From nobody Wed Aug 6 14:09:36 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512391B27B5; Wed, 6 Aug 2014 14:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLMGy-dNVpk8; Wed, 6 Aug 2014 14:09:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6851A02A6; Wed, 6 Aug 2014 14:09:32 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140806210932.26762.11590.idtracker@ietfa.amsl.com> Date: Wed, 06 Aug 2014 14:09:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/pgbY9zwOfwwBa18hOz1s3VUgym4 Cc: paws@ietf.org Subject: [paws] Second Last Call: (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 21:09:34 -0000 The IESG has received a request from the Protocol to Access WS database WG (paws) to consider the following document: - 'Protocol to Access White-Space (PAWS) Databases' as Proposed Standard A prior Last Call was made for version -12 of this document. Comments received during that discussion lead to extensive edits to the document, which could benefit from a second review. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-08-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "White Space." Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to managing spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space (PAWS) Databases". The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2203/ http://datatracker.ietf.org/ipr/2340/ http://datatracker.ietf.org/ipr/2239/ From nobody Wed Aug 6 18:55:04 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67341B283F; Wed, 6 Aug 2014 18:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb9UZ4IJOnYj; Wed, 6 Aug 2014 18:55:00 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FC31A0452; Wed, 6 Aug 2014 18:55:00 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s771swS8066762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Wed, 6 Aug 2014 20:54:59 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53E2DC72.8020301@nostrum.com> Date: Wed, 06 Aug 2014 20:54:58 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ietf@ietf.org, IETF-Announce References: <20140806210932.26762.11590.idtracker@ietfa.amsl.com> In-Reply-To: <20140806210932.26762.11590.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/paws/qi4yvNArAX6HBtD-qfKuBqKmPHc Cc: paws@ietf.org, General Area Review Team , draft-ietf-paws-protocol.all@tools.ietf.org Subject: [paws] Genart LC review draft-ietf-paws-protocol-14 (was Re: Second Last Call: (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 01:55:03 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-paws-protocol-14 Reviewer: Robert Sparks Review Date: 6-Aug-2014 IETF LC End Date: 20-Aug-2014 IESG Telechat date: 21-Aug-2014 Summary: Ready for publication as Proposed Standard Version -14 addresses the concerns I raised with -12. Thanks again to the WG and the authors for such quick and effective responses. RjS On 8/6/14, 4:09 PM, The IESG wrote: > The IESG has received a request from the Protocol to Access WS database > WG (paws) to consider the following document: > - 'Protocol to Access White-Space (PAWS) Databases' > as Proposed Standard > > A prior Last Call was made for version -12 of this document. Comments > received during that discussion lead to extensive edits to the document, > which could benefit from a second review. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-08-20. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > Portions of the radio spectrum that are allocated to licensees are > available for non-interfering use. This available spectrum is called > "White Space." Allowing secondary users access to available spectrum > "unlocks" existing spectrum to maximize its utilization and to > provide opportunities for innovation, resulting in greater overall > spectrum utilization. > > One approach to managing spectrum sharing uses databases to report > spectrum availability to devices. To achieve interoperability among > multiple devices and databases, a standardized protocol must be > defined and implemented. This document defines such a protocol, the > "Protocol to Access White Space (PAWS) Databases". > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ballot/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/2203/ > http://datatracker.ietf.org/ipr/2340/ > http://datatracker.ietf.org/ipr/2239/ > > > From nobody Mon Aug 11 05:51:24 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1F01A0296 for ; Mon, 11 Aug 2014 05:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.568 X-Spam-Level: X-Spam-Status: No, score=-0.568 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TAkU3yEml4s for ; Mon, 11 Aug 2014 05:51:18 -0700 (PDT) Received: from ls-mx3.csir.co.za (mx-3.csir.co.za [146.64.10.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06301A03CA for ; Mon, 11 Aug 2014 05:51:12 -0700 (PDT) Received: from pta-emo.csir.co.za (pta-emo.csir.co.za [146.64.100.109]) by ls-mx3.csir.co.za (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id s7BCowSU023242 for ; Mon, 11 Aug 2014 14:51:00 +0200 Received: from PTA-EMO-MTA by pta-emo.csir.co.za with Novell_GroupWise; Mon, 11 Aug 2014 14:50:39 +0200 Message-Id: <53E8D83B0200009E0009B0DC@pta-emo.csir.co.za> X-Mailer: Novell GroupWise Internet Agent 12.0.2 Date: Mon, 11 Aug 2014 14:50:35 +0200 From: "Luzango Mfupe" To: References: <53E8D5260200009E0009B0D8@pta-emo.csir.co.za> <53E8D83B0200009E0009B0DC@pta-emo.csir.co.za> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part6456D20B.4__=" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (ls-mx3.csir.co.za [146.64.10.248]); Mon, 11 Aug 2014 14:51:00 +0200 (SAST) X-CSIR-MailScanner-Information: Please contact the ISP for more information X-CSIR-MailScanner-ID: s7BCowSU023242 X-CSIR-MailScanner: Found to be clean X-CSIR-MailScanner-From: lmfupe@csir.co.za X-CSIR-MailScanner-Watermark: 1408366260.73914@Fo/58C/KoPvBpS+LLPhZrg Archived-At: http://mailarchive.ietf.org/arch/msg/paws/WYRdVxAJ5UHtFIrDZx-WeUPZ9bE Cc: paws@ietf.org, barryleiba@computer.org Subject: Re: [paws] Review of draft-ietf-paws-protocol-12 (by the other APPAD) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 12:51:22 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part6456D20B.4__= Content-Type: multipart/alternative; boundary="=__Part6456D20B.5__=" --=__Part6456D20B.5__= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Vince, Folks, It seems the issue of adding the single-resolution bandwidth example slipped off the cracks some how as it was supposed to be included in the current draft. Today I am presenting another burning issue relevant to the following Sections: SECTION 5.5 DeviceOwner SECTION 6.4 Example Encoding Device Owner vCard Can you please elaborate how the device owner jcard/vCard fragments should be handled within the JSON registration request message body; what primitive type(s) should be applied( i.e, String, int etc...). Apparently there is already a great deal of confusion in this area as some would thinks the card fragments should just be sent as-it-is in an array format with the rest of the JSON registration request body To the best of my understanding jcards are supposed to be written as String primitive types this allows to preserve the formatting when they are parse/read by the spectrum database/server or any other application that would wish to extract the contact information in a standardised format. Section 5.5 is silent on the definition of vCard data type(s), while the example provided in Section 6.4 shows the vCard in an array. May I suggest that we should also explicitly state the data type of jcard similar to the way we have defined data types for other aspects throughout the document (e.g., In Section 5.2 Device Descriptor)...In doing so this will clear any future confusions in the implementation of our standard. Kind Regards, Luzango. >>> Vincent Chen 28/07/2014 18:54 >>> Hi Luzango, Thanks for your suggestions. On Sat, Jul 26, 2014 at 9:51 AM, Luzango Mfupe wrote: Hi Vince, Folks, I am glad to see things are moving to the right direction and hopefully soon we will finalise this work. I just found some few not very critical issues that needs some fixing in in my opinion: 5.11. Spectrum Here the document talk about the FCC and OFCOM/ETSI spectral profile presentation requirements (i.e, power levels over a set of frequency ranges. However, there is only one type of example (OFCOM/ETSI specific) that is provided throughout the document. I think we need to add another set of example that is FCC specific. Would something like this below suffice for the FCC specific example? “resolutionBwHz”: 1e5, “profiles”: [ { "Hz": 5.18e8, "Hz": 5.24e8, “dbm”: 24 ] }, Ah. I see. We can add a single resolution-bandwidth example for completeness. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner ( http://www.mailscanner.info/) , and is believed to be clean. Please consider the environment before printing this email. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. --=__Part6456D20B.5__= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Description: HTML
Hi Vince, Folks,
 
It seems the issue of adding the singl= e-resolution bandwidth example slipped off the cracks some how as it w= as supposed to be included in the current draft.
 
Today I am presenting another burning issue= relevant to the following Sections:
 
SECTION 5.5 DeviceOwner
SECTION 6.4 Example Encoding Device Owner v= Card
 
Can you please elaborate how the device owner&nb= sp;jcard/vCard fragments should be handled within the JSON registratio= n request message body; what primitive type(s) should be applied( i.e, Stri= ng, int etc...). Apparently there is already a great deal of confusion= in this area as some would thinks the card fragments should= just be sent as-it-is in an array format with the rest of the JS= ON registration request body
 
To the best of my understanding jcards are = supposed to be written as String primitive types this allows to preser= ve the formatting when they are parse/read by the spectrum databa= se/server or any other application that would wish to extract the= contact information in a standardised format. 
 
Section 5.5 is silent on the definitio= n of vCard data type(s), while the example provided in Section 6.4 shows th= e vCard in an array.
 
May I suggest that we should also expl= icitly state the data type of jcard similar to the way we have defined= data types for other aspects throughout the document (e.g., In Section 5.2= Device Descriptor)...In doing so this will clear any future confusions&nbs= p;in the implementation of our standard.
 
 
Kind Regards,
Luzango.


>>> Vincent Chen <vchen@google.com> 28/07/2014 = 18:54 >>>
Hi Luzango,=20

Thanks for your suggestions.


On Sat, Jul 26, 2014 at 9:51 AM, Luzango Mfupe <lmfup= e@csir.co.za> wrote:
Hi Vince, Folks,= =20

I am glad to see things are moving to the right direction and hop= efully soon we will finalise this work.

I just found some few not very critical issues that needs some fi= xing in in my opinion:

5.11. Spectrum<= /B>

=

Here the document talk about the FCC and OFCOM/ETSI spectral profil= e presentation requirements (i.e, power levels over a set of frequency ranges. However, there is only one= type of example (OFCOM/ETSI specific) that is provided throughout the docu= ment. I think we need to add another set of example that is FCC specific. <= /SPAN>


=

Would something li= ke this below suffice for the FCC specific example?

<= FONT color=3D#0000ff face=3D"Courier New, monospace">

=E2=80=9CresolutionBwHz=E2=80=9D: 1e5,

=E2=80=9Cprofiles=E2=80=9D: [

{

"Hz": 5.18e8,

"Hz": 5.24e8,

=E2=80=9Cdbm=E2=80=9D: 24

] },

=



Ah. I see. We can add a single resolution-bandwidth example for comple= teness.

--
Th= is message is subject to the CSIR's copyright terms and conditions, e-mail = legal notice, and implemented Open Document Format (ODF) standard.
The = full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by <= A href=3D"http://www.mailscanner.info/">MailScanner,
and is = believed to be clean.=20


Please consider the environment before printing this email. <= /P>
--=20
This message is subject to the CSIR's copyright terms and conditions,= e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner,=20
and is believed to be clean.


Please consider the environment before printing this email. --=__Part6456D20B.5__=-- --=__Part6456D20B.4__=-- From nobody Mon Aug 11 07:43:00 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818D71A03FE for ; Mon, 11 Aug 2014 07:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDz8UAht10pJ for ; Mon, 11 Aug 2014 07:42:54 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34BF1A03F2 for ; Mon, 11 Aug 2014 07:42:53 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id ik5so11700194vcb.34 for ; Mon, 11 Aug 2014 07:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wimT2aH2jcbxpEwAtM/UQvWcUQgvekoFQYrLXW8QOug=; b=LEoWoEAA1EXRvzn2jp4zIDSmAxOjsM0jlP40hrlKykQ29mfbh5UwyuLGB3fiq6pJrZ FJrXu+M9mrLD1W6Lib9bblft0DrZ+cYS3dwYv8b7sUlmyOLi57+B5Z4GGxrmlLhsBzgT 4g+lq9cDXV0nLAUBD+AK26vuP/0bGLTFyUs18ZKUWAzi26/s9MKxznQBmDZgTxo/zdwX 9IRfK9e6kCB1Z20Xc3FvwcGxgxSBHtraFk/KkLUrh/VhFskboeGVHKw/JFoBd4Yb5aW1 clVYHTWs4RN9IoXSxjHbgtq9Dcd4rcK3m9sqdTYVETaE0VQkpWhDwMhjfGi2KwDReIox VxNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wimT2aH2jcbxpEwAtM/UQvWcUQgvekoFQYrLXW8QOug=; b=H9I4JOg5+riRay1CieTp7FU2nKRnQ7C+leVEEEUbwTnYjWMddJkOYTnFAOqOTON+JN 4RHPcIMLBKTgwG2zFx/qoI1Y1uUKZjVzngbBQRQoT9XrAWiNJP617+u3A731I9MvBYCn Z2jasQdi1W4lv+xxamgprJGKoEVDbKMLu+XPjGZp1SPyY861Rd70q6L5osQbqi74zJwC Nk6OJOhDd+dYqMlphuDtv8V91a8rprOoFAx4yrz8CNh+P47ygIyKbSGK/R7ilz5vHasf XQ5A1a0NOHGg1dil5yP3h/tFCyWbHO/bXgnqQudL+jwWeA2SxOJEYJJrMyZ0uO2L13eO tEsA== X-Gm-Message-State: ALoCoQnWBjquKDQuoUSMOv2cItOKgjyFU0kt73puc57sJ/kDR5iNmqPa5/A0HpbtoDkQl59zxJnl MIME-Version: 1.0 X-Received: by 10.52.137.2 with SMTP id qe2mr19402794vdb.11.1407768172898; Mon, 11 Aug 2014 07:42:52 -0700 (PDT) Received: by 10.52.118.3 with HTTP; Mon, 11 Aug 2014 07:42:52 -0700 (PDT) In-Reply-To: <53E8D83B0200009E0009B0DC@pta-emo.csir.co.za> References: <53E8D5260200009E0009B0D8@pta-emo.csir.co.za> <53E8D83B0200009E0009B0DC@pta-emo.csir.co.za> <53E8D83B0200009E0009B0DC@pta-emo.csir.co.za> Date: Mon, 11 Aug 2014 07:42:52 -0700 Message-ID: From: Vincent Chen To: Luzango Mfupe Content-Type: multipart/alternative; boundary=bcaec51b161bdf4e2105005b913f Archived-At: http://mailarchive.ietf.org/arch/msg/paws/7DvwJDO9FUjCtb6UZwF8qn0GtJ0 Cc: "paws@ietf.org" , Barry Leiba Subject: Re: [paws] Review of draft-ietf-paws-protocol-12 (by the other APPAD) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 14:42:56 -0000 --bcaec51b161bdf4e2105005b913f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Luzango, On Mon, Aug 11, 2014 at 5:50 AM, Luzango Mfupe wrote: > Hi Vince, Folks, > > It seems the issue of adding the single-resolution bandwidth > example slipped off the cracks some how as it was supposed to be included > in the current draft. > Please see the first example in Section 5.11, which was added based on your suggestion. > > Today I am presenting another burning issue relevant to the following > Sections: > > SECTION 5.5 DeviceOwner > SECTION 6.4 Example Encoding Device Owner vCard > > Can you please elaborate how the device owner jcard/vCard fragments shoul= d > be handled within the JSON registration request message body; what > primitive type(s) should be applied( i.e, String, int etc...). Apparently > there is already a great deal of confusion in this area as some would > thinks the card fragments should just be sent as-it-is in an array > format with the rest of the JSON registration request body > > To the best of my understanding jcards are supposed to be written as > String primitive types this allows to preserve the formatting when they a= re > parse/read by the spectrum database/server or any other application > that would wish to extract the contact information in a standardised > format. > > Section 5.5 is silent on the definition of vCard data type(s), while the > example provided in Section 6.4 shows the vCard in an array. > > May I suggest that we should also explicitly state the data type of jcard > similar to the way we have defined data types for other aspects throughou= t > the document (e.g., In Section 5.2 Device Descriptor)...In doing so this > will clear any future confusions in the implementation of our standard. > Actually, Section 6.4 is the jCard representation and was intended to provide the clarification you're asking for. Perhaps it needs a better intro sentence? Since Sections 4 and 5 define new data models for PAWS, we provide a mapping from those data models to JSON. On the other hand, we are not redefining vCard and jCard, so it seemed redundant to repeat their definitions. -vince > > Kind Regards, > Luzango. > > > >>> Vincent Chen 28/07/2014 18:54 >>> > Hi Luzango, > > Thanks for your suggestions. > > > On Sat, Jul 26, 2014 at 9:51 AM, Luzango Mfupe wrote: > >> Hi Vince, Folks, >> >> I am glad to see things are moving to the right direction and hopefully >> soon we will finalise this work. >> >> I just found some few not very critical issues that needs some fixing in >> in my opinion: >> >> *5.11. Spectrum* >> >> >> Here the document talk about the FCC and OFCOM/ETSI spectral profile >> presentation requirements (i.e, power levels over a set of frequency >> ranges. However, there is only one type of example (OFCOM/ETSI specific) >> that is provided throughout the document. I think we need to add another >> set of example that is FCC specific. >> >> >> Would something like this below suffice for the FCC specific example? >> >> =E2=80=9CresolutionBwHz=E2=80=9D: 1e5, >> >> =E2=80=9Cprofiles=E2=80=9D: [ >> >> { >> >> "Hz": 5.18e8, >> >> "Hz": 5.24e8, >> >> =E2=80=9Cdbm=E2=80=9D: 24 >> >> ] }, >> >> >> >> > Ah. I see. We can add a single resolution-bandwidth example for > completeness. > > -- >> This message is subject to the CSIR's copyright terms and conditions, >> e-mail legal notice, and implemented Open Document Format (ODF) standard= . >> The full disclaimer details can be found at >> http://www.csir.co.za/disclaimer.html. >> > > This message has been scanned for viruses and dangerous content by > *MailScanner* , > and is believed to be clean. > > > Please consider the environment before printing this email. > > -- > This message is subject to the CSIR's copyright terms and conditions, > e-mail legal notice, and implemented Open Document Format (ODF) standard. > The full disclaimer details can be found at > http://www.csir.co.za/disclaimer.html. > > > This message has been scanned for viruses and dangerous content by > *MailScanner* , > and is believed to be clean. > > > Please consider the environment before printing this email. > > --=20 -vince --bcaec51b161bdf4e2105005b913f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Luzango,


On Mon, Aug 11, 2014 at 5:50 AM, Luzango Mfupe <LMfupe@= csir.co.za> wrote:
Hi Vince, Folks,
=C2=A0
It seems=C2=A0the issue of adding the=C2=A0sin= gle-resolution bandwidth example=C2=A0slipped off the cracks some how as it= was=C2=A0supposed to be included in the current draft.
<= /blockquote>

Please see the first example in Section 5.11, which was adde= d based on your suggestion.
=C2=A0
=C2=A0
Today I am presenting another=C2=A0burning iss= ue relevant to the following Sections:
=C2=A0
SECTION 5.5 DeviceOwner
SECTION 6.4 Example Encoding Device Owner=C2= =A0vCard
=C2=A0
Can you please elaborate how the device owner= =C2=A0jcard/vCard=C2=A0fragments should be handled within the JSON registra= tion request message body; what primitive type(s) should be applied( i.e, S= tring,=C2=A0int etc...). Apparently there is already a great deal of confus= ion in this area as some=C2=A0would thinks=C2=A0the card fragments=C2=A0sho= uld just be sent as-it-is in=C2=A0an array format=C2=A0with the rest of the= JSON registration request body
=C2=A0
To the best of my understanding=C2=A0jcards ar= e supposed to be=C2=A0written as String primitive types this allows to pres= erve=C2=A0the=C2=A0formatting when they are parse/read by the spectrum data= base/server or any other application that=C2=A0would wish to extract=C2=A0t= he contact information in=C2=A0a standardised format.=C2=A0
=C2=A0
Section 5.5 is=C2=A0silent=C2=A0on the definit= ion of vCard data type(s), while the example provided in Section 6.4 shows = the vCard in an array.
=C2=A0
May I suggest that=C2=A0we should also=C2=A0ex= plicitly state the data type of jcard similar to the way we have=C2=A0defin= ed data types for other aspects throughout the document (e.g., In Section 5= .2 Device Descriptor)...In doing so this will clear any future confusions= =C2=A0in the implementation of our standard.

Actually, Section 6.4 is the jCard r= epresentation and was intended to provide the clarification you're aski= ng for.
Perhaps it needs a better intro sentence?

Since Sections 4 and 5 define new data models for PAWS, we provi= de a mapping from those data models to JSON.
On the other hand, w= e are not redefining vCard and jCard, so it seemed redundant to repeat thei= r definitions.

-vince

=C2=A0
=C2=A0
Kind Regards,
Luzango.


>>> Vincent Chen <vchen@google.com> 28/07/2014 18:54 >>>= ;
Hi Luzango,=20

Thanks for your suggestions.


On Sat, Jul 26, 2014 at 9:51 AM, Luzango Mfupe <= span dir=3D"ltr"><lmfupe@csir.co.za> wrote:
Hi Vince, Folks,= =20

I am glad to see things are moving to the right direction and ho= pefully soon we will finalise this work.

I just found some few not very critical issues that needs some f= ixing in in my opinion:

<= font color=3D"#0000ff" face=3D"Courier New, monospace">5.11. Spectrum


Here the document talk about the FCC and OFCOM/ETSI spectral profile= presentation requirements (i.e, power levels over a set of frequency ranges. However, there is only one type o= f example (OFCOM/ETSI specific) that is provided throughout the document. I= think we need to add another set of example that is FCC specific. <= /font>

Would something like= this below suffice for the FCC specific example?

=E2=80=9CresolutionBwHz=E2=80=9D: 1e5,

=E2=80=9Cprofiles=E2=80=9D: [

{

"Hz": 5.18e8,

"Hz": 5.24e8,

=E2=80=9Cdbm=E2=80=9D: 24

] },




Ah. I see. We can add a single resolution-bandwidth example for comple= teness.

--
= This message is subject to the CSIR's copyright terms and conditions, e= -mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html<= /a>.


This message has been scanned for viruses and dangerous content by <= a href=3D"http://www.mailscanner.info/" target=3D"_blank">MailScanner,
and is believed to be clean.=20


Please consider the environment before printing this email.

=
--=20
This message is subject to the CSIR's copyright terms and condition= s, e-mail legal notice, and implemented Open Document Format (ODF) standard= .
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.h= tml.


This message has been scanned for viruses and dangerous content by MailScanner,=20
and is believed to be clean.


Please consider the environment before printing this email.




--
-vince
--bcaec51b161bdf4e2105005b913f-- From nobody Mon Aug 11 08:18:48 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A351E1A04AC for ; Mon, 11 Aug 2014 08:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auhiQnmv9ItZ for ; Mon, 11 Aug 2014 08:18:44 -0700 (PDT) Received: from ls-mx3.csir.co.za (mx-3.csir.co.za [146.64.10.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A597D1A0401 for ; Mon, 11 Aug 2014 08:18:41 -0700 (PDT) Received: from pta-emo.csir.co.za (pta-emo.csir.co.za [146.64.100.109]) by ls-mx3.csir.co.za (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id s7BFIMmn014154 for ; Mon, 11 Aug 2014 17:18:24 +0200 Received: from PTA-EMO-MTA by pta-emo.csir.co.za with Novell_GroupWise; Mon, 11 Aug 2014 17:18:17 +0200 Message-Id: <53E8FAD70200009E0009B121@pta-emo.csir.co.za> X-Mailer: Novell GroupWise Internet Agent 12.0.2 Date: Mon, 11 Aug 2014 17:18:15 +0200 From: "Luzango Mfupe" To: "Vincent Chen" References: <53E8D5260200009E0009B0D8@pta-emo.csir.co.za> <53E8D83B0200009E0009B0DC@pta-emo.csir.co.za> <53E8D83B0200009E0009B0DC@pta-emo.csir.co.za> In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartAA981CA7.4__=" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (ls-mx3.csir.co.za [146.64.10.248]); Mon, 11 Aug 2014 17:18:24 +0200 (SAST) X-CSIR-MailScanner-Information: Please contact the ISP for more information X-CSIR-MailScanner-ID: s7BFIMmn014154 X-CSIR-MailScanner: Found to be clean X-CSIR-MailScanner-From: lmfupe@csir.co.za X-CSIR-MailScanner-Watermark: 1408375104.61866@pb9jMSR16W9b9xKgGgGnDQ Archived-At: http://mailarchive.ietf.org/arch/msg/paws/-vWV8Yt0YOReJUF6pB-5__LY75M Cc: "paws@ietf.org" , Barry Leiba Subject: Re: [paws] Review of draft-ietf-paws-protocol-12 (by the other APPAD) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 15:18:46 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartAA981CA7.4__= Content-Type: multipart/alternative; boundary="=__PartAA981CA7.5__=" --=__PartAA981CA7.5__= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Vince, Thanks for prompt clarifications however, my suggestion is that the data type of vCard fragments (the device owner part and the device operator part) as a whole should be explicitly stated in section 5.5. Here I am not talking about the data types of individual parameters inside the vCard itself. This will indeed help to preserve the integrity of card formatting when they are being parsed by different applications as well as promote uniformity in different PAWS implementations. Kind Regards, Luzango. >>> Vincent Chen 11/08/2014 16:42 >>> Hi Luzango, On Mon, Aug 11, 2014 at 5:50 AM, Luzango Mfupe wrote: Hi Vince, Folks, It seems the issue of adding the single-resolution bandwidth example slipped off the cracks some how as it was supposed to be included in the current draft. Please see the first example in Section 5.11, which was added based on your suggestion. Today I am presenting another burning issue relevant to the following Sections: SECTION 5.5 DeviceOwner SECTION 6.4 Example Encoding Device Owner vCard Can you please elaborate how the device owner jcard/vCard fragments should be handled within the JSON registration request message body; what primitive type(s) should be applied( i.e, String, int etc...). Apparently there is already a great deal of confusion in this area as some would thinks the card fragments should just be sent as-it-is in an array format with the rest of the JSON registration request body To the best of my understanding jcards are supposed to be written as String primitive types this allows to preserve the formatting when they are parse/read by the spectrum database/server or any other application that would wish to extract the contact information in a standardised format. Section 5.5 is silent on the definition of vCard data type(s), while the example provided in Section 6.4 shows the vCard in an array. May I suggest that we should also explicitly state the data type of jcard similar to the way we have defined data types for other aspects throughout the document (e.g., In Section 5.2 Device Descriptor)...In doing so this will clear any future confusions in the implementation of our standard. Actually, Section 6.4 is the jCard representation and was intended to provide the clarification you're asking for. Perhaps it needs a better intro sentence? Since Sections 4 and 5 define new data models for PAWS, we provide a mapping from those data models to JSON. On the other hand, we are not redefining vCard and jCard, so it seemed redundant to repeat their definitions. -vince Kind Regards, Luzango. >>> Vincent Chen 28/07/2014 18:54 >>> Hi Luzango, Thanks for your suggestions. On Sat, Jul 26, 2014 at 9:51 AM, Luzango Mfupe wrote: Hi Vince, Folks, I am glad to see things are moving to the right direction and hopefully soon we will finalise this work. I just found some few not very critical issues that needs some fixing in in my opinion: 5.11. Spectrum Here the document talk about the FCC and OFCOM/ETSI spectral profile presentation requirements (i.e, power levels over a set of frequency ranges. However, there is only one type of example (OFCOM/ETSI specific) that is provided throughout the document. I think we need to add another set of example that is FCC specific. Would something like this below suffice for the FCC specific example? “resolutionBwHz”: 1e5, “profiles”: [ { "Hz": 5.18e8, "Hz": 5.24e8, “dbm”: 24 ] }, Ah. I see. We can add a single resolution-bandwidth example for completeness. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner ( http://www.mailscanner.info/) , and is believed to be clean. Please consider the environment before printing this email. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner ( http://www.mailscanner.info/) , and is believed to be clean. Please consider the environment before printing this email. -- -vince -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner ( http://www.mailscanner.info/) , and is believed to be clean. Please consider the environment before printing this email. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. --=__PartAA981CA7.5__= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Description: HTML
Hi Vince,
 
Thanks for prompt clarifications however, my suggestion= is that the data type of vCard fragments (the device owner part and the de= vice operator part) as a whole should be explicitly stated in section = 5.5. Here I am not talking about the data types of individual paramete= rs inside the vCard itself. This will indeed help to preserve the integrity= of card formatting when they are being parsed by different applications&nb= sp;as well as promote uniformity in different PAWS implementations.
 
Kind Regards,
Luzango.

>>> Vincent Chen <vchen@google.com> 11/= 08/2014 16:42 >>>
Hi Luzango,


On Mon, Aug 11, 2014 at 5:50 AM, Luzango Mfupe <LMfup= e@csir.co.za> wrote:
Hi Vince, Folks,
It seems the issue of adding the single-resoluti= on bandwidth example slipped off the cracks some how as it was supposed to = be included in the current draft.

Please see the first example in Section 5.11, which was added based on= your suggestion.
Today I am presenting another burning issue rele= vant to the following Sections:
SECTION 5.5 DeviceOwner
SECTION 6.4 Example Encoding Device Owner vCard<= /FONT>
Can you please elaborate how the device owner jc= ard/vCard fragments should be handled within the JSON registration request = message body; what primitive type(s) should be applied( i.e, String, int et= c...). Apparently there is already a great deal of confusion in this area a= s some would thinks the card fragments should just be sent as-it-is in an a= rray format with the rest of the JSON registration request body
To the best of my understanding jcards are suppo= sed to be written as String primitive types this allows to preserve the for= matting when they are parse/read by the spectrum database/server or any oth= er application that would wish to extract the contact information in a stan= dardised format.
Section 5.5 is silent on the definition of vCard= data type(s), while the example provided in Section 6.4 shows the vCard in= an array.
May I suggest that we should also explicitly sta= te the data type of jcard similar to the way we have defined data types for= other aspects throughout the document (e.g., In Section 5.2 Device Descrip= tor)...In doing so this will clear any future confusions in the implementat= ion of our standard.

Actually, Section 6.4 is the jCard representation and was intended to = provide the clarification you're asking for.
Perhaps it needs a better intro sentence?

Since Sections 4 and 5 define new data models for PAWS, we provide a m= apping from those data models to JSON.
On the other hand, we are not redefining vCard and jCard, so it seemed= redundant to repeat their definitions.

-vince

Kind Regards,
Luzango.


>>> Vincent Chen <vchen@google.com> 28/07/2014 18:54 >>><= BR>
Hi Luzango,=20

Thanks for your suggestions.


On Sat, Jul 26, 2014 at 9:51 AM, Luzango Mfupe <lmfup= e@csir.co.za> wrote:
Hi Vince, Folks,= =20

I am glad to see things are moving to the right direction and hop= efully soon we will finalise this work.

I just found some few not very critical issues that needs some fi= xing in in my opinion:

5.11. Spectrum<= /B>

=

Here the document talk about the FCC and OFCOM/ETSI spectral profil= e presentation requirements (i.e, power levels over a set of frequency ranges. However, there is only one= type of example (OFCOM/ETSI specific) that is provided throughout the docu= ment. I think we need to add another set of example that is FCC specific. <= /SPAN>


=

Would something li= ke this below suffice for the FCC specific example?

<= FONT color=3D#0000ff face=3D"Courier New, monospace">

=E2=80=9CresolutionBwHz=E2=80=9D: 1e5,

=E2=80=9Cprofiles=E2=80=9D: [

{

"Hz": 5.18e8,

"Hz": 5.24e8,

=E2=80=9Cdbm=E2=80=9D: 24

] },

=



Ah. I see. We can add a single resolution-bandwidth example for comple= teness.

--
Th= is message is subject to the CSIR's copyright terms and conditions, e-mail = legal notice, and implemented Open Document Format (ODF) standard.
The = full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. <= /FONT>


This message has been scanned for viruses and dangerous content by <= A href=3D"http://www.mailscanner.info/" target=3D_blank>MailScanner<= /A>,
and is believed to be clean.


Please consider the environment before printing this email.


--
This message is subject to the CSIR's c= opyright terms and conditions, e-mail legal notice, and implemented Open Do= cument Format (ODF) standard.
The full disclaimer details can be found = at http:/= /www.csir.co.za/disclaimer.html.=20


This message has been scanned for viruses and dangerous content by <= A href=3D"http://www.mailscanner.info/" target=3D_blank>MailScanner<= /A>,
and is believed to be clean.


Please consider the environment before printing this email.




--
-vince

--
This message is subject to the CSIR's= copyright terms and conditions, e-mail legal notice, and implemented Open = Document Format (ODF) standard.
The full disclaimer details can be foun= d at http://www.csir.co.z= a/disclaimer.html.=20


This message has been scanned for viruses and dangerous content by <= A href=3D"http://www.mailscanner.info/">MailScanner,
and is = believed to be clean.=20


Please consider the environment before printing this email. <= /P>
--=20
This message is subject to the CSIR's copyright terms and conditions,= e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner,=20
and is believed to be clean.


Please consider the environment before printing this email. --=__PartAA981CA7.5__=-- --=__PartAA981CA7.4__=-- From nobody Tue Aug 12 12:51:51 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D55C1A00EA for ; Tue, 12 Aug 2014 12:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.646 X-Spam-Level: X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6UVzK8fiwEP for ; Tue, 12 Aug 2014 12:51:46 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6351D1A0076 for ; Tue, 12 Aug 2014 12:51:46 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id ij19so13823099vcb.39 for ; Tue, 12 Aug 2014 12:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CeFoQefekAKsAoz6kVdT2AkFPXD/uB1v5jPyzrPTdJ4=; b=L1MPAaLSyOaGF+3V3y/EW4hYHx6FIKWau0xvXp3NQfEKC9ZzHpgT4fbeZmD7Eqd90q pUhI4jhxmKUbA5U/ApFBytOl69gXvxc3QVFHG2mKQrTXXceK7JhPpxCdT7pgl2H2J9eZ eJCe0vRTPCAABJw8pxxyDSwBaLE5Fo37I+27354ySkIOI67BgqRzl+CoekFiqeYiUl9m Nn/4mhhllVHfeym176yX6u58F0po9EAyt6vzMjNOHVyhLX5LRHrfq1h2ApHlbKA2OEXt l+aIgsI1E88uDz4jY2xQSdTc2fUf08/hPXIXbmd0S0hgBAiphFu1kAe5tzmEpP7q8Trx EANA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CeFoQefekAKsAoz6kVdT2AkFPXD/uB1v5jPyzrPTdJ4=; b=Si9FFVr64kXf6km2Z3CIqTRNLbuHmz94akXDWxrLWgWThseX7QBhzOhHwhgJ/QH2VO FQnie9Wu/nZ8qa7aCGJiYlaX9sL+4lFqcXUHN1/RRMuXEW4MBKI9jG6Tzul5VD6H9Qu4 Yj2otqqaE5N+JNpJy5ZFzNLX0fOROaVOPlqyxAHHwW8OYxehM3407fm4CMMQn7HqjdBO BsGBMf2Wbw/Qo5a4rifmoStiLgsPZAaMxv51iTR7cr8oALip0TZnhUoJx3kYSd7UideE TyAaxqfgN2SOD7sQ1qMaLgr4Fn2MShUgUYp3wvXa92sNp+crBAvJ466/3L3NFGHyON69 DO0A== X-Gm-Message-State: ALoCoQleb4MXZ0etV6FofdzesxhAZaqaOUWV10kC1wQPUwzA2OStnTsowp2wFerOErlIdBCAASvt MIME-Version: 1.0 X-Received: by 10.52.168.134 with SMTP id zw6mr25509075vdb.37.1407873105177; Tue, 12 Aug 2014 12:51:45 -0700 (PDT) Received: by 10.52.118.3 with HTTP; Tue, 12 Aug 2014 12:51:45 -0700 (PDT) In-Reply-To: <53E8FAD70200009E0009B121@pta-emo.csir.co.za> References: <53E8D5260200009E0009B0D8@pta-emo.csir.co.za> <53E8D83B0200009E0009B0DC@pta-emo.csir.co.za> <53E8FAD70200009E0009B121@pta-emo.csir.co.za> Date: Tue, 12 Aug 2014 12:51:45 -0700 Message-ID: From: Vincent Chen To: Luzango Mfupe Content-Type: multipart/alternative; boundary=089e0163509452cb8b050074003c Archived-At: http://mailarchive.ietf.org/arch/msg/paws/BpRhVOr33jNzdDvgwphA04M926c Cc: "paws@ietf.org" , Barry Leiba Subject: Re: [paws] Review of draft-ietf-paws-protocol-12 (by the other APPAD) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 19:51:49 -0000 --089e0163509452cb8b050074003c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Luzango, Please see Section 9.1.2.1 for additional requirements on the DeviceOwner fields for FCC rules. There's a table that describes the required fields that must appear for "owner" and "operator". We did not want to make any restrictions in the core PAWS spec. Also, RFC 6350 defines what the types are for each field, e.g., "fn" is "a single text value" (Section 6.2.1) and "adr" is a structured text value of 7 components (Section 6.3.1). -vince On Mon, Aug 11, 2014 at 8:18 AM, Luzango Mfupe wrote: > Hi Vince, > > Thanks for prompt clarifications however, my suggestion is that the data > type of vCard fragments (the device owner part and the device operator > part) as a whole should be explicitly stated in section 5.5. Here I am no= t > talking about the data types of individual parameters inside the vCard > itself. This will indeed help to preserve the integrity of card formattin= g > when they are being parsed by different applications as well as promote > uniformity in different PAWS implementations. > > Kind Regards, > Luzango. > > >>> Vincent Chen 11/08/2014 16:42 >>> > Hi Luzango, > > > On Mon, Aug 11, 2014 at 5:50 AM, Luzango Mfupe wrote: > >> Hi Vince, Folks, >> It seems the issue of adding the single-resolution bandwidth example >> slipped off the cracks some how as it was supposed to be included in the >> current draft. >> > > Please see the first example in Section 5.11, which was added based on > your suggestion. > >> Today I am presenting another burning issue relevant to the following >> Sections: >> SECTION 5.5 DeviceOwner >> SECTION 6.4 Example Encoding Device Owner vCard >> Can you please elaborate how the device owner jcard/vCard fragments >> should be handled within the JSON registration request message body; wha= t >> primitive type(s) should be applied( i.e, String, int etc...). Apparentl= y >> there is already a great deal of confusion in this area as some would >> thinks the card fragments should just be sent as-it-is in an array forma= t >> with the rest of the JSON registration request body >> To the best of my understanding jcards are supposed to be written as >> String primitive types this allows to preserve the formatting when they = are >> parse/read by the spectrum database/server or any other application that >> would wish to extract the contact information in a standardised format. >> Section 5.5 is silent on the definition of vCard data type(s), while >> the example provided in Section 6.4 shows the vCard in an array. >> May I suggest that we should also explicitly state the data type of >> jcard similar to the way we have defined data types for other aspects >> throughout the document (e.g., In Section 5.2 Device Descriptor)...In do= ing >> so this will clear any future confusions in the implementation of our >> standard. >> > > Actually, Section 6.4 is the jCard representation and was intended to > provide the clarification you're asking for. > Perhaps it needs a better intro sentence? > > Since Sections 4 and 5 define new data models for PAWS, we provide a > mapping from those data models to JSON. > On the other hand, we are not redefining vCard and jCard, so it seemed > redundant to repeat their definitions. > > -vince > > Kind Regards, >> Luzango. >> >> >> >>> Vincent Chen 28/07/2014 18:54 >>> >> Hi Luzango, >> >> Thanks for your suggestions. >> >> >> On Sat, Jul 26, 2014 at 9:51 AM, Luzango Mfupe wrote= : >> >>> Hi Vince, Folks, >>> >>> I am glad to see things are moving to the right direction and hopefully >>> soon we will finalise this work. >>> >>> I just found some few not very critical issues that needs some fixing i= n >>> in my opinion: >>> >>> *5.11. Spectrum* >>> >>> >>> Here the document talk about the FCC and OFCOM/ETSI spectral profile >>> presentation requirements (i.e, power levels over a set of frequency >>> ranges. However, there is only one type of example (OFCOM/ETSI >>> specific) that is provided throughout the document. I think we need to = add >>> another set of example that is FCC specific. >>> >>> >>> Would something like this below suffice for the FCC specific example? >>> >>> =E2=80=9CresolutionBwHz=E2=80=9D: 1e5, >>> >>> =E2=80=9Cprofiles=E2=80=9D: [ >>> >>> { >>> >>> "Hz": 5.18e8, >>> >>> "Hz": 5.24e8, >>> >>> =E2=80=9Cdbm=E2=80=9D: 24 >>> >>> ] }, >>> >>> >>> >>> >> Ah. I see. We can add a single resolution-bandwidth example for >> completeness. >> >> -- >>> This message is subject to the CSIR's copyright terms and conditions, >>> e-mail legal notice, and implemented Open Document Format (ODF) standar= d. >>> The full disclaimer details can be found at >>> http://www.csir.co.za/disclaimer.html. >>> >> >> This message has been scanned for viruses and dangerous content by >> *MailScanner* , >> and is believed to be clean. >> >> >> Please consider the environment before printing this email. >> >> -- >> This message is subject to the CSIR's copyright terms and conditions, >> e-mail legal notice, and implemented Open Document Format (ODF) standard= . >> The full disclaimer details can be found at >> http://www.csir.co.za/disclaimer.html. >> >> >> This message has been scanned for viruses and dangerous content by >> *MailScanner* , >> and is believed to be clean. >> >> >> Please consider the environment before printing this email. >> >> > > > -- > -vince > > -- > This message is subject to the CSIR's copyright terms and conditions, > e-mail legal notice, and implemented Open Document Format (ODF) standard. > The full disclaimer details can be found at > http://www.csir.co.za/disclaimer.html. > > > This message has been scanned for viruses and dangerous content by > *MailScanner* , > and is believed to be clean. > > > Please consider the environment before printing this email. > > > -- > This message is subject to the CSIR's copyright terms and conditions, > e-mail legal notice, and implemented Open Document Format (ODF) standard. > The full disclaimer details can be found at > http://www.csir.co.za/disclaimer.html. > > > This message has been scanned for viruses and dangerous content by > *MailScanner* , > and is believed to be clean. > > > Please consider the environment before printing this email. > > --=20 -vince --089e0163509452cb8b050074003c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Luzango,

Please see Section 9.1.2.1 = for additional requirements on the DeviceOwner fields for FCC rules. There&= #39;s a table that describes the required fields that must appear for "= ;owner" and "operator".

We did not want to make any restrictions in the core PA= WS spec.

Also, RFC 6350 defines what the types are= for each field, e.g., "fn" is "a single text value" (S= ection 6.2.1) and "adr" is a structured text value of 7 component= s (Section 6.3.1).


-vince


On Mon, Aug 11, 2014 at 8:18 AM, L= uzango Mfupe <LMfupe@csir.co.za> wrote:
Hi Vince,
=C2=A0
Thanks for prompt=C2=A0clarifications however,=C2=A0my=C2=A0suggestion= is that the data type of vCard fragments (the device owner part and the de= vice operator part)=C2=A0as a whole should be explicitly stated in section = 5.5. Here I am not talking about the data types of individual=C2=A0paramete= rs inside the vCard itself. This will indeed help to preserve the integrity= of card formatting when they are being parsed by different applications=C2= =A0as well as=C2=A0promote uniformity in different PAWS implementations.
=C2=A0
Kind Regards,
Luzango.

>>> Vincent Chen <vchen@google.com> 11/08/2014 16:42 >= ;>>
Hi Luzango,


On Mon, Aug 11, 2014 at 5:50 AM, Luzango Mfupe <= span dir=3D"ltr"><LMfupe@csir.co.za> wrote:
Hi Vince, Folks,
It seems the issue of adding the single-resolu= tion bandwidth example slipped off the cracks some how as it was supposed t= o be included in the current draft.

Please see the first example in Section 5.11, which was added based on= your suggestion.
Today I am presenting another burning issue re= levant to the following Sections:
SECTION 5.5 DeviceOwner
SECTION 6.4 Example Encoding Device Owner vCar= d
Can you please elaborate how the device owner = jcard/vCard fragments should be handled within the JSON registration reques= t message body; what primitive type(s) should be applied( i.e, String, int = etc...). Apparently there is already a great deal of confusion in this area= as some would thinks the card fragments should just be sent as-it-is in an= array format with the rest of the JSON registration request body
To the best of my understanding jcards are sup= posed to be written as String primitive types this allows to preserve the f= ormatting when they are parse/read by the spectrum database/server or any o= ther application that would wish to extract the contact information in a st= andardised format.
Section 5.5 is silent on the definition of vCa= rd data type(s), while the example provided in Section 6.4 shows the vCard = in an array.
May I suggest that we should also explicitly s= tate the data type of jcard similar to the way we have defined data types f= or other aspects throughout the document (e.g., In Section 5.2 Device Descr= iptor)...In doing so this will clear any future confusions in the implement= ation of our standard.

Actually, Section 6.4 is the jCard representation and was intended to = provide the clarification you're asking for.
Perhaps it needs a better intro sentence?

Since Sections 4 and 5 define new data models for PAWS, we provide a m= apping from those data models to JSON.
On the other hand, we are not redefining vCard and jCard, so it seemed= redundant to repeat their definitions.

-vince

Kind Regards,
Luzango.


>>> Vincent Chen <vchen@google.com> 28/07/2014 18:54 >>>= ;
Hi Luzango,=20

Thanks for your suggestions.


On Sat, Jul 26, 2014 at 9:51 AM, Luzango Mfupe <= span dir=3D"ltr"><lmfupe@csir.co.za> wrote:
Hi Vince, Folks,= =20

I am glad to see things are moving to the right direction and ho= pefully soon we will finalise this work.

I just found some few not very critical issues that needs some f= ixing in in my opinion:

<= font color=3D"#0000ff" face=3D"Courier New, monospace">5.11. Spectrum


Here the document talk about the FCC and OFCOM/ETSI spectral profile= presentation requirements (i.e, power levels over a set of frequency ranges. However, there is only one type o= f example (OFCOM/ETSI specific) that is provided throughout the document. I= think we need to add another set of example that is FCC specific. <= /font>

Would something like= this below suffice for the FCC specific example?

=E2=80=9CresolutionBwHz=E2=80=9D: 1e5,

=E2=80=9Cprofiles=E2=80=9D: [

{

"Hz": 5.18e8,

"Hz": 5.24e8,

=E2=80=9Cdbm=E2=80=9D: 24

] },




Ah. I see. We can add a single resolution-bandwidth example for comple= teness.

--
= This message is subject to the CSIR's copyright terms and conditions, e= -mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html<= /a>.


This message has been scanned for viruses and dangerous content by <= a href=3D"http://www.mailscanner.info/" target=3D"_blank">MailScanner,
and is believed to be clean.


Please consider the environment before printing this email.


--
This message is subject to the CSIR's copyrigh= t terms and conditions, e-mail legal notice, and implemented Open Document = Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html<= /a>.=20


This message has been scanned for viruses and dangerous content by <= a href=3D"http://www.mailscanner.info/" target=3D"_blank">MailScanner,
and is believed to be clean.


Please consider the environment before printing this email.




--
-vince

--
This message is subject to the CSIR= 's copyright terms and conditions, e-mail legal notice, and implemented= Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html<= /a>.=20


This message has been scanned for viruses and dangerous content by <= a href=3D"http://www.mailscanner.info/" target=3D"_blank">MailScanner,
and is believed to be clean.=20


Please consider the environment before printing this email.

=


--=20
This message is subject to the CSIR's copyright terms and condition= s, e-mail legal notice, and implemented Open Document Format (ODF) standard= .
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.h= tml.


This message has been scanned for viruses and dangerous content by MailScanner,=20
and is believed to be clean.


Please consider the environment before printing this email.




--
-vince
--089e0163509452cb8b050074003c-- From nobody Tue Aug 19 18:53:58 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9241A6F30 for ; Tue, 19 Aug 2014 18:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.669 X-Spam-Level: X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKS-a-Dm-EAU for ; Tue, 19 Aug 2014 18:53:55 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448551A6EEA for ; Tue, 19 Aug 2014 18:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408499635; x=1440035635; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=nLV81XiVKm4Le2dB5yM6kjVhBgSXevD3o5ku4bIxUxg=; b=H0xn89krRy5FkMcFjzd4y9oys8jlXAcQcYleIloVDLaN/K5A41mSnB9r T6mnAt0jg6Bbcfi/0ahHGbOvvCgjMMcIz7KhOPXcpKeJkS0iU/sen5sSq xS80ZSguvpbGG0qDJGz65+42LVICpg13gmud2LNwuvFLPD00ACoTh4WUr Y=; X-IronPort-AV: E=McAfee;i="5600,1067,7535"; a="150689459" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 19 Aug 2014 18:53:54 -0700 X-IronPort-AV: E=Sophos;i="5.01,898,1400050800"; d="scan'208";a="694856804" Received: from nasanexhc14.na.qualcomm.com ([172.30.48.23]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2014 18:53:54 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc14.na.qualcomm.com (172.30.48.23) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:53:54 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:53:53 -0700 Message-ID: <53F3FFAF.8090703@qti.qualcomm.com> Date: Tue, 19 Aug 2014 20:53:51 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/-v6l5DTQpOJsRaajpqartXN9-xo Subject: [paws] Messages not being copied to list X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 01:53:57 -0000 My apologies, but when I did the second Last Call, somehow the notification field in the tracker removed the copy to the WG mailing list. I'm about to forward a bunch of mail from the past week. If you wish to reply, please do so to the original From/To/Cc. As always, keep in mind that it is IESG review week, so please minimize the messages that the IESG has to read: Allow the document author or the chairs to address issues first, and only follow up if you think they have missed something. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Aug 19 18:54:58 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9680C1A6F71 for ; Tue, 19 Aug 2014 18:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.669 X-Spam-Level: X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me77VthF2uZx for ; Tue, 19 Aug 2014 18:54:55 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8880A1A6F54 for ; Tue, 19 Aug 2014 18:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408499695; x=1440035695; h=message-id:date:from:mime-version:to:subject; bh=Fgigi+UeH/sabdUC70qZ7yvlMw66W8ie0fppuQlyro0=; b=nlf7KcgoaRxKfyYm274qBIRmNcs1aTm1hrITRr3wSi1BwfR7CDZ44AxN 1IZZsKQ7lhnEzo3M4pyDot0AjR8sZrYGqzwT2BXiGyC1SjFPOFpoEunDC ZszmjO2eIrxlQlGHixwC6L3QbIAJzgYRQPRibVeNMzmELScRz0zQuy7P7 Y=; X-IronPort-AV: E=McAfee;i="5600,1067,7535"; a="150689654" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine02.qualcomm.com with ESMTP; 19 Aug 2014 18:54:55 -0700 X-IronPort-AV: E=Sophos;i="5.01,898,1400050800"; d="eml'208?scan'208,208";a="31112856" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2014 18:54:54 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:54:54 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:54:53 -0700 Message-ID: <53F3FFED.1040503@qti.qualcomm.com> Date: Tue, 19 Aug 2014 20:54:53 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "paws@ietf.org" Content-Type: multipart/mixed; boundary="------------000808090901050507050208" X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/rnWc41m6CzEdYah3dnrxUEYGXNY Subject: [paws] Fwd: Barry Leiba's Yes on draft-ietf-paws-protocol-14: (with COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 01:54:57 -0000 --------------000808090901050507050208 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit --------------000808090901050507050208 Content-Type: message/rfc822; name="Barry Leiba's Yes on draft-ietf-paws-protocol-14: (with COMMENT).eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Barry Leiba's Yes on draft-ietf-paws-protocol-14: (with COMM"; filename*1="ENT).eml" Return-Path: X-Original-To: presnick@dev-presnick.qualcomm.com Delivered-To: presnick@dev-presnick.qualcomm.com Received: from Ironmsg03-R.qualcomm.com (ironmsg03-R.qualcomm.com [172.30.46.17]) by dev-presnick.qualcomm.com (Postfix) with ESMTPS id EF3053F84A for ; Thu, 14 Aug 2014 08:41:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,863,1400050800"; d="scan'208";a="731574453" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Aug 2014 08:41:45 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 14 Aug 2014 08:41:45 -0700 Resent-From: Received: from Ironmsg04-L.qualcomm.com (172.30.48.1) by nasanexhc05.na.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 14 Aug 2014 08:31:40 -0700 X-IronPort-AV: E=Sophos;i="5.01,863,1400050800"; d="scan'208";a="691713515" X-ojodefuego: yes X-Forgery: (qualnet-external) Received: from gatewayhorse2.qualcomm.com ([199.106.114.132]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Aug 2014 08:31:41 -0700 Received-SPF: Pass (gatewayhorse2.qualcomm.com: domain of iesg-bounces@ietf.org designates 4.31.198.44 as permitted sender) identity=mailfrom; client-ip=4.31.198.44; receiver=gatewayhorse2.qualcomm.com; envelope-from="iesg-bounces@ietf.org"; x-sender="iesg-bounces@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" Authentication-Results: gatewayhorse2.qualcomm.com; dkim=pass (signature verified) header.i=@ietf.org X-SLBL-Result: SAFE-LISTED X-IronPort-AV: E=McAfee;i="5600,1067,7529"; a="232469195" X-DMARC-Status: PASS X-IPAS-Result: AtUJAJLV7FMEH8Ysm3poAFmCanZXgnqIUcICGgqIYBYBDwEBAQEBCAkLCRQphAcEAiAdAQEECikBAgMBAgYCJAIiBAICAwFDFhgEiDoCCq8od4UCAQWBfI4+EQaBLI0+EQGDDw8yEoFBhhWFDoV/V4NPhnUBgVeKKox5TAGBDoFAAQEB Received: from mail.ietf.org ([4.31.198.44]) by gatewayhorse2.qualcomm.com with ESMTP; 14 Aug 2014 08:31:40 -0700 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B5D1A6F0B; Thu, 14 Aug 2014 08:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1408030300; bh=QFIb8bhvabJIZNQ2s2lTUHcjp7iPHsnsf97qwvZPbA8=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: Subject:Message-ID:Date:Cc:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Sender; b=WyInmAv03HN1nyZPUBm2ty2Yal0ZLggOWVDOEuvkk36oEopGJ73fGe4bFHYdabnhG tFq3FXR7+QD/yLZiJJuO/RLAk5vbF7WRCdzSAMS4BI73hSZO3XcNxjgQHI/4ldwvHK zi7hy2yv3AuuqEYgn0ETPaVjqQ0201vzNSa4jsrY= X-Original-To: iesg@ietfa.amsl.com Delivered-To: iesg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF851A6F0B for ; Thu, 14 Aug 2014 08:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLfP0zp1DVRm; Thu, 14 Aug 2014 08:31:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB201A04E7; Thu, 14 Aug 2014 08:31:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba To: The IESG Subject: Barry Leiba's Yes on draft-ietf-paws-protocol-14: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140814153137.21470.81530.idtracker@ietfa.amsl.com> Date: Thu, 14 Aug 2014 08:31:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/iesg/7YP6lTJBYn-yDI-o7BZtptVgrNE CC: , X-BeenThere: iesg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iesg-bounces@ietf.org Sender: iesg Barry Leiba has entered the following ballot position for draft-ietf-paws-protocol-14: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Vince handled all my comments during last call, and I'm happy with this version. Thanks, especially, for all the work that went into re-doing Section 6. --------------000808090901050507050208-- From nobody Tue Aug 19 18:55:21 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2741A6F73 for ; Tue, 19 Aug 2014 18:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.668 X-Spam-Level: X-Spam-Status: No, score=-7.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u69rsdY9-PFZ for ; Tue, 19 Aug 2014 18:55:18 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79ED31A6F71 for ; Tue, 19 Aug 2014 18:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408499718; x=1440035718; h=message-id:date:from:mime-version:to:subject; bh=dfF3KCn71xMELvyIid5c3PovRkcMeETxkdrLmc8fX/c=; b=ylJEhJTcOjGHPGeWygsI0n2a68DBAaEXUCS+0RjX1H1yDoY6yBsBTVPj P5pqVXjTTEBgxbhWGiKVit7AbWkbsD+iOWQ9PlLlF+8xwMHhCnvamoPds b6TD36x13JOggWTmo1CWzkvX2cl/DfxzxsDPc8FqGKDJV4eUnzmN9Rxol E=; X-IronPort-AV: E=McAfee;i="5600,1067,7535"; a="150689733" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 19 Aug 2014 18:55:18 -0700 X-IronPort-AV: E=Sophos;i="5.01,898,1400050800"; d="eml'208?scan'208,208,217";a="694857119" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2014 18:55:18 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc07.na.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:55:17 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:55:17 -0700 Message-ID: <53F40004.5050602@qti.qualcomm.com> Date: Tue, 19 Aug 2014 20:55:16 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "paws@ietf.org" Content-Type: multipart/mixed; boundary="------------070408050404020306010309" X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/j4kPCAyz_OayLtb_Y8MlPE6_rDU Subject: [paws] Fwd: Secdir Review of draft-ietf-paws-protocol X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 01:55:20 -0000 --------------070408050404020306010309 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit --------------070408050404020306010309 Content-Type: message/rfc822; name="Secdir Review of draft-ietf-paws-protocol.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Secdir Review of draft-ietf-paws-protocol.eml" Return-Path: X-Original-To: presnick@dev-presnick.qualcomm.com Delivered-To: presnick@dev-presnick.qualcomm.com Received: from Ironmsg03-L.qualcomm.com (ironmsg03-L.qualcomm.com [172.30.48.18]) by dev-presnick.qualcomm.com (Postfix) with ESMTPS id F409B3F84A for ; Tue, 8 Jul 2014 09:10:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,625,1400050800"; d="scan'208,217";a="695433954" Received: from nasanexhc17.na.qualcomm.com ([10.45.158.129]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Jul 2014 09:10:49 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC17.na.qualcomm.com (10.45.158.129) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 8 Jul 2014 09:10:48 -0700 Resent-From: Received: from Ironmsg04-R.qualcomm.com (172.30.48.1) by nasanexhc05.na.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 8 Jul 2014 09:10:47 -0700 X-IronPort-AV: E=Sophos;i="5.01,625,1400050800"; d="scan'208,217";a="763118043" X-ojodefuego: yes X-Forgery: (qualnet-external) Received: from gatewayhorse2.qualcomm.com ([199.106.114.132]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2014 09:10:48 -0700 Received-SPF: Pass (gatewayhorse2.qualcomm.com: domain of iesg-bounces@ietf.org designates 4.31.198.44 as permitted sender) identity=mailfrom; client-ip=4.31.198.44; receiver=gatewayhorse2.qualcomm.com; envelope-from="iesg-bounces@ietf.org"; x-sender="iesg-bounces@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" Authentication-Results: gatewayhorse2.qualcomm.com; dkim=pass (signature verified) header.i=@ietf.org X-SLBL-Result: SAFE-LISTED X-IronPort-AV: E=McAfee;i="5600,1067,7492"; a="225724778" X-DMARC-Status: PASS X-IPAS-Result: AjcBAKgXvFMEH8Ysm3poAE8HA4JHI8AwHgGHSIEYFg8BAQEBAQYLCwkUKIQHBAI9AQEECikBAgMBAgUBAg46CAMBF0MSBYg9AQKvLIV5AQWUNhEGBI5cBgsBJESCJQ9EJIEWsmZQgQs Received: from mail.ietf.org ([4.31.198.44]) by gatewayhorse2.qualcomm.com with ESMTP; 08 Jul 2014 09:10:44 -0700 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 554861B2B85; Tue, 8 Jul 2014 09:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1404835844; bh=aqnZhKdmBxxIKvjaTcaq/e17rzsSAy5EqWpReMKfGYU=; h=From:Content-Type:Subject:Date:Message-Id:To:Mime-Version:Cc: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Sender; b=bvZoXa7y+IRmNlXZTIS6fU+OFQEUWZqNto1XUwUwIbiBw4W0hqApBJyABUWgmyfya WmmOz7uo1zGdjw0ZTKU+PjZVe8IhyboP5EEEszMPxvHKRRbmIarSAj/3bHChck/DBJ x8UdmN4BTRtiWJNrOd8g59yxRogK9BmuvbFt9TVo= X-Original-To: iesg@ietfa.amsl.com Delivered-To: iesg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960711B2B62; Tue, 8 Jul 2014 09:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oh1eigVu2RO; Tue, 8 Jul 2014 09:10:39 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [132.250.118.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C991A0104; Tue, 8 Jul 2014 09:10:38 -0700 (PDT) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id s68GAaff018786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2014 12:10:37 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_B320056C-9B0B-4F4A-81E7-FDCDAB379C9E" Subject: Secdir Review of draft-ietf-paws-protocol Date: Tue, 8 Jul 2014 12:10:36 -0400 Message-ID: To: , , MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: http://mailarchive.ietf.org/arch/msg/iesg/LhOYfaxVKoPVQE921itu7dmvxrI CC: Catherine Meadows X-BeenThere: iesg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iesg-bounces@ietf.org Sender: iesg --Apple-Mail=_B320056C-9B0B-4F4A-81E7-FDCDAB379C9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This ID describes a protocol, PAWS, that allows wireless devices to = access currently unused portions of the radio spectrum. The protocol works between a geospatial database and a device with = geolocation capabilities. The device reports its location and other relevant information to the database, which in turns gives it = information about which portions of the spectrum is available to it. This removes the responsibility for managing the complex information = about spectrum available from the device and to the database, which is better equipped to handle it. =20 The ID has a very thorough and well-written Security Considerations = section, which covers the security threats against such a protocol. = They identify two main threats By using the PAWS protocol, the Master Device and the Database expose themselves to the following risks: o Accuracy: The Master Device receives incorrect spectrum availability information. o Privacy: An unauthorized entity intercepts identifying data for the Master Device or its Slave Devices, such as serial number and location. Note that core PAWS does not address client authentication, on the = grounds that unauthorized clients could find out the existence of white space on their own without the help of PAWS, and in that case there = would be nothing preventing them from using it. The ID does point out = though that client authentication may be required by specific regulatory = domains, and so it is possible for the Database to require client authentication, = e.g. by TLS. The authors appropriately point out the limitations of = using TLS for authentication, particularly when the keys are trusted to small ubiquitous devices. =20 I believe this draft is ready. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail=_B320056C-9B0B-4F4A-81E7-FDCDAB379C9E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
I have reviewed this document as part of = the security directorate's 
ongoing effort to review all = IETF documents being processed by the 
IESG.  These = comments were written primarily for the benefit of = the 
security area directors.  Document editors and = WG chairs should treat 
these comments just like any = other last call comments.


This = ID describes a protocol, PAWS,  that allows wireless devices to = access currently unused portions of the radio spectrum.
The protocol = works between a geospatial database and a device with geolocation = capabilities.  The device reports its location
and other = relevant information to the database, which in turns gives it = information about which portions of the spectrum is available to = it.
This removes the responsibility for managing the complex = information about spectrum available from the device and to the = database,
which is better equipped to handle it. =  

The ID has a very thorough and = well-written Security Considerations section, which  covers the = security threats against such a protocol.  They identify = two
main threats

 By using the = PAWS protocol, the Master Device and the Database expose
themselves = to the following risks:
o Accuracy: The Master Device receives = incorrect spectrum availability
information.
o Privacy: An = unauthorized entity intercepts identifying data for
the Master Device = or its Slave Devices, such as serial number = and
location.

Note that core PAWS does not = address client authentication, on the grounds that unauthorized clients = could find out the existence of white
space on their own = without the help of PAWS, and in that case there would be nothing = preventing them from using it. The ID does point out though that client = authentication may be required by specific regulatory = domains,
and so it is possible for the Database to require = client authentication, e.g. by TLS.  The authors appropriately = point out the limitations of using TLS for authentication, = particularly
when the keys are trusted to small ubiquitous = devices.   

I believe this draft is = ready.


= --Apple-Mail=_B320056C-9B0B-4F4A-81E7-FDCDAB379C9E-- --------------070408050404020306010309-- From nobody Tue Aug 19 18:55:42 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC6C1A6F96 for ; Tue, 19 Aug 2014 18:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.668 X-Spam-Level: X-Spam-Status: No, score=-7.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IF281bY9R0HI for ; Tue, 19 Aug 2014 18:55:32 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4AB1A6FE0 for ; Tue, 19 Aug 2014 18:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408499732; x=1440035732; h=message-id:date:from:mime-version:to:subject; bh=YXyTq7xl4WAslrJ/h+lO6QI9LI5vfAATHex2YCxxBSM=; b=wmoDazbK/u/ZzC6CQGP98Oy4SEzzD+i8N+8NwVjbtkJeeK8yYvpGt8bg zwgtZwxciiIDKT49mwlfSAGChJ390FiiKsc2HO/O6egv6TvsvdMc6ICQ+ 9Y77GdDt2g//8jylOO2cgLV9l2Mv3DIzzZgCcQ+IEr+jh/cikBq53Xalr o=; X-IronPort-AV: E=McAfee;i="5600,1067,7535"; a="72558104" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP; 19 Aug 2014 18:55:31 -0700 X-IronPort-AV: E=Sophos;i="5.01,898,1400050800"; d="eml'208?scan'208,208,217";a="720167388" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2014 18:55:31 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:55:31 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:55:30 -0700 Message-ID: <53F40011.5020402@qti.qualcomm.com> Date: Tue, 19 Aug 2014 20:55:29 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "paws@ietf.org" Content-Type: multipart/mixed; boundary="------------020806030906080109000701" X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/7jsQDYzJAocDniRTe-bmgbhmMQI Subject: [paws] Fwd: Secdir Review of draft-ietf-paws-protocol-14 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 01:55:34 -0000 --------------020806030906080109000701 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit --------------020806030906080109000701 Content-Type: message/rfc822; name="Secdir Review of draft-ietf-paws-protocol-14.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Secdir Review of draft-ietf-paws-protocol-14.eml" Return-Path: X-Original-To: presnick@dev-presnick.qualcomm.com Delivered-To: presnick@dev-presnick.qualcomm.com Received: from Ironmsg03-R.qualcomm.com (ironmsg03-R.qualcomm.com [172.30.46.17]) by dev-presnick.qualcomm.com (Postfix) with ESMTPS id 3FF2E3F84A for ; Fri, 15 Aug 2014 13:51:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,872,1400050800"; d="scan'208,217";a="732340436" Received: from nasanexhc03.na.qualcomm.com ([10.46.56.181]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Aug 2014 13:51:41 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC03.na.qualcomm.com (10.46.56.181) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 15 Aug 2014 13:51:41 -0700 Resent-From: Received: from Ironmsg03-L.qualcomm.com (172.30.48.1) by nasanexhc05.na.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 15 Aug 2014 13:51:40 -0700 X-IronPort-AV: E=Sophos;i="5.01,872,1400050800"; d="scan'208,217";a="717904034" X-ojodefuego: yes X-Forgery: (qualnet-external) Received: from gatewaypony01.qualcomm.com ([65.197.215.24]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Aug 2014 13:51:42 -0700 Received-SPF: Pass (gatewaypony01.qualcomm.com: domain of iesg-bounces@ietf.org designates 4.31.198.44 as permitted sender) identity=mailfrom; client-ip=4.31.198.44; receiver=gatewaypony01.qualcomm.com; envelope-from="iesg-bounces@ietf.org"; x-sender="iesg-bounces@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" Authentication-Results: gatewaypony01.qualcomm.com; dkim=pass (signature verified) header.i=@ietf.org X-SLBL-Result: SAFE-LISTED X-IronPort-AV: E=McAfee;i="5600,1067,7531"; a="133612632" X-DMARC-Status: PASS X-IPAS-Result: AucBAAty7lMEH8Ysm3poAE8HA4JHI7gclx0cAYdhgRQWAQ8BAQEBAQgJCwkUKYQDAQEBAQIBAQI9AQEECikBAgIBAQIFAQEBIiYIAwEXPAcSBYg1CAECrU6FeQEFkBkRBgSOZgYLASREgicPRCSBHY8Sgw6jGFABgQ6BQAEBAQ Received: from mail.ietf.org ([4.31.198.44]) by gatewaypony01.qualcomm.com with ESMTP; 15 Aug 2014 13:51:40 -0700 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EED241A064E; Fri, 15 Aug 2014 13:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1408135900; bh=uOj3dz8LWn44w2DbYH9ZmWjPbOeAUrXrAEOGkz1voEI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Message-Id:References:To:Cc:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Sender; b=w4YqZu6iEpNN4mbpvrMjLdVsS02zSuPSHqIEpQxaGVCR57Y4mgl+UCgr+YbcbJaDX yGquWLLZaEJ1eSDKrz6R7pdDuyjHx5SjKVaNuXsx3o6Ec2bkX1t8y1S0y5w/zmF5oz xkqJLfmzYCsPAY7yRRnBiAUUOziu8bZwk8JfK7nY= X-Original-To: iesg@ietfa.amsl.com Delivered-To: iesg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759721A06C7; Fri, 15 Aug 2014 13:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.267 X-Spam-Level: X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6YSF3YAHzDm; Fri, 15 Aug 2014 13:51:34 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [132.250.118.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BB11A06C6; Fri, 15 Aug 2014 13:51:33 -0700 (PDT) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id s7FKpVYW011389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 Aug 2014 16:51:31 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_6BB4887E-10C4-482A-B607-92DB2E46D30A" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Secdir Review of draft-ietf-paws-protocol-14 From: Catherine Meadows In-Reply-To: Date: Fri, 15 Aug 2014 16:51:31 -0400 Message-ID: <4C83FE05-DABB-40F1-A544-7E8FE54B2605@nrl.navy.mil> References: To: , , X-Mailer: Apple Mail (2.1878.6) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: http://mailarchive.ietf.org/arch/msg/iesg/R82wS_k0WUsjTV3RGCv-XGO4nd8 CC: Catherine Meadows X-BeenThere: iesg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iesg-bounces@ietf.org Sender: iesg --Apple-Mail=_6BB4887E-10C4-482A-B607-92DB2E46D30A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This ID describes a protocol, PAWS, that allows wireless devices to = access currently unused portions of the radio spectrum. The protocol works between a geospatial database and a device with = geolocation capabilities. The device reports its location and other relevant information to the database, which in turns gives it = information about which portions of the spectrum is available to it. This removes the responsibility for managing the complex information = about spectrum available from the device and to the database, which is better equipped to handle it. I previously reviewed version 12 = of this ID, and although some changes and additions have been made to = the Security Considerations section, they are minor and do not change my previous review, which ran = as follows: The ID has a very thorough and well-written Security Considerations = section, which covers the security threats against such a protocol. = They identify two main threats By using the PAWSl, the Master Device and the Database expose themselves to the following risks: o Accuracy: The Master Device receives incorrect spectrum availability information. o Privacy: An unauthorized entity intercepts identifying data for the Master Device or its Slave Devices, such as serial number and location. Note that core PAWS does not address client authentication, on the = grounds that unauthorized clients could find out the existence of white space on their own without the help of PAWS, and in that case there = would be nothing preventing them from using it. The ID does point out = though that client authentication may be required by specific regulatory = domains, and so it is possible for the Database to require client authentication, = e.g. by TLS. The authors appropriately point out the limitations of = using TLS for authentication, particularly when the keys are trusted to small ubiquitous devices. =20 I believe this draft is ready. Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil On Jul 8, 2014, at 12:17 PM, Catherine Meadows = wrote: > I am resending this, because I got one of the email addresses wrong. >=20 > Cathy >=20 >=20 > Catherine Meadows > Naval Research Laboratory > Code 5543 > 4555 Overlook Ave., S.W. > Washington DC, 20375 > phone: 202-767-3490 > fax: 202-404-7942 > email: catherine.meadows@nrl.navy.mil >=20 > On Jul 8, 2014, at 12:10 PM, Catherine Meadows = wrote: >=20 >>=20 >>=20 >>=20 >> Catherine Meadows >> Naval Research Laboratory >> Code 5543 >> 4555 Overlook Ave., S.W. >> Washington DC, 20375 >> phone: 202-767-3490 >> fax: 202-404-7942 >> email: catherine.meadows@nrl.navy.mil >>=20 >=20 --Apple-Mail=_6BB4887E-10C4-482A-B607-92DB2E46D30A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" I have = reviewed this document as part of the security = directorate's 
ongoing effort to review all IETF documents being = processed by the 
IESG.  These comments were written = primarily for the benefit of the 
security area directors. =  Document editors and WG chairs should treat 
these = comments just like any other last call comments.


This ID = describes a protocol, PAWS,  that allows wireless devices to access = currently unused portions of the radio spectrum.
The protocol works = between a geospatial database and a device with geolocation = capabilities.  The device reports its location
and other = relevant information to the database, which in turns gives it = information about which portions of the spectrum is available to = it.
This removes the responsibility for managing the complex = information about spectrum available from the device and to the = database,
which is better equipped to handle it.  I previously = reviewed version 12 of this ID, and although some changes and additions = have been made to the Security Considerations
section, they are = minor and do not change my previous review, which ran as = follows:

The ID has a very thorough and well-written Security = Considerations section, which  covers the security threats against = such a protocol.  They identify two
main threats

 By = using the PAWSl, the Master Device and the Database expose
themselves = to the following risks:

o Accuracy: The Master Device = receives incorrect spectrum availability
information.
o Privacy: = An unauthorized entity intercepts identifying data for
the Master = Device or its Slave Devices, such as serial number = and
location.

Note that core PAWS does not address client = authentication, on the grounds that unauthorized clients could find out = the existence of white
space on their own without the help of PAWS, = and in that case there would be nothing preventing them from using it. = The ID does point out though that client authentication may be required = by specific regulatory domains,
and so it is possible for the = Database to require client authentication, e.g. by TLS.  The = authors appropriately point out the limitations of using TLS for = authentication, particularly
when the keys are trusted to small = ubiquitous devices.   

I believe this draft is = ready.
Catherine Meadows
Naval = Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil

On Jul 8, 2014, at 12:17 PM, Catherine Meadows <catherine.meadows@nrl.navy.= mil> wrote:

I am resending this, because I = got one of the email addresses = wrong.

Cathy


Catherine Meadows
Naval Research Laboratory
Code = 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: = 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.= mil

On Jul 8, 2014, at 12:10 PM, Catherine Meadows <catherine.meadows@nrl.navy.= mil> wrote:




Catherine Meadows
Naval = Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil
=


= = --Apple-Mail=_6BB4887E-10C4-482A-B607-92DB2E46D30A-- --------------020806030906080109000701-- From nobody Tue Aug 19 18:56:01 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B2B1A6FB4 for ; Tue, 19 Aug 2014 18:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.669 X-Spam-Level: X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-sK3c5b1Cm7 for ; Tue, 19 Aug 2014 18:55:50 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24B4A1A6F7C for ; Tue, 19 Aug 2014 18:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408499751; x=1440035751; h=message-id:date:from:mime-version:to:subject; bh=wib8zwF27R5BHRNk5LLL8HBdOsMcNcxv5A/e42iJW4w=; b=tu4zsWbqf2Qqa0MqhC0an5B7x/RZF40Rd+5QzyYp4KgOaiauGc1LMil6 4dqDCmYRXcc97FN0Q7sY4w9kMZT7GaRLPlHYydWNKiABtEx2dQu8iMiMK TvFuWAJTqIHamaL6dcasaxg/opT5+5taEl+4qtN1oAEv70j2t7hakDnAZ k=; X-IronPort-AV: E=McAfee;i="5600,1067,7535"; a="59184997" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine01.qualcomm.com with ESMTP; 19 Aug 2014 18:55:51 -0700 X-IronPort-AV: E=Sophos;i="5.01,898,1400050800"; d="eml'208?scan'208,208";a="30399368" Received: from nasanexhc17.na.qualcomm.com ([10.45.158.129]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2014 18:55:49 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC17.na.qualcomm.com (10.45.158.129) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:55:48 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:55:48 -0700 Message-ID: <53F40023.1070101@qti.qualcomm.com> Date: Tue, 19 Aug 2014 20:55:47 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "paws@ietf.org" Content-Type: multipart/mixed; boundary="------------050406010504050803070801" X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/Cn8MNoxQ97FPhRPNZZrgf7TKVBk Subject: [paws] Fwd: [IANA #775577] Second Last Call: (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 01:55:58 -0000 --------------050406010504050803070801 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit --------------050406010504050803070801 Content-Type: message/rfc822; name="[IANA #775577] Second Last Call: (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="[IANA #775577] Second Last Call: X-Original-To: presnick@dev-presnick.qualcomm.com Delivered-To: presnick@dev-presnick.qualcomm.com Received: from Ironmsg03-L.qualcomm.com (ironmsg03-L.qualcomm.com [172.30.48.18]) by dev-presnick.qualcomm.com (Postfix) with ESMTPS id 759C74074E for ; Thu, 14 Aug 2014 10:27:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,864,1400050800"; d="scan'208";a="717125320" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Aug 2014 10:27:43 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc10.na.qualcomm.com (172.30.48.3) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 14 Aug 2014 10:27:43 -0700 Resent-From: Received: from Ironmsg04-R.qualcomm.com (172.30.48.1) by nasanexhc05.na.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 14 Aug 2014 10:27:39 -0700 X-IronPort-AV: E=Sophos;i="5.01,864,1400050800"; d="scan'208";a="785013091" X-ojodefuego: yes X-Forgery: (qualnet-external) Received: from gatewayhorse1.qualcomm.com ([199.106.114.111]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Aug 2014 10:27:40 -0700 Received-SPF: Pass (gatewayhorse1.qualcomm.com: domain of iesg-bounces@ietf.org designates 4.31.198.44 as permitted sender) identity=mailfrom; client-ip=4.31.198.44; receiver=gatewayhorse1.qualcomm.com; envelope-from="iesg-bounces@ietf.org"; x-sender="iesg-bounces@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" Authentication-Results: gatewayhorse1.qualcomm.com; dkim=pass (signature verified) header.i=@ietf.org X-SLBL-Result: SAFE-LISTED X-IronPort-AV: E=McAfee;i="5600,1067,7530"; a="222375971" X-DMARC-Status: PASS X-IPAS-Result: ApkBAEjw7FMEH8Ysm3poAFmCanZTBIJ6rByeMiAMh0cmchYBDwEBAQEBCAkLCRQphAQBAQEBAgECIA8BDQEBBAoeCwECAwECBgEBIgICEgEMAwQCAgMBKBoBEBkFBIg5AQIFBa9id4UCAQWBd45AEQaBLIRQhiGCTREBLjsBgiUPMg8DgUGGFYsNhCaEHoJYgVeMd4hGgUZsAQEBgQUHF4EpAQEF Received: from mail.ietf.org ([4.31.198.44]) by gatewayhorse1.qualcomm.com with ESMTP; 14 Aug 2014 10:27:38 -0700 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 598BE1A0A7D; Thu, 14 Aug 2014 10:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1408037258; bh=AZDDphO+b6QnwUeySc3almN0zTxEh1jJyRHZ6V5kOWA=; h=Subject:From:In-Reply-To:References:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Sender; b=ikYWlEVJC15t05/8yTAtuL5/xxaOvYbU4KHffDMVGxm8BMsmsEI/inToVJjtDZ9IZ A+SBITrLf5fCd0yzOUEjejcC4Ge55C7yQtr2P1WzBBx7EMLM6ha+ceYh3naZh3P/0a NAdGQWsGW6gL2kozlDIeLCmdBtp8vfjvxHp0vcdM= X-Original-To: iesg@ietfa.amsl.com Delivered-To: iesg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFCF1A6F8C; Thu, 14 Aug 2014 10:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1g9or-cUvMaX; Thu, 14 Aug 2014 10:27:29 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91CB1A6F8B; Thu, 14 Aug 2014 10:27:29 -0700 (PDT) Received: from request1.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id s7EHRTQK017756; Thu, 14 Aug 2014 17:27:29 GMT Received: by request1.lax.icann.org (Postfix, from userid 48) id F0EDE560463; Thu, 14 Aug 2014 17:27:28 +0000 (UTC) RT-Owner: pearl.liang Subject: [IANA #775577] Second Last Call: (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard From: Pearl Liang via RT In-Reply-To: <20140806210932.26762.78438.idtracker@ietfa.amsl.com> References: <20140806210932.26762.78438.idtracker@ietfa.amsl.com> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #775577 Managed-BY: RT 4.0.8 (http://www.bestpractical.com/rt/) RT-Originator: pearl.liang@icann.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Thu, 14 Aug 2014 17:27:28 +0000 Archived-At: http://mailarchive.ietf.org/arch/msg/iesg/FvDfn1V8XVIBk-q1LI6zzkNNCWE CC: , , X-BeenThere: iesg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iesg-bounces@ietf.org Sender: iesg (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-paws-protocol-14. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA has a question for one of the requested actions in this draft document. We received the following comments/questions from the IANA's reviewer: IANA understands that, upon approval of this document there are three actions which IANA must complete. IANA understands that this document proposes the creation of a PAWS protocol registry which will initially consist of three subregistries: - the PAWS Ruleset ID Registry - the PAWS Parameter Registry - the PAWS Error Code Registry On the IANA Matrix located at: http://www.iana.org/protocols the new PAWS registry will be linked with a reference of [ RFC-to-be ]. In the new PAWS registry there will be three sub-registries as follows: First, in the PAWS Registry created above, a new registry called the PAWS Ruleset ID Registry will be created. Each entry in the registry has a ruleset name, additional parameter requirements and a specification. New entires in this registry are done through Specification Required as defined in RFC 5226. There are two initial entries in this new registry as follows: Ruleset identifier: FccTvBandWhiteSpace-2010 Specification: This ruleset refers to the FCC rules for TV-band White Space operations established in the Code of Federal Regulations (CFR), Title 47, Part 15, Subpart H. Additional Parameter Requirements for FccTvBandWhiteSpace-2010: Available Spectrum Request +---------------+-----------------------------+-------------+-------+ | Parameter | Type | Requirement | Notes | | Name | | | | +---------------+-----------------------------+-------------+-------+ | deviceDesc | DeviceDescriptor | REQUIRED | | +---------------+-----------------------------+-------------+-------+ Available Spectrum Batch Request +---------------+-----------------------------+-------------+-------+ | Parameter | Type | Requirement | Notes | | Name | | | | +---------------+-----------------------------+-------------+-------+ | deviceDesc | DeviceDescriptor | REQUIRED | | +---------------+-----------------------------+-------------+-------+ DeviceDescriptor Message +-------------------+--------+-------------+------------------------+ | Parameter Name | Type | Requirement | Notes | +-------------------+--------+-------------+------------------------+ | fccId | string | REQUIRED | Specifies a device's | | | | | FCC certification ID | | fccTvbdDeviceType | string | REQUIRED | Specifies the FCC | | | | | Device Type | | | | | of | | | | | TV-band White Space | | | | | device, as defined by | | | | | the FCC rules. | +-------------------+--------+-------------+------------------------+ DeviceOwner Message +-----------+-------+-----------------------------------------------+ | Parameter | Type | Additional Requirement | | Name | | | +-----------+-------+-----------------------------------------------+ | owner | vCard | The owner is required to contain the formatted| | | | name of an individual or organization using | | | | the "fn" property. When the name is that of an| | | | organization, the entry also is required to | | | | contain the "kind" property, with a value of | | | | "org". | | operator | vCard | The operator entry is required to contain the | | | | following properties for the contact person | | | | responsible for the device's operation: "fn", | | | | "adr", "tel", and "email". | +-----------+-------+-----------------------------------------------+ Ruleset identifier: ETSI-EN-301-598-1.1.1 Specification document(s): This ruleset refers to the ETSI Harmonised Standard [ETSI-EN-301-598] established by ETSI. Additional Parameter Requirements: DeviceDescriptor +-------------------------+-------+-------------+-------------------+ | Parameter Name | Type | Requirement | Notes | +-------------------------+-------+-------------+-------------------+ | manufacturerId | string| REQUIRED | Specifies a | | | | | device's | | | | | manufacturer's | | | | | identifier. See | | | | | [ RFC-to-be ] | | | | | Section 5.2. | | modelId | string| REQUIRED | Specifies a | | | | | device's model | | | | | identifier. See | | | | | [ RFC-to-be ] | | | | | Section 5.2. | | etsiEnDeviceType | string| REQUIRED | Specifies the | | | | | device's ETSI | | | | | device type | | | | | (Section | | | | | 9.2.2.3). | | etsiEnDeviceEmissionsCl | string| REQUIRED | Specifies the | | ass | | | device's ETSI | | | | | device emissions | | | | | class (Section | | | | | 9.2.2.4). | | etsiEnTechnologyId | string| REQUIRED | Specifies the | | | | | device's ETSI | | | | | technology ID | | | | | (Section | | | | | 9.2.2.5). | | etsiEnDeviceCategory | string| REQUIRED | Specifies the | | | | | device's ETSI | | | | | device category | | | | | (Section | | | | | 9.2.2.6). | +-------------------------+-------+-------------+-------------------+ AVAIL_SPECTRUM_REQ +-------------+--------+-------------+------------------------------+ | Parameter | Type | Requirement | Notes | | Name | | | | +-------------+--------+-------------+------------------------------+ | requestType | string | OPTIONAL | Modifies the available- | | | | | spectrum request type. If | | | | | specified, the only valid | | | | | value is, "Generic Slave", | | | | | and the Database is required | | | | | to respond with generic | | | | | operating parameters for any | | | | | Slave Device. | +-------------+--------+-------------+------------------------------+ Available Spectrum Batch Request +-------------+--------+-------------+------------------------------+ | Parameter | Type | Requirement | Notes | | Name | | | | +-------------+--------+-------------+------------------------------+ | requestType | string | OPTIONAL | Modifies the available- | | | | | spectrum request type. If | | | | | specified, the only valid | | | | | value is, "Generic Slave", | | | | | and the Database is required | | | | | to respond with generic | | | | | operating parameters for any | | | | | Slave Device. | +-------------+--------+-------------+------------------------------+ DeviceDescriptor for AVAIL_SPECTRUM_RESP and AVAIL_SPECTRUM_BATCH_RESP messages +--------------------------------+---------+----------+---------------+ | Parameter Name | Type | Requirem | Notes | | | | ent | | +--------------------------------+---------+----------+---------------+ | needsSpectrumReport | boolean | REQUIRED | The Database | | | | | is required | | | | | to set this | | | | | to true to | | | | | indicate that | | | | | the device | | | | | must report | | | | | spectrum | | | | | usage. | | maxTotalBwHz | float | REQUIRED | Specifies a | | | | | constraint on | | | | | total allowed | | | | | bandwidth. | | maxContiguousBwHz | float | REQUIRED | Specifies a | | | | | constraint on | | | | | total allowed | | | | | contiguous | | | | | bandwidth. | | etsiEnSimultaneousChannelOpera | string | REQUIRED | Specifies a | | tionRestriction | | | constraint on | | | | | simultaneous | | | | | channel | | | | | operation | | | | | (Section | | | | | 9.2.2.7). If | | | | | it is not | | | | | provided, the | | | | | default value | | | | | is "0". | +--------------------------------+---------+----------+---------------+ RulesetInfo +-------------------+-------+-------------+-------------------------+ | Parameter Name | Type | Requirement | Notes | +-------------------+-------+-------------+-------------------------+ | maxLocationChange | float | OPTIONAL | Specifies a constraint | | | | | on maximum location | | | | | changes. | +-------------------+-------+-------------+-------------------------+ QUESTION/Note: 1) It appears that this document defines multiple tables for Additional Parameter Requirements for each Ruleset ID entry in the new requested sub-registry "PAWS Ruleset ID Registry" of the new created PAWS protocol registry. How do the authors want the registration information presented in the namespace (aka website)? You can visit the following registry that shows a list of sub-registries for iSCSI Parameters, and more sub-registries under a sub-registry "iSCSI Login Response Status Codes": http://www.iana.org/assignments/iscsi-parameters 2) We understand that "Specification document(s)" is the column for Reference. Second, in the PAWS Registry created above, a new registry called the PAWS Parameter Registry will be created. Each entry in the registry has a parameter name, parameter usage location and a specification. New entires in this registry are done through Specification Required as defined in RFC 5226. There are seven initial entries in this new registry as follows: Parameter name: fccId Parameter usage location: DeviceDescriptor Specification document(s): [ RFC-to-be ] Parameter name: fccTvbdDeviceType Parameter usage location: DeviceDescriptor Specification document(s): [ RFC-to-be ] Parameter name: etsiEnDeviceType Parameter usage location: DeviceDescriptor Specification document(s): Specifies the White Space Device type, as defined by the ETSI Harmonized Standard - [ http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf ] Parameter name: etsiEnDeviceEmissionsClass Parameter usage location: DeviceDescriptor Specification document(s): Specifies the White Space Device emissions class, as defined by the ETSI Harmonized Standard - [ http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf ] Parameter name: etsiEnTechnologyId Parameter usage location: DeviceDescriptor Specification document(s): Specifies the White Space Device technology identifier, as defined by the ETSI Harmonized Standard - [ http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf ] Parameter name: etsiEnDeviceCategory Parameter usage location: DeviceDescriptor Specification document(s): Specifies the White Space Device category, as defined by the ETSI Harmonized Standard - [ http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf ] Parameter name: etsiEnSimultaneousChannelOperationRestriction Parameter usage location: SpectrumSpec Specification document(s): Specifies the constraint on the device maximum total EIRP, as defined by the ETSI Harmonized Standard - [ http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf ] Third, in the PAWS Registry created above, a new registry called the PAWS Error Code Registry will be created. Each entry in the registry has an error code, name, description, additional parameters and reference New entries in this registry are done through Specification Required as defined in RFC 5226. There are new entries in this subregistry, all with a reference of [ RFC-to-be ], as follows: Code Name Description & Additional parameters ------ ---------------- --------------------------------------------- 32767 to 1 Unassigned 0 (reserved) -100 (reserved) -101 VERSION The Database does not support the specified version of the message. -102 UNSUPPORTED The Database does not support the Device. For example, it does not support the ruleset specified in the request. -103 UNIMPLEMENTED The Database does not implement the optional request or optional feature. -104 OUTSIDE_COVERAGE The specified geo-location is outside the coverage area of the Database. The Database MAY include a DbUpdateSpec parameter to provide a list of alternate databases that might be appropriate for the requested location. See OUTSIDE_COVERAGE Error for more details. -105 DATABASE_CHANGE The Database has changed its URI. The Database MAY include a DbUpdateSpec parameter in the error response to provide devices with one or more alternate database URIs. The Device needs to use the information to update its list of preconfigured databases to replace (only) its entry for the responding Database with the list of alternate database URIs. See DATABASE_CHANGE Error for more details. -200 (reserved) -201 MISSING A required parameter is missing. The Database MUST include a list of the required parameter names. The Database MAY include only names of parameters that are missing, but MAY include a full list. Including the full list of missing parameters may reduce the number of re-queries from the Device. See MISSING Error for more details. -202 INVALID_VALUE A parameter value is invalid in some way. The Database SHOULD include a message indicating which parameter and why its value is invalid. -300 (reserved) -301 UNAUTHORIZED The Device is not authorized to used the Database. Authorization may be determined by the ruleset or be dependent on prior arrangement between the Device and Database. -302 NOT_REGISTERED Device registration required, but the Device is not registered. -32000 (reserved) Reserved for JSON-RPC error codes. to -32768 IANA understands that these three actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Wed Aug 06 21:09:57 2014, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the Protocol to Access WS database > WG (paws) to consider the following document: > - 'Protocol to Access White-Space (PAWS) Databases' > as Proposed Standard > > A prior Last Call was made for version -12 of this document. Comments > received during that discussion lead to extensive edits to the document, > which could benefit from a second review. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-08-20. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > Portions of the radio spectrum that are allocated to licensees are > available for non-interfering use. This available spectrum is called > "White Space." Allowing secondary users access to available spectrum > "unlocks" existing spectrum to maximize its utilization and to > provide opportunities for innovation, resulting in greater overall > spectrum utilization. > > One approach to managing spectrum sharing uses databases to report > spectrum availability to devices. To achieve interoperability among > multiple devices and databases, a standardized protocol must be > defined and implemented. This document defines such a protocol, the > "Protocol to Access White Space (PAWS) Databases". > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ballot/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/2203/ > http://datatracker.ietf.org/ipr/2340/ > http://datatracker.ietf.org/ipr/2239/ > > > --------------050406010504050803070801-- From nobody Tue Aug 19 18:56:16 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D711A8032 for ; Tue, 19 Aug 2014 18:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.668 X-Spam-Level: X-Spam-Status: No, score=-7.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s7ithP-KHVe for ; Tue, 19 Aug 2014 18:56:00 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D02C1A6F7C for ; Tue, 19 Aug 2014 18:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408499760; x=1440035760; h=message-id:date:from:mime-version:to:subject; bh=qrFQzRs9a5OQbirLBJh4mZmeJ5tKPWIRsE5xKsTMDOU=; b=b2yQir6Gu/fMZF0RfY7GTkknXaS7w5GojokJtPMfCplcetWr2vuVItlM ktQYCDcdrRPUeJCRBj8pQHSBep6RMA5DXPql0mPaA98UzqpyqlWMIPvx8 EIgeh0Zo5z8pysUdeXq7cBUc+/Lt2MwKydSFXpxxAkNgxN/HwytT7VF7E E=; X-IronPort-AV: E=McAfee;i="5600,1067,7535"; a="73156291" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 19 Aug 2014 18:55:59 -0700 X-IronPort-AV: E=Sophos;i="5.01,898,1400050800"; d="eml'208?scan'208,208";a="31112864" Received: from nasanexhc15.na.qualcomm.com ([129.46.52.215]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2014 18:55:59 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc15.na.qualcomm.com (129.46.52.215) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:55:59 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:55:58 -0700 Message-ID: <53F4002D.3050203@qti.qualcomm.com> Date: Tue, 19 Aug 2014 20:55:57 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "paws@ietf.org" Content-Type: multipart/mixed; boundary="------------060804020405070503010906" X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/DwSQEWl0Cuw2tX5bn_IxqYKByTQ Subject: [paws] Fwd: Re: [IANA #775577] Second Last Call: (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 01:56:13 -0000 --------------060804020405070503010906 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit --------------060804020405070503010906 Content-Type: message/rfc822; name="Re: [IANA #775577] Second Last Call: (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Re: [IANA #775577] Second Last Call: X-Original-To: presnick@dev-presnick.qualcomm.com Delivered-To: presnick@dev-presnick.qualcomm.com Received: from Ironmsg03-L.qualcomm.com (ironmsg03-L.qualcomm.com [172.30.48.18]) by dev-presnick.qualcomm.com (Postfix) with ESMTPS id 21CE23F84A for ; Fri, 15 Aug 2014 11:28:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,872,1400050800"; d="scan'208";a="717815133" Received: from nasanexhc01.na.qualcomm.com ([10.46.57.53]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Aug 2014 11:28:21 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC01.na.qualcomm.com (10.46.57.53) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 15 Aug 2014 11:28:21 -0700 Resent-From: Received: from Ironmsg03-R.qualcomm.com (172.30.48.1) by nasanexhc05.na.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 15 Aug 2014 11:28:19 -0700 X-IronPort-AV: E=Sophos;i="5.01,872,1400050800"; d="scan'208";a="732274257" X-ojodefuego: yes X-Forgery: (qualnet-external) Received: from gatewayhorse2.qualcomm.com ([199.106.114.132]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Aug 2014 11:28:19 -0700 Received-SPF: Pass (gatewayhorse2.qualcomm.com: domain of iesg-bounces@ietf.org designates 4.31.198.44 as permitted sender) identity=mailfrom; client-ip=4.31.198.44; receiver=gatewayhorse2.qualcomm.com; envelope-from="iesg-bounces@ietf.org"; x-sender="iesg-bounces@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" Authentication-Results: gatewayhorse2.qualcomm.com; dkim=pass (signature verified) header.i=@ietf.org X-SLBL-Result: SAFE-LISTED X-IronPort-AV: E=McAfee;i="5600,1067,7531"; a="232665608" X-DMARC-Status: PASS X-IPAS-Result: AlYDAB9Q7lMEH8Ysm3poAFmCanZTCIJ4r1WZXIFBGAELh1YacQgWAQ8BAQEBAQgJCwkUKYQDAQEBAQEBAQECDwgBCB0BAQQKHgsBAgMBAgYBAQgCCw0WAQkBAgMEAgICAQEeEgEFAQsRGQUEGYgYCQIFBZF9kCFqijJ3hQIBBUePUxEGCowTgk0RAS47AYJmgVOGFYURg2yFCYEwhB6CWYFXjHeEPhgpg0eBZkwBAQGBBQcXgSkBAQE Received: from mail.ietf.org ([4.31.198.44]) by gatewayhorse2.qualcomm.com with ESMTP; 15 Aug 2014 11:28:17 -0700 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF83D1A02D4; Fri, 15 Aug 2014 11:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1408127296; bh=YIt8iN8sHmBY+8/ChdqM79IZIIYuvC2Jx3UKGzlr6ME=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type:Cc:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Sender; b=FPgjl7dTzfI/f86wzBtLctSZhbC5aRQ1FWQvpr1uGTjxQkM7OzdtI7SK7u63TKI6Q Z5driaqY02JrnfDP9z3Z/hIYiL/jgwvbh4kNFEUkMvPXomzu0jRFxGC5pQE1hHs3h0 lPGahWBDGz/h5qSSagY6HdMrzUKZBO78Cj2x5Z5s= X-Original-To: iesg@ietfa.amsl.com Delivered-To: iesg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AD51A026C for ; Fri, 15 Aug 2014 11:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mBjkl7843lh for ; Fri, 15 Aug 2014 11:28:06 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2181A02D8 for ; Fri, 15 Aug 2014 11:27:58 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf12so3363993vcb.12 for ; Fri, 15 Aug 2014 11:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GtqMtRKKOFIvTlrcpVWa+5UyTfeFN4Ocfri09nJPpsQ=; b=LeL8TleEfjEN1FcrnCou1BEhZppTRmrxL01ElbOX5BesmRN/YwXhY0/u6Wn6CejUPq Gl5DOMjRzDfdfXsoX4qlgFViCTVlS00akin16sW+G9O4h48wM9RDY9S5gPD+vELnpaJh eaCHKGWcKAtR0zdJlT+ptqEmR7VzTm5nVHZFHRWL1Max7HS9Jn0ZUYThdicRcbV6+qG9 dU48MZr7XpaKM6rOKn3n80CAbNkGEOFImnOqWKRigmHOmazJIywoFeAUPK1Onlojpn4r DtwlvH4GkHqT8HQBqxHca8HXCSylkndHO2ToxJb4WVFSnHLokkKOiakOEylLWmKSUyKO MqWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GtqMtRKKOFIvTlrcpVWa+5UyTfeFN4Ocfri09nJPpsQ=; b=K+Zjuz1J94JiTUSdRNYFPPBhiRt0/pDTRNhJUWWmqnkLlhVZsiDzCLmtNVucgAy/uY b9k19AcMuRmAwXBeIMdLs0pAm+t6aH7hswv6bxKx35XRDxg+R9gSafBM858Bymc9fxiv RXu0crR3NsnaiqYBaXXLXNMORkEw05/TcBWkoCs7yKJez4aUSerS5XriGX/POxai8eKq wix2FUYY2KY9r54OZz7aGmsiJiaU/Hfxlpx54REQE1wDcfPF0khOywUjndMufcVjkF2F 6Gik6JfpAS7t51Ve8IVAMZ3TiHrQcJyeYiAnbbC1D1PxO0w4SOjq8kreISrWC9rZFnxm 5CWw== X-Gm-Message-State: ALoCoQkv5t28LMuF6lqIn4zJ3S6AFVrp25ucs6lsbxGSm6FYE8KBO5sTqsS9e1he9a9lQNrI3QF5 MIME-Version: 1.0 X-Received: by 10.220.119.8 with SMTP id x8mr1684263vcq.62.1408127277004; Fri, 15 Aug 2014 11:27:57 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Fri, 15 Aug 2014 11:27:56 -0700 (PDT) In-Reply-To: References: <20140806210932.26762.78438.idtracker@ietfa.amsl.com> Date: Fri, 15 Aug 2014 11:27:56 -0700 Message-ID: Subject: Re: [IANA #775577] Second Last Call: (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard From: Vincent Chen To: Content-Type: multipart/alternative; boundary="001a1132e2102511470500af2e29" Archived-At: http://mailarchive.ietf.org/arch/msg/iesg/ZWYOlyD_1_DG-kTCy6_zWIy5RwA CC: "paws-chairs@tools.ietf.org" , , X-BeenThere: iesg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iesg-bounces@ietf.org Sender: iesg --001a1132e2102511470500af2e29 Content-Type: text/plain; charset="UTF-8" Thanks for the review. On Thu, Aug 14, 2014 at 10:27 AM, Pearl Liang via RT < drafts-lastcall@iana.org> wrote: > (BEGIN IANA LAST CALL COMMENTS) > > IESG/Authors/WG Chairs: > > IANA has reviewed draft-ietf-paws-protocol-14. Authors should review the > comments and/or questions below. Please report any inaccuracies and > respond to any questions as soon as possible. > > IANA has a question for one of the requested actions in this draft > document. > > We received the following comments/questions from the IANA's reviewer: > > IANA understands that, upon approval of this document there are three > actions which IANA must complete. > > IANA understands that this document proposes the creation of a PAWS > protocol registry which will initially consist of three subregistries: > > - the PAWS Ruleset ID Registry > - the PAWS Parameter Registry > - the PAWS Error Code Registry > > On the IANA Matrix located at: > > http://www.iana.org/protocols > > the new PAWS registry will be linked with a reference of [ RFC-to-be ]. > > In the new PAWS registry there will be three sub-registries as follows: > > First, in the PAWS Registry created above, a new registry called the PAWS > Ruleset ID Registry will be created. Each entry in the registry has a > ruleset name, additional parameter requirements and a specification. > > New entires in this registry are done through Specification Required as > defined in RFC 5226. > > There are two initial entries in this new registry as follows: > > Ruleset identifier: FccTvBandWhiteSpace-2010 > Specification: This ruleset refers to the FCC rules for TV-band White > Space operations established in the Code of Federal Regulations (CFR), > Title 47, Part 15, Subpart H. > Additional Parameter Requirements for FccTvBandWhiteSpace-2010: > > Available Spectrum Request > +---------------+-----------------------------+-------------+-------+ > | Parameter | Type | Requirement | Notes | > | Name | | | | > +---------------+-----------------------------+-------------+-------+ > | deviceDesc | DeviceDescriptor | REQUIRED | | > +---------------+-----------------------------+-------------+-------+ > > Available Spectrum Batch Request > +---------------+-----------------------------+-------------+-------+ > | Parameter | Type | Requirement | Notes | > | Name | | | | > +---------------+-----------------------------+-------------+-------+ > | deviceDesc | DeviceDescriptor | REQUIRED | | > +---------------+-----------------------------+-------------+-------+ > > DeviceDescriptor Message > +-------------------+--------+-------------+------------------------+ > | Parameter Name | Type | Requirement | Notes | > +-------------------+--------+-------------+------------------------+ > | fccId | string | REQUIRED | Specifies a device's | > | | | | FCC certification ID | > | fccTvbdDeviceType | string | REQUIRED | Specifies the FCC | > | | | | Device Type | > | | | | of | > | | | | TV-band White Space | > | | | | device, as defined by | > | | | | the FCC rules. | > +-------------------+--------+-------------+------------------------+ > > DeviceOwner Message > +-----------+-------+-----------------------------------------------+ > | Parameter | Type | Additional Requirement | > | Name | | | > +-----------+-------+-----------------------------------------------+ > | owner | vCard | The owner is required to contain the formatted| > | | | name of an individual or organization using | > | | | the "fn" property. When the name is that of an| > | | | organization, the entry also is required to | > | | | contain the "kind" property, with a value of | > | | | "org". | > | operator | vCard | The operator entry is required to contain the | > | | | following properties for the contact person | > | | | responsible for the device's operation: "fn", | > | | | "adr", "tel", and "email". | > +-----------+-------+-----------------------------------------------+ > > Ruleset identifier: ETSI-EN-301-598-1.1.1 > Specification document(s): This ruleset refers to the ETSI > Harmonised Standard [ETSI-EN-301-598] established by ETSI. > Additional Parameter Requirements: > > DeviceDescriptor > +-------------------------+-------+-------------+-------------------+ > | Parameter Name | Type | Requirement | Notes | > +-------------------------+-------+-------------+-------------------+ > | manufacturerId | string| REQUIRED | Specifies a | > | | | | device's | > | | | | manufacturer's | > | | | | identifier. See | > | | | | [ RFC-to-be ] | > | | | | Section 5.2. | > | modelId | string| REQUIRED | Specifies a | > | | | | device's model | > | | | | identifier. See | > | | | | [ RFC-to-be ] | > | | | | Section 5.2. | > | etsiEnDeviceType | string| REQUIRED | Specifies the | > | | | | device's ETSI | > | | | | device type | > | | | | (Section | > | | | | 9.2.2.3). | > | etsiEnDeviceEmissionsCl | string| REQUIRED | Specifies the | > | ass | | | device's ETSI | > | | | | device emissions | > | | | | class (Section | > | | | | 9.2.2.4). | > | etsiEnTechnologyId | string| REQUIRED | Specifies the | > | | | | device's ETSI | > | | | | technology ID | > | | | | (Section | > | | | | 9.2.2.5). | > | etsiEnDeviceCategory | string| REQUIRED | Specifies the | > | | | | device's ETSI | > | | | | device category | > | | | | (Section | > | | | | 9.2.2.6). | > +-------------------------+-------+-------------+-------------------+ > > AVAIL_SPECTRUM_REQ > +-------------+--------+-------------+------------------------------+ > | Parameter | Type | Requirement | Notes | > | Name | | | | > +-------------+--------+-------------+------------------------------+ > | requestType | string | OPTIONAL | Modifies the available- | > | | | | spectrum request type. If | > | | | | specified, the only valid | > | | | | value is, "Generic Slave", | > | | | | and the Database is required | > | | | | to respond with generic | > | | | | operating parameters for any | > | | | | Slave Device. | > +-------------+--------+-------------+------------------------------+ > > Available Spectrum Batch Request > +-------------+--------+-------------+------------------------------+ > | Parameter | Type | Requirement | Notes | > | Name | | | | > +-------------+--------+-------------+------------------------------+ > | requestType | string | OPTIONAL | Modifies the available- | > | | | | spectrum request type. If | > | | | | specified, the only valid | > | | | | value is, "Generic Slave", | > | | | | and the Database is required | > | | | | to respond with generic | > | | | | operating parameters for any | > | | | | Slave Device. | > +-------------+--------+-------------+------------------------------+ > > DeviceDescriptor for AVAIL_SPECTRUM_RESP and AVAIL_SPECTRUM_BATCH_RESP > messages > +--------------------------------+---------+----------+---------------+ > | Parameter Name | Type | Requirem | Notes | > | | | ent | | > +--------------------------------+---------+----------+---------------+ > | needsSpectrumReport | boolean | REQUIRED | The Database | > | | | | is required | > | | | | to set this | > | | | | to true to | > | | | | indicate that | > | | | | the device | > | | | | must report | > | | | | spectrum | > | | | | usage. | > | maxTotalBwHz | float | REQUIRED | Specifies a | > | | | | constraint on | > | | | | total allowed | > | | | | bandwidth. | > | maxContiguousBwHz | float | REQUIRED | Specifies a | > | | | | constraint on | > | | | | total allowed | > | | | | contiguous | > | | | | bandwidth. | > | etsiEnSimultaneousChannelOpera | string | REQUIRED | Specifies a | > | tionRestriction | | | constraint on | > | | | | simultaneous | > | | | | channel | > | | | | operation | > | | | | (Section | > | | | | 9.2.2.7). If | > | | | | it is not | > | | | | provided, the | > | | | | default value | > | | | | is "0". | > +--------------------------------+---------+----------+---------------+ > > RulesetInfo > +-------------------+-------+-------------+-------------------------+ > | Parameter Name | Type | Requirement | Notes | > +-------------------+-------+-------------+-------------------------+ > | maxLocationChange | float | OPTIONAL | Specifies a constraint | > | | | | on maximum location | > | | | | changes. | > +-------------------+-------+-------------+-------------------------+ > > QUESTION/Note: > 1) It appears that this document defines multiple tables for Additional > Parameter > Requirements for each Ruleset ID entry in the new requested sub-registry > "PAWS > Ruleset ID Registry" of the new created PAWS protocol registry. How do > the authors > want the registration information presented in the namespace (aka website)? > You can visit the following registry that shows a list of sub-registries > for iSCSI > Parameters, and more sub-registries under a sub-registry "iSCSI Login > Response > Status Codes": > > http://www.iana.org/assignments/iscsi-parameters Thanks for the pointer to the example. To use this, I can see organizing it as follows: a) Add a sub-registry "Additional Requirements for Ruleset Identifier=FccTvBandWhiteSpace-2010", and the multiple tables in the draft can be collapsed into a single table with an additional "Location" column, e.g.,: +--------------------------------------------------------------------------------------------+ | Location | Parameter Name | Type | Requirement | Notes | +-----------------+-----------------+----------------+---------------------+-----------------+ |Available |deviceDesc |DeviceDescriptor| REQUIRED | | |Spectrum | | | | | |Request | | | | | | | | | | | |Available |deviceDesc |DeviceDescriptor| REQUIRED | | |Spectrum | | | | | |Batch | | | | | |Request | | | | | | | | | | | |DeviceDescriptor |fccId |string |REQUIRED |Specifies a | | | | | |device's FCC | | | | | |certification ID | | | | | | | |DeviceDescriptor |fccTvbdDeviceType| | | | | | | | | | |DeviceOwner |owner |vCard |The owner is required| | | | | |to contain the | | | | | |formatted name of an | | | | | |individual or | | | | | |organization using | | | | | |the "fn" property. | | | | | |When the name is that| | | | | |of an organization, | | | | | |the entry also is | | | | | |required to contain | | | | | |contain the "kind" | | | | | |property, with a | | | | | |value of "org". | | | | | | | | |DeviceOwner |operator |vCard |The operator entry is| | | | | |... | | +--------------------------------------------------------------------------------------------+ b) Add sub-registry "Additional Requirements for Ruleset Identifier=ETSI-EN-301-598-1.1.1" and a single table similar to the above. Questions: - Would something like that work? - If so, should I update the RFC draft to reflect the above? Another option is to preserve the text as-is as the "template" and refer to it via a link, like http://www.iana.org/assignments/lang-subtags-templates/lang-subtags-templates.xhtml > > 2) We understand that "Specification document(s)" is the column for > Reference. > Yes. Agreed. > > Second, in the PAWS Registry created above, a new registry called the PAWS > Parameter Registry will be created. Each entry in the registry has a > parameter name, parameter usage location and a specification. > > > New entires in this registry are done through Specification Required as > defined in RFC 5226. > > There are seven initial entries in this new registry as follows: > > Parameter name: fccId > Parameter usage location: DeviceDescriptor > Specification document(s): [ RFC-to-be ] > > Parameter name: fccTvbdDeviceType > Parameter usage location: DeviceDescriptor > Specification document(s): [ RFC-to-be ] > > Parameter name: etsiEnDeviceType > Parameter usage location: DeviceDescriptor > Specification document(s): Specifies the White Space Device type, as > defined by the ETSI Harmonized Standard - [ > http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf > ] > > Parameter name: etsiEnDeviceEmissionsClass > Parameter usage location: DeviceDescriptor > Specification document(s): Specifies the White Space Device emissions > class, as defined by the ETSI Harmonized Standard - [ > http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf > ] > > Parameter name: etsiEnTechnologyId > Parameter usage location: DeviceDescriptor > Specification document(s): Specifies the White Space Device technology > identifier, as defined by the ETSI Harmonized Standard - [ > http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf > ] > > Parameter name: etsiEnDeviceCategory > Parameter usage location: DeviceDescriptor > Specification document(s): Specifies the White Space Device category, as > defined by the ETSI Harmonized Standard - [ > http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf > ] > > Parameter name: etsiEnSimultaneousChannelOperationRestriction > Parameter usage location: SpectrumSpec > Specification document(s): Specifies the constraint on the device maximum > total EIRP, as defined by the ETSI Harmonized Standard - [ > http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf > ] > > Third, in the PAWS Registry created above, a new registry called the PAWS > Error Code Registry will be created. Each entry in the registry has an > error code, name, description, additional parameters and reference > > New entries in this registry are done through Specification Required as > defined in RFC 5226. > > There are new entries in this subregistry, all with a reference of [ > RFC-to-be ], as follows: > > Code Name Description & Additional parameters > ------ ---------------- --------------------------------------------- > 32767 to 1 Unassigned > 0 (reserved) > -100 (reserved) > -101 VERSION The Database does not support the specified > version of the message. > -102 UNSUPPORTED The Database does not support the Device. For > example, it does not support the ruleset > specified in the request. > -103 UNIMPLEMENTED The Database does not implement the optional > request or optional feature. > -104 OUTSIDE_COVERAGE The specified geo-location is outside the > coverage area of the Database. The Database > MAY include a DbUpdateSpec > parameter to provide a list of alternate > databases that might be appropriate for the > requested location. See OUTSIDE_COVERAGE > Error for more details. > -105 DATABASE_CHANGE The Database has changed its URI. The > Database MAY include a DbUpdateSpec > parameter in the error response > to provide devices with one or more alternate > database URIs. The Device needs to use the > information to update its list of > preconfigured databases to replace (only) its > entry for the responding Database with the > list of alternate database URIs. See > DATABASE_CHANGE Error for > more details. > -200 (reserved) > -201 MISSING A required parameter is missing. The Database > MUST include a list of the required parameter > names. The Database MAY include only names of > parameters that are missing, but MAY include > a full list. Including the full list of > missing parameters may reduce the number of > re-queries from the Device. See MISSING Error > for more details. > -202 INVALID_VALUE A parameter value is invalid in some way. The > Database SHOULD include a message indicating > which parameter and why its value is invalid. > -300 (reserved) > -301 UNAUTHORIZED The Device is not authorized to used the > Database. Authorization may be determined by > the ruleset or be dependent on prior > arrangement between the Device and Database. > -302 NOT_REGISTERED Device registration required, but the Device > is not registered. > -32000 (reserved) Reserved for JSON-RPC error codes. > to > -32768 > > IANA understands that these three actions are the only ones required to be > completed upon approval of this document. > > Note: The actions requested in this document will not be completed until > the document has been approved for publication as an RFC. This message is > only to confirm what actions will be performed. > > Thanks, > > Pearl Liang > ICANN > > (END IANA LAST CALL COMMENTS) > > > > On Wed Aug 06 21:09:57 2014, iesg-secretary@ietf.org wrote: > > > > The IESG has received a request from the Protocol to Access WS database > > WG (paws) to consider the following document: > > - 'Protocol to Access White-Space (PAWS) Databases' > > as Proposed Standard > > > > A prior Last Call was made for version -12 of this document. Comments > > received during that discussion lead to extensive edits to the document, > > which could benefit from a second review. > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2014-08-20. Exceptionally, comments may > be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > Portions of the radio spectrum that are allocated to licensees are > > available for non-interfering use. This available spectrum is called > > "White Space." Allowing secondary users access to available spectrum > > "unlocks" existing spectrum to maximize its utilization and to > > provide opportunities for innovation, resulting in greater overall > > spectrum utilization. > > > > One approach to managing spectrum sharing uses databases to report > > spectrum availability to devices. To achieve interoperability among > > multiple devices and databases, a standardized protocol must be > > defined and implemented. This document defines such a protocol, the > > "Protocol to Access White Space (PAWS) Databases". > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ballot/ > > > > > > The following IPR Declarations may be related to this I-D: > > > > http://datatracker.ietf.org/ipr/2203/ > > http://datatracker.ietf.org/ipr/2340/ > > http://datatracker.ietf.org/ipr/2239/ > > > > > > > > > -- -vince --001a1132e2102511470500af2e29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+VGhhbmtzIGZvciB0aGUgcmV2aWV3Ljxicj48ZGl2IGNsYXNzPSJnbWFp bF9leHRyYSI+PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVGh1LCBBdWcgMTQs IDIwMTQgYXQgMTA6MjcgQU0sIFBlYXJsIExpYW5nIHZpYSBSVCA8c3BhbiBkaXI9Imx0ciI+Jmx0 OzxhIGhyZWY9Im1haWx0bzpkcmFmdHMtbGFzdGNhbGxAaWFuYS5vcmciIHRhcmdldD0iX2JsYW5r Ij5kcmFmdHMtbGFzdGNhbGxAaWFuYS5vcmc8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAu OGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwy MDQpO2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPihCRUdJTiBJQU5B IExBU1QgQ0FMTCBDT01NRU5UUyk8YnI+DQo8YnI+DQpJRVNHL0F1dGhvcnMvV0cgQ2hhaXJzOjxi cj4NCjxicj4NCklBTkEgaGFzIHJldmlld2VkIGRyYWZ0LWlldGYtcGF3cy1wcm90b2NvbC0xNC7C oCBBdXRob3JzIHNob3VsZCByZXZpZXcgdGhlIGNvbW1lbnRzIGFuZC9vciBxdWVzdGlvbnMgYmVs b3cuwqAgUGxlYXNlIHJlcG9ydCBhbnkgaW5hY2N1cmFjaWVzIGFuZCByZXNwb25kIHRvIGFueSBx dWVzdGlvbnMgYXMgc29vbiBhcyBwb3NzaWJsZS48YnI+DQo8YnI+DQpJQU5BIGhhcyBhIHF1ZXN0 aW9uIGZvciBvbmUgb2YgdGhlIHJlcXVlc3RlZCBhY3Rpb25zIGluIHRoaXMgZHJhZnQgZG9jdW1l bnQuPGJyPg0KPGJyPg0KV2UgcmVjZWl2ZWQgdGhlIGZvbGxvd2luZyBjb21tZW50cy9xdWVzdGlv bnMgZnJvbSB0aGUgSUFOQSYjMzk7cyByZXZpZXdlcjo8YnI+DQo8YnI+DQpJQU5BIHVuZGVyc3Rh bmRzIHRoYXQsIHVwb24gYXBwcm92YWwgb2YgdGhpcyBkb2N1bWVudCB0aGVyZSBhcmUgdGhyZWUg YWN0aW9ucyB3aGljaCBJQU5BIG11c3QgY29tcGxldGUuPGJyPg0KPGJyPg0KSUFOQSB1bmRlcnN0 YW5kcyB0aGF0IHRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdGhlIGNyZWF0aW9uIG9mIGEgUEFXUyBw cm90b2NvbCByZWdpc3RyeSB3aGljaCB3aWxsIGluaXRpYWxseSBjb25zaXN0IG9mIHRocmVlIHN1 YnJlZ2lzdHJpZXM6PGJyPg0KPGJyPg0KLSB0aGUgUEFXUyBSdWxlc2V0IElEIFJlZ2lzdHJ5PGJy Pg0KLSB0aGUgUEFXUyBQYXJhbWV0ZXIgUmVnaXN0cnk8YnI+DQotIHRoZSBQQVdTIEVycm9yIENv ZGUgUmVnaXN0cnk8YnI+DQo8YnI+DQpPbiB0aGUgSUFOQSBNYXRyaXggbG9jYXRlZCBhdDo8YnI+ DQo8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmlhbmEub3JnL3Byb3RvY29scyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly93d3cuaWFuYS5vcmcvcHJvdG9jb2xzPC9hPjxicj4NCjxicj4NCnRoZSBu ZXcgUEFXUyByZWdpc3RyeSB3aWxsIGJlIGxpbmtlZCB3aXRoIGEgcmVmZXJlbmNlIG9mIFsgUkZD LXRvLWJlIF0uPGJyPg0KPGJyPg0KSW4gdGhlIG5ldyBQQVdTIHJlZ2lzdHJ5IHRoZXJlIHdpbGwg YmUgdGhyZWUgc3ViLXJlZ2lzdHJpZXMgYXMgZm9sbG93czo8YnI+DQo8YnI+DQpGaXJzdCwgaW4g dGhlIFBBV1MgUmVnaXN0cnkgY3JlYXRlZCBhYm92ZSwgYSBuZXcgcmVnaXN0cnkgY2FsbGVkIHRo ZSBQQVdTIFJ1bGVzZXQgSUQgUmVnaXN0cnkgd2lsbCBiZSBjcmVhdGVkLsKgIEVhY2ggZW50cnkg aW4gdGhlIHJlZ2lzdHJ5IGhhcyBhIHJ1bGVzZXQgbmFtZSwgYWRkaXRpb25hbCBwYXJhbWV0ZXIg cmVxdWlyZW1lbnRzIGFuZCBhIHNwZWNpZmljYXRpb24uPGJyPg0KPGJyPg0KTmV3IGVudGlyZXMg aW4gdGhpcyByZWdpc3RyeSBhcmUgZG9uZSB0aHJvdWdoIFNwZWNpZmljYXRpb24gUmVxdWlyZWQg YXMgZGVmaW5lZCBpbiBSRkMgNTIyNi48YnI+DQo8YnI+DQpUaGVyZSBhcmUgdHdvIGluaXRpYWwg ZW50cmllcyBpbiB0aGlzIG5ldyByZWdpc3RyeSBhcyBmb2xsb3dzOjxicj4NCjxicj4NClJ1bGVz ZXQgaWRlbnRpZmllcjrCoCBGY2NUdkJhbmRXaGl0ZVNwYWNlLTIwMTA8YnI+DQpTcGVjaWZpY2F0 aW9uOsKgIFRoaXMgcnVsZXNldCByZWZlcnMgdG8gdGhlIEZDQyBydWxlcyBmb3IgVFYtYmFuZCBX aGl0ZSBTcGFjZSBvcGVyYXRpb25zIGVzdGFibGlzaGVkIGluIHRoZSBDb2RlIG9mIEZlZGVyYWwg UmVndWxhdGlvbnMgKENGUiksIFRpdGxlIDQ3LCBQYXJ0IDE1LCBTdWJwYXJ0IEguPGJyPg0KQWRk aXRpb25hbCBQYXJhbWV0ZXIgUmVxdWlyZW1lbnRzIGZvciBGY2NUdkJhbmRXaGl0ZVNwYWNlLTIw MTA6PGJyPg0KPGJyPg0KQXZhaWxhYmxlIFNwZWN0cnVtIFJlcXVlc3Q8YnI+DQorLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0t LSs8YnI+DQp8IFBhcmFtZXRlcsKgIMKgIMKgfCBUeXBlwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfCBSZXF1aXJlbWVudCB8IE5vdGVzIHw8YnI+DQp8IE5hbWXCoCDCoCDCoCDC oCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAg wqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqB8PGJyPg0KKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0rPGJyPg0KfCBkZXZp Y2VEZXNjwqAgwqAgfCBEZXZpY2VEZXNjcmlwdG9ywqAgwqAgwqAgwqAgwqAgwqAgfCBSRVFVSVJF RMKgIMKgIHzCoCDCoCDCoCDCoHw8YnI+DQorLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLSs8YnI+DQo8YnI+DQpBdmFpbGFi bGUgU3BlY3RydW0gQmF0Y2ggUmVxdWVzdDxicj4NCsKgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0rPGJyPg0KfCBQYXJh bWV0ZXLCoCDCoCDCoHwgVHlwZcKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwg UmVxdWlyZW1lbnQgfCBOb3RlcyB8PGJyPg0KfCBOYW1lwqAgwqAgwqAgwqAgwqAgfMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKg fMKgIMKgIMKgIMKgfDxicj4NCistLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tKzxicj4NCnwgZGV2aWNlRGVzY8KgIMKgIHwg RGV2aWNlRGVzY3JpcHRvcsKgIMKgIMKgIMKgIMKgIMKgIHwgUkVRVUlSRUTCoCDCoCB8wqAgwqAg wqAgwqB8PGJyPg0KKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tKy0tLS0tLS0rPGJyPg0KPGJyPg0KRGV2aWNlRGVzY3JpcHRvciBNZXNz YWdlPGJyPg0KKy0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rPGJyPg0KfCBQYXJhbWV0ZXIgTmFtZcKgIMKgIHwgVHlwZcKg IMKgfCBSZXF1aXJlbWVudCB8IE5vdGVzwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4N CistLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKzxicj4NCnwgZmNjSWTCoCDCoCDCoCDCoCDCoCDCoCDCoHwgc3RyaW5nIHwg UkVRVUlSRUTCoCDCoCB8IFNwZWNpZmllcyBhIGRldmljZSYjMzk7c8KgIMKgfDxicj4NCnzCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAg wqB8IEZDQyBjZXJ0aWZpY2F0aW9uIElEwqAgwqB8PGJyPg0KfCBmY2NUdmJkRGV2aWNlVHlwZSB8 IHN0cmluZyB8IFJFUVVJUkVEwqAgwqAgfCBTcGVjaWZpZXMgdGhlIEZDQ8KgIMKgIMKgIHw8YnI+ DQp8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKg IMKgIMKgIMKgfCBEZXZpY2UgVHlwZcKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQp8wqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgfCBv ZsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfDxicj4NCnzCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqB8IFRWLWJhbmQg V2hpdGUgU3BhY2XCoCDCoCB8PGJyPg0KfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKg IMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoHwgZGV2aWNlLCBhcyBkZWZpbmVkIGJ5wqAg fDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAgwqAg wqAgwqAgwqAgwqAgwqB8IHRoZSBGQ0MgcnVsZXMuwqAgwqAgwqAgwqAgwqB8PGJyPg0KKy0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rPGJyPg0KPGJyPg0KRGV2aWNlT3duZXIgTWVzc2FnZTxicj4NCsKgKy0tLS0tLS0tLS0t Ky0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r PGJyPg0KfCBQYXJhbWV0ZXIgfCBUeXBlwqAgfCBBZGRpdGlvbmFsIFJlcXVpcmVtZW50wqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCnwgTmFtZcKgIMKgIMKgIHzCoCDC oCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8YnI+DQorLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSs8YnI+DQp8IG93bmVywqAg wqAgwqB8IHZDYXJkIHwgVGhlIG93bmVyIGlzIHJlcXVpcmVkIHRvIGNvbnRhaW4gdGhlIGZvcm1h dHRlZHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqB8IG5hbWUgb2YgYW4gaW5k aXZpZHVhbCBvciBvcmdhbml6YXRpb24gdXNpbmfCoCDCoHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAg wqB8wqAgwqAgwqAgwqB8IHRoZSAmcXVvdDtmbiZxdW90OyBwcm9wZXJ0eS4gV2hlbiB0aGUgbmFt ZSBpcyB0aGF0IG9mIGFufDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoHwgb3Jn YW5pemF0aW9uLCB0aGUgZW50cnkgYWxzbyBpcyByZXF1aXJlZCB0b8KgIMKgfDxicj4NCnzCoCDC oCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoHwgY29udGFpbiB0aGUgJnF1b3Q7a2luZCZxdW90OyBw cm9wZXJ0eSwgd2l0aCBhIHZhbHVlIG9mwqAgfDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoHzCoCDC oCDCoCDCoHwgJnF1b3Q7b3JnJnF1b3Q7LsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQp8IG9wZXJhdG9ywqAgfCB2Q2FyZCB8 IFRoZSBvcGVyYXRvciBlbnRyeSBpcyByZXF1aXJlZCB0byBjb250YWluIHRoZSB8PGJyPg0KfMKg IMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgfCBmb2xsb3dpbmcgcHJvcGVydGllcyBmb3IgdGhl IGNvbnRhY3QgcGVyc29uwqAgwqB8PGJyPg0KfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKg fCByZXNwb25zaWJsZSBmb3IgdGhlIGRldmljZSYjMzk7cyBvcGVyYXRpb246ICZxdW90O2ZuJnF1 b3Q7LCB8PGJyPg0KfMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgfCAmcXVvdDthZHImcXVv dDssICZxdW90O3RlbCZxdW90OywgYW5kICZxdW90O2VtYWlsJnF1b3Q7LsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHw8YnI+DQorLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSs8YnI+DQo8YnI+DQpSdWxlc2V0IGlk ZW50aWZpZXI6wqAgRVRTSS1FTi0zMDEtNTk4LTEuMS4xPGJyPg0KU3BlY2lmaWNhdGlvbiBkb2N1 bWVudChzKTrCoCBUaGlzIHJ1bGVzZXQgcmVmZXJzIHRvIHRoZSBFVFNJPGJyPg0KwqAgwqAgwqBI YXJtb25pc2VkIFN0YW5kYXJkIFtFVFNJLUVOLTMwMS01OThdIGVzdGFibGlzaGVkIGJ5IEVUU0ku PGJyPg0KQWRkaXRpb25hbCBQYXJhbWV0ZXIgUmVxdWlyZW1lbnRzOjxicj4NCjxicj4NCkRldmlj ZURlc2NyaXB0b3I8YnI+DQorLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tKy0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLSs8YnI+DQp8IFBhcmFtZXRlciBOYW1lwqAgwqAg wqAgwqAgwqAgfCBUeXBlwqAgfCBSZXF1aXJlbWVudCB8IE5vdGVzwqAgwqAgwqAgwqAgwqAgwqAg wqB8PGJyPg0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0rPGJyPg0KfCBtYW51ZmFjdHVyZXJJZMKgIMKgIMKgIMKgIMKg IHwgc3RyaW5nfCBSRVFVSVJFRMKgIMKgIHwgU3BlY2lmaWVzIGHCoCDCoCDCoCDCoHw8YnI+DQp8 wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqB8wqAgwqAg wqAgwqAgwqAgwqAgwqB8IGRldmljZSYjMzk7c8KgIMKgIMKgIMKgIMKgIHw8YnI+DQp8wqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAg wqAgwqAgwqB8IG1hbnVmYWN0dXJlciYjMzk7c8KgIMKgIHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqB8 IGlkZW50aWZpZXIuIFNlZcKgIMKgfDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHzCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoHwgWyBSRkMtdG8tYmUg XcKgIMKgIMKgfDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzC oCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoHwgU2VjdGlvbiA1LjIuwqAgwqAgwqAgfDxi cj4NCnwgbW9kZWxJZMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfCBzdHJpbmd8IFJFUVVJUkVE wqAgwqAgfCBTcGVjaWZpZXMgYcKgIMKgIMKgIMKgfDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoHwgZGV2 aWNlJiMzOTtzIG1vZGVswqAgwqAgfDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHzCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoHwgaWRlbnRpZmllci4g U2VlwqAgwqB8PGJyPg0KfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKg IMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgfCBbIFJGQy10by1iZSBdwqAgwqAgwqB8PGJy Pg0KfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgfMKg IMKgIMKgIMKgIMKgIMKgIMKgfCBTZWN0aW9uIDUuMi7CoCDCoCDCoCB8PGJyPg0KfCBldHNpRW5E ZXZpY2VUeXBlwqAgwqAgwqAgwqAgfCBzdHJpbmd8IFJFUVVJUkVEwqAgwqAgfCBTcGVjaWZpZXMg dGhlwqAgwqAgwqB8PGJyPg0KfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg fMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgfCBkZXZpY2UmIzM5O3MgRVRTScKgIMKg IMKgfDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDC oCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoHwgZGV2aWNlIHR5cGXCoCDCoCDCoCDCoHw8YnI+DQp8 wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqB8wqAgwqAg wqAgwqAgwqAgwqAgwqB8IChTZWN0aW9uwqAgwqAgwqAgwqAgwqAgfDxicj4NCnzCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDC oCDCoHwgOS4yLjIuMykuwqAgwqAgwqAgwqAgwqB8PGJyPg0KfCBldHNpRW5EZXZpY2VFbWlzc2lv bnNDbCB8IHN0cmluZ3wgUkVRVUlSRUTCoCDCoCB8IFNwZWNpZmllcyB0aGXCoCDCoCDCoHw8YnI+ DQp8IGFzc8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgfMKgIMKg IMKgIMKgIMKgIMKgIMKgfCBkZXZpY2UmIzM5O3MgRVRTScKgIMKgIMKgfDxicj4NCnzCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDC oCDCoCDCoHwgZGV2aWNlIGVtaXNzaW9uc8KgIHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqB8IGNsYXNz IChTZWN0aW9uwqAgwqAgfDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoHzCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCDCoCDCoHwgOS4yLjIuNCkuwqAgwqAgwqAg wqAgwqB8PGJyPg0KfCBldHNpRW5UZWNobm9sb2d5SWTCoCDCoCDCoCB8IHN0cmluZ3wgUkVRVUlS RUTCoCDCoCB8IFNwZWNpZmllcyB0aGXCoCDCoCDCoHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqB8IGRl dmljZSYjMzk7cyBFVFNJwqAgwqAgwqB8PGJyPg0KfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgfCB0ZWNobm9sb2d5 IElEwqAgwqAgwqB8PGJyPg0KfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg fMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgfCAoU2VjdGlvbsKgIMKgIMKgIMKgIMKg IHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAg wqB8wqAgwqAgwqAgwqAgwqAgwqAgwqB8IDkuMi4yLjUpLsKgIMKgIMKgIMKgIMKgfDxicj4NCnwg ZXRzaUVuRGV2aWNlQ2F0ZWdvcnnCoCDCoCB8IHN0cmluZ3wgUkVRVUlSRUTCoCDCoCB8IFNwZWNp ZmllcyB0aGXCoCDCoCDCoHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqB8wqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqB8IGRldmljZSYjMzk7cyBFVFNJ wqAgwqAgwqB8PGJyPg0KfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKg IMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIMKgIMKgfCBkZXZpY2UgY2F0ZWdvcnnCoCDCoHw8YnI+ DQp8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqB8wqAg wqAgwqAgwqAgwqAgwqAgwqB8IChTZWN0aW9uwqAgwqAgwqAgwqAgwqAgfDxicj4NCnzCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDC oCDCoCDCoHwgOS4yLjIuNikuwqAgwqAgwqAgwqAgwqB8PGJyPg0KKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0rPGJyPg0K PGJyPg0KQVZBSUxfU1BFQ1RSVU1fUkVRPGJyPg0KKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rPGJyPg0KfCBQYXJhbWV0 ZXLCoCDCoHwgVHlwZcKgIMKgfCBSZXF1aXJlbWVudCB8IE5vdGVzwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgfDxicj4NCnwgTmFtZcKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8 wqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgfDxicj4NCistLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKzxicj4NCnwgcmVxdWVzdFR5cGUgfCBzdHJpbmcg fCBPUFRJT05BTMKgIMKgIHwgTW9kaWZpZXMgdGhlIGF2YWlsYWJsZS3CoCDCoCDCoCB8PGJyPg0K fMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoHwg c3BlY3RydW0gcmVxdWVzdCB0eXBlLiBJZsKgIMKgIHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAgwqAg wqB8wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgfCBzcGVjaWZpZWQsIHRoZSBvbmx5 IHZhbGlkwqAgwqAgfDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAg wqAgwqAgwqAgwqAgwqAgwqB8IHZhbHVlIGlzLCAmcXVvdDtHZW5lcmljIFNsYXZlJnF1b3Q7LMKg IMKgfDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAg wqAgwqAgwqB8IGFuZCB0aGUgRGF0YWJhc2UgaXMgcmVxdWlyZWQgfDxicj4NCnzCoCDCoCDCoCDC oCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqB8IHRvIHJlc3BvbmQg d2l0aCBnZW5lcmljwqAgwqAgwqAgfDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDC oCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqB8IG9wZXJhdGluZyBwYXJhbWV0ZXJzIGZvciBhbnkg fDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAg wqAgwqB8IFNsYXZlIERldmljZS7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KKy0tLS0t LS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rPGJyPg0KPGJyPg0KQXZhaWxhYmxlIFNwZWN0cnVtIEJhdGNoIFJlcXVlc3Q8YnI+DQor LS0tLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSs8YnI+DQp8IFBhcmFtZXRlcsKgIMKgfCBUeXBlwqAgwqB8IFJlcXVpcmVtZW50 IHwgTm90ZXPCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KfCBOYW1l wqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PGJyPg0KKy0tLS0tLS0tLS0tLS0r LS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rPGJy Pg0KfCByZXF1ZXN0VHlwZSB8IHN0cmluZyB8IE9QVElPTkFMwqAgwqAgfCBNb2RpZmllcyB0aGUg YXZhaWxhYmxlLcKgIMKgIMKgIHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAg wqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgfCBzcGVjdHJ1bSByZXF1ZXN0IHR5cGUuIElmwqAgwqAg fDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAg wqAgwqB8IHNwZWNpZmllZCwgdGhlIG9ubHkgdmFsaWTCoCDCoCB8PGJyPg0KfMKgIMKgIMKgIMKg IMKgIMKgIMKgfMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoHwgdmFsdWUgaXMsICZx dW90O0dlbmVyaWMgU2xhdmUmcXVvdDsswqAgwqB8PGJyPg0KfMKgIMKgIMKgIMKgIMKgIMKgIMKg fMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoHwgYW5kIHRoZSBEYXRhYmFzZSBpcyBy ZXF1aXJlZCB8PGJyPg0KfMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIHzCoCDCoCDC oCDCoCDCoCDCoCDCoHwgdG8gcmVzcG9uZCB3aXRoIGdlbmVyaWPCoCDCoCDCoCB8PGJyPg0KfMKg IMKgIMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoHwgb3Bl cmF0aW5nIHBhcmFtZXRlcnMgZm9yIGFueSB8PGJyPg0KfMKgIMKgIMKgIMKgIMKgIMKgIMKgfMKg IMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoHwgU2xhdmUgRGV2aWNlLsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHw8YnI+DQorLS0tLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSs8YnI+DQo8YnI+DQpEZXZpY2VEZXNjcmlw dG9yIGZvciBBVkFJTF9TUEVDVFJVTV9SRVNQIGFuZCBBVkFJTF9TUEVDVFJVTV9CQVRDSF9SRVNQ IG1lc3NhZ2VzPGJyPg0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSs8YnI+DQp8IFBhcmFtZXRlciBOYW1lwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB8IFR5cGXCoCDCoCB8IFJlcXVpcmVtIHwgTm90ZXPCoCDCoCDC oCDCoCDCoHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfMKgIMKgIMKgIMKgIMKgfCBlbnTCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAg wqB8PGJyPg0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLSs8YnI+DQp8IG5lZWRzU3BlY3RydW1SZXBvcnTCoCDCoCDC oCDCoCDCoCDCoCB8IGJvb2xlYW4gfCBSRVFVSVJFRCB8IFRoZSBEYXRhYmFzZcKgIHw8YnI+DQp8 wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfMKgIMKgIMKg IMKgIMKgfMKgIMKgIMKgIMKgIMKgIHwgaXMgcmVxdWlyZWTCoCDCoHw8YnI+DQp8wqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgfMKg IMKgIMKgIMKgIMKgIHwgdG8gc2V0IHRoaXPCoCDCoHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKg IMKgIHwgdG8gdHJ1ZSB0b8KgIMKgIHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIHwgaW5k aWNhdGUgdGhhdCB8PGJyPg0KfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCB8IHRoZSBkZXZpY2XCoCDC oCB8PGJyPg0KfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHzCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCB8IG11c3QgcmVwb3J0wqAgwqB8PGJyPg0K fMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDC oCDCoCDCoHzCoCDCoCDCoCDCoCDCoCB8IHNwZWN0cnVtwqAgwqAgwqAgfDxicj4NCnzCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqB8 wqAgwqAgwqAgwqAgwqAgfCB1c2FnZS7CoCDCoCDCoCDCoCB8PGJyPg0KfCBtYXhUb3RhbEJ3SHrC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwgZmxvYXTCoCDCoHwgUkVRVUlSRUQgfCBTcGVj aWZpZXMgYcKgIMKgfDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgfCBjb25zdHJhaW50IG9u IHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIHwgdG90YWwgYWxsb3dlZCB8PGJyPg0KfMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDC oCDCoHzCoCDCoCDCoCDCoCDCoCB8IGJhbmR3aWR0aC7CoCDCoCB8PGJyPg0KfCBtYXhDb250aWd1 b3VzQndIesKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgZmxvYXTCoCDCoHwgUkVRVUlSRUQgfCBTcGVj aWZpZXMgYcKgIMKgfDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgfCBjb25zdHJhaW50IG9u IHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIHwgdG90YWwgYWxsb3dlZCB8PGJyPg0KfMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDC oCDCoHzCoCDCoCDCoCDCoCDCoCB8IGNvbnRpZ3VvdXPCoCDCoCB8PGJyPg0KfMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoHzCoCDC oCDCoCDCoCDCoCB8IGJhbmR3aWR0aC7CoCDCoCB8PGJyPg0KfCBldHNpRW5TaW11bHRhbmVvdXND aGFubmVsT3BlcmEgfCBzdHJpbmfCoCB8IFJFUVVJUkVEIHwgU3BlY2lmaWVzIGHCoCDCoHw8YnI+ DQp8IHRpb25SZXN0cmljdGlvbsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDC oHzCoCDCoCDCoCDCoCDCoCB8IGNvbnN0cmFpbnQgb24gfDxicj4NCnzCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAg wqAgwqAgfCBzaW11bHRhbmVvdXPCoCB8PGJyPg0KfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCB8IGNo YW5uZWzCoCDCoCDCoCDCoHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKgIHwgb3BlcmF0aW9u wqAgwqAgwqB8PGJyPg0KfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHzCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCB8IChTZWN0aW9uwqAgwqAgwqAg fDxicj4NCnzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8 wqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgfCA5LjIuMi43KS4gSWbCoCB8PGJyPg0KfMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDC oCDCoHzCoCDCoCDCoCDCoCDCoCB8IGl0IGlzIG5vdMKgIMKgIMKgfDxicj4NCnzCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqB8wqAg wqAgwqAgwqAgwqAgfCBwcm92aWRlZCwgdGhlIHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIMKg IHwgZGVmYXVsdCB2YWx1ZSB8PGJyPg0KfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoHzCoCDCoCDCoCDCoCDCoCB8IGlzICZxdW90 OzAmcXVvdDsuwqAgwqAgwqAgwqB8PGJyPg0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSs8YnI+DQo8YnI+DQpSdWxl c2V0SW5mbzxicj4NCistLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKzxicj4NCnwgUGFyYW1ldGVyIE5hbWXCoCDCoCB8IFR5 cGXCoCB8IFJlcXVpcmVtZW50IHwgTm90ZXPCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHw8 YnI+DQorLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSs8YnI+DQp8IG1heExvY2F0aW9uQ2hhbmdlIHwgZmxvYXQgfCBPUFRJ T05BTMKgIMKgIHwgU3BlY2lmaWVzIGEgY29uc3RyYWludMKgIHw8YnI+DQp8wqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqB8wqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqB8IG9uIG1h eGltdW0gbG9jYXRpb27CoCDCoCDCoHw8YnI+DQp8wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqB8wqAgwqAgwqAgwqB8wqAgwqAgwqAgwqAgwqAgwqAgwqB8IGNoYW5nZXMuwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgfDxicj4NCistLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKzxicj4NCjxicj4NClFVRVNUSU9OL05vdGU6 PGJyPg0KMSkgSXQgYXBwZWFycyB0aGF0IHRoaXMgZG9jdW1lbnQgZGVmaW5lcyBtdWx0aXBsZSB0 YWJsZXMgZm9yIEFkZGl0aW9uYWwgUGFyYW1ldGVyPGJyPg0KUmVxdWlyZW1lbnRzIGZvciBlYWNo IFJ1bGVzZXQgSUQgZW50cnkgaW4gdGhlIG5ldyByZXF1ZXN0ZWQgc3ViLXJlZ2lzdHJ5ICZxdW90 O1BBV1M8YnI+DQpSdWxlc2V0IElEIFJlZ2lzdHJ5JnF1b3Q7IG9mIHRoZSBuZXcgY3JlYXRlZCBQ QVdTIHByb3RvY29sIHJlZ2lzdHJ5LsKgIEhvdyBkbyB0aGUgYXV0aG9yczxicj4NCndhbnQgdGhl IHJlZ2lzdHJhdGlvbiBpbmZvcm1hdGlvbiBwcmVzZW50ZWQgaW4gdGhlIG5hbWVzcGFjZSAoYWth IHdlYnNpdGUpPzxicj4NCllvdSBjYW4gdmlzaXQgdGhlIGZvbGxvd2luZyByZWdpc3RyeSB0aGF0 IHNob3dzIGEgbGlzdCBvZiBzdWItcmVnaXN0cmllcyBmb3IgaVNDU0k8YnI+DQpQYXJhbWV0ZXJz LCBhbmQgbW9yZSBzdWItcmVnaXN0cmllcyB1bmRlciBhIHN1Yi1yZWdpc3RyeSAmcXVvdDtpU0NT SSBMb2dpbiBSZXNwb25zZTxicj4NClN0YXR1cyBDb2RlcyZxdW90Ozo8YnI+DQo8YnI+DQo8YSBo cmVmPSJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2lzY3NpLXBhcmFtZXRlcnMiIHRh cmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2lzY3NpLXBhcmFt ZXRlcnM8L2E+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhhbmtzIGZvciB0aGUg cG9pbnRlciB0byB0aGUgZXhhbXBsZS4gVG8gdXNlIHRoaXMsIEkgY2FuIHNlZSBvcmdhbml6aW5n IGl0IGFzIGZvbGxvd3M6PC9kaXY+DQo8ZGl2Pjxicj48L2Rpdj48ZGl2PsKgIGEpIEFkZCBhIHN1 Yi1yZWdpc3RyeSAmcXVvdDtBZGRpdGlvbmFsIFJlcXVpcmVtZW50cyBmb3IgUnVsZXNldCBJZGVu dGlmaWVyPUZjY1R2QmFuZFdoaXRlU3BhY2UtMjAxMCZxdW90OywgYW5kIHRoZSBtdWx0aXBsZSB0 YWJsZXMgaW4gdGhlIGRyYWZ0IGNhbiBiZSBjb2xsYXBzZWQgaW50byBhIHNpbmdsZSB0YWJsZSB3 aXRoIGFuIGFkZGl0aW9uYWwgJnF1b3Q7TG9jYXRpb24mcXVvdDsgY29sdW1uLCBlLmcuLDo8L2Rp dj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiYjMzk7Y291cmllciBuZXcmIzM5Oyxt b25vc3BhY2UiPjxicj48L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JiMzOTtjb3VyaWVyIG5ldyYjMzk7LG1vbm9zcGFjZSI+Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKzwvc3Bhbj48YnI+DQo8L2Rpdj48ZGl2Pjxmb250IGZhY2U9ImNvdXJpZXIg bmV3LCBtb25vc3BhY2UiPnwgTG9jYXRpb24gwqAgwqAgwqAgwqB8IFBhcmFtZXRlciBOYW1lIMKg fCBUeXBlIMKgIMKgIMKgIMKgIMKgIHwgUmVxdWlyZW1lbnQgwqAgwqAgwqAgwqAgfCBOb3RlcyDC oCDCoCDCoCDCoCDCoCB8PC9mb250PjwvZGl2PjxkaXY+PGZvbnQgZmFjZT0iY291cmllciBuZXcs IG1vbm9zcGFjZSI+Ky0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tKzwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iY291cmllciBuZXcsIG1vbm9zcGFjZSI+fEF2YWlsYWJs ZSDCoCDCoCDCoCDCoHxkZXZpY2VEZXNjIMKgIMKgIMKgIHxEZXZpY2VEZXNjcmlwdG9yfCBSRVFV SVJFRCDCoCDCoCDCoCDCoCDCoCDCoHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDwvZm9udD48 L2Rpdj48ZGl2Pjxmb250IGZhY2U9ImNvdXJpZXIgbmV3LCBtb25vc3BhY2UiPnxTcGVjdHJ1bSDC oCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iY291cmllciBuZXcsIG1vbm9z cGFjZSI+fFJlcXVlc3QgwqAgwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDwvZm9udD48L2Rpdj48ZGl2Pjxmb250IGZhY2U9ImNv dXJpZXIgbmV3LCBtb25vc3BhY2UiPnwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9ImNvdXJpZXIgbmV3LCBtb25vc3BhY2UiPnxBdmFpbGFibGUgwqAg wqAgwqAgwqB8ZGV2aWNlRGVzYyDCoCDCoCDCoCB8RGV2aWNlRGVzY3JpcHRvcnwgUkVRVUlSRUQg wqAgwqAgwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8L2ZvbnQ+PC9kaXY+ PGRpdj48Zm9udCBmYWNlPSJjb3VyaWVyIG5ldywgbW9ub3NwYWNlIj58U3BlY3RydW0gwqAgwqAg wqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg fCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHw8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImNvdXJpZXIgbmV3LCBtb25vc3BhY2Ui PnxCYXRjaCDCoCDCoCDCoCDCoCDCoCDCoHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8PC9mb250PjwvZGl2PjxkaXY+PGZvbnQgZmFjZT0iY291cmll ciBuZXcsIG1vbm9zcGFjZSI+fFJlcXVlc3QgwqAgwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDwvZm9udD48L2Rpdj4NCjxkaXY+ PGZvbnQgZmFjZT0iY291cmllciBuZXcsIG1vbm9zcGFjZSI+fCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8 IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fDwvZm9udD48L2Rpdj48ZGl2Pjxmb250IGZhY2U9ImNvdXJpZXIgbmV3LCBtb25vc3BhY2UiPnxE ZXZpY2VEZXNjcmlwdG9yIHxmY2NJZCDCoCDCoCDCoCDCoCDCoCDCoHxzdHJpbmcgwqAgwqAgwqAg wqAgwqB8UkVRVUlSRUQgwqAgwqAgwqAgwqAgwqAgwqAgfFNwZWNpZmllcyBhIMKgIMKgIMKgfDwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iY291cmllciBuZXcsIG1vbm9zcGFjZSI+fCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHxkZXZpY2Um IzM5O3MgwqBGQ0MgwqAgwqB8PC9mb250PjwvZGl2PjxkaXY+PGZvbnQgZmFjZT0iY291cmllciBu ZXcsIG1vbm9zcGFjZSI+fCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHxjZXJ0aWZpY2F0aW9uIElEIHw8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9ImNvdXJpZXIgbmV3LCBtb25vc3BhY2UiPnwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8L2ZvbnQ+ PC9kaXY+PGRpdj48Zm9udCBmYWNlPSJjb3VyaWVyIG5ldywgbW9ub3NwYWNlIj58RGV2aWNlRGVz Y3JpcHRvciB8ZmNjVHZiZERldmljZVR5cGV8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgfCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImNvdXJpZXIgbmV3LCBtb25vc3BhY2UiPnwgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHw8L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udCBmYWNlPSJjb3VyaWVyIG5l dywgbW9ub3NwYWNlIj58RGV2aWNlT3duZXIgwqAgwqAgwqB8b3duZXIgwqAgwqAgwqAgwqAgwqAg wqB8dkNhcmQgwqAgwqAgwqAgwqAgwqAgfFRoZSBvd25lciBpcyByZXF1aXJlZHwgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iY291cmllciBu ZXcsIG1vbm9zcGFjZSI+fCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8dG8gY29udGFpbiB0aGUgwqAgwqAg wqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PC9mb250PjwvZGl2PjxkaXY+PGZvbnQgZmFj ZT0iY291cmllciBuZXcsIG1vbm9zcGFjZSI+fCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8Zm9ybWF0dGVk wqA8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiYjMzk7Y291cmllciBuZXcmIzM5Oyxt b25vc3BhY2UiPm5hbWUgb2YgYW4gfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8PC9zcGFuPjwv ZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JiMzOTtjb3VyaWVyIG5ldyYjMzk7 LG1vbm9zcGFjZSI+fCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8aW5kaXZpZHVhbCBvciDCoCDCoCDCoCDC oHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomIzM5O2NvdXJpZXIgbmV3JiMzOTssbW9ub3NwYWNlIj58IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoHxvcmdhbml6YXRpb24gdXNpbmcgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB8PC9zcGFuPjwvZGl2Pg0KPGZvbnQgZmFjZT0iY291cmllciBuZXcsIG1vbm9zcGFjZSI+fCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqB8dGhlICZxdW90O2ZuJnF1b3Q7IHByb3BlcnR5LiDCoCB8IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHw8L2ZvbnQ+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUi Pjxmb250IGZhY2U9ImNvdXJpZXIgbmV3LCBtb25vc3BhY2UiPnwgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg fFdoZW4gdGhlIG5hbWUgaXMgdGhhdHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDwvZm9udD48 L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48Zm9udCBmYWNlPSJjb3VyaWVyIG5ldywg bW9ub3NwYWNlIj58IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHxvZiBhbsKgb3JnYW5pemF0aW9uLCDCoHwg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDwvZm9udD48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+PGZvbnQgZmFjZT0iY291cmllciBuZXcsIG1vbm9zcGFjZSI+fCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqB8dGhlIGVudHJ5IGFsc28gaXMgwqAgwqB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8 L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGZvbnQgZmFjZT0iY291cmll ciBuZXcsIG1vbm9zcGFjZSI+fCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8cmVxdWlyZWQgdG8gY29udGFp biDCoHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDxicj58IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHxj b250YWluIHRoZSAmcXVvdDtraW5kJnF1b3Q7IMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg fDwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48Zm9udCBmYWNlPSJjb3Vy aWVyIG5ldywgbW9ub3NwYWNlIj58IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHxwcm9wZXJ0eSwgd2l0aCBh IMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfDwvZm9udD48L2Rpdj48ZGl2IGNsYXNz PSJnbWFpbF9xdW90ZSI+PGZvbnQgZmFjZT0iY291cmllciBuZXcsIG1vbm9zcGFjZSI+fCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqB8dmFsdWUgb2YgJnF1b3Q7b3JnJnF1b3Q7LiDCoCDCoCDCoHwgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgfDwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3Rl Ij48Zm9udCBmYWNlPSJjb3VyaWVyIG5ldywgbW9ub3NwYWNlIj58IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB8PGJyPnxEZXZpY2VPd25lciDCoCDCoCDCoHxvcGVyYXRvciDCoCDCoCDCoCDCoCB8dkNhcmQg wqAgwqAgwqAgwqAgwqAgfFRoZSBvcGVyYXRvciBlbnRyeSBpc3wgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgfDwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48Zm9udCBmYWNl PSJjb3VyaWVyIG5ldywgbW9ub3NwYWNlIj58IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHwuLi4gwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+PC9mb250 PjxkaXY+PGZvbnQgZmFjZT0iY291cmllciBuZXcsIG1vbm9zcGFjZSI+Ky0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKzwvZm9udD48L2Rpdj4NCjxkaXY+PGJyPjwvZGl2PjxkaXY+ wqBiKSBBZGQgc3ViLXJlZ2lzdHJ5ICZxdW90O0FkZGl0aW9uYWwgUmVxdWlyZW1lbnRzIGZvciBS dWxlc2V0IElkZW50aWZpZXI9RVRTSS1FTi0zMDEtNTk4LTEuMS4xJnF1b3Q7IGFuZCBhIHNpbmds ZSB0YWJsZSBzaW1pbGFyIHRvIHRoZSBhYm92ZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlF1 ZXN0aW9uczo8L2Rpdj48ZGl2PsKgLSBXb3VsZCBzb21ldGhpbmcgbGlrZSB0aGF0IHdvcms/PC9k aXY+DQo8ZGl2PsKgLSBJZiBzbywgc2hvdWxkIEkgdXBkYXRlIHRoZSBSRkMgZHJhZnQgdG8gcmVm bGVjdCB0aGUgYWJvdmU/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Bbm90aGVyIG9wdGlvbiBp cyB0byBwcmVzZXJ2ZSB0aGUgdGV4dCBhcy1pcyBhcyB0aGUgJnF1b3Q7dGVtcGxhdGUmcXVvdDsg YW5kIHJlZmVyIHRvIGl0IHZpYSBhIGxpbmssIGxpa2XCoDxhIGhyZWY9Imh0dHA6Ly93d3cuaWFu YS5vcmcvYXNzaWdubWVudHMvbGFuZy1zdWJ0YWdzLXRlbXBsYXRlcy9sYW5nLXN1YnRhZ3MtdGVt cGxhdGVzLnhodG1sIj5odHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2xhbmctc3VidGFn cy10ZW1wbGF0ZXMvbGFuZy1zdWJ0YWdzLXRlbXBsYXRlcy54aHRtbDwvYT48L2Rpdj4NCjxkaXY+ PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdC13aWR0aDoxcHg7Ym9y ZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTtib3JkZXItbGVmdC1zdHlsZTpzb2xpZDtw YWRkaW5nLWxlZnQ6MWV4Ij48YnI+DQo8YnI+DQoyKSBXZSB1bmRlcnN0YW5kIHRoYXQgJnF1b3Q7 U3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKSZxdW90OyBpcyB0aGUgY29sdW1uIGZvciBSZWZlcmVu Y2UuPGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Plllcy4gQWdyZWVkLjwvZGl2 PjxkaXY+wqA8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQtd2lkdGg6MXB4O2JvcmRlci1sZWZ0LWNv bG9yOnJnYigyMDQsMjA0LDIwNCk7Ym9yZGVyLWxlZnQtc3R5bGU6c29saWQ7cGFkZGluZy1sZWZ0 OjFleCI+DQoNCjxicj4NClNlY29uZCwgaW4gdGhlIFBBV1MgUmVnaXN0cnkgY3JlYXRlZCBhYm92 ZSwgYSBuZXcgcmVnaXN0cnkgY2FsbGVkIHRoZSBQQVdTIFBhcmFtZXRlciBSZWdpc3RyeSB3aWxs IGJlIGNyZWF0ZWQuwqAgRWFjaCBlbnRyeSBpbiB0aGUgcmVnaXN0cnkgaGFzIGEgcGFyYW1ldGVy IG5hbWUsIHBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbiBhbmQgYSBzcGVjaWZpY2F0aW9uLjxicj4N Cjxicj4NCjxicj4NCk5ldyBlbnRpcmVzIGluIHRoaXMgcmVnaXN0cnkgYXJlIGRvbmUgdGhyb3Vn aCBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIGFzIGRlZmluZWQgaW4gUkZDIDUyMjYuPGJyPg0KPGJy Pg0KVGhlcmUgYXJlIHNldmVuIGluaXRpYWwgZW50cmllcyBpbiB0aGlzIG5ldyByZWdpc3RyeSBh cyBmb2xsb3dzOjxicj4NCjxicj4NClBhcmFtZXRlciBuYW1lOsKgIGZjY0lkPGJyPg0KUGFyYW1l dGVyIHVzYWdlIGxvY2F0aW9uOsKgIERldmljZURlc2NyaXB0b3I8YnI+DQpTcGVjaWZpY2F0aW9u IGRvY3VtZW50KHMpOsKgIFsgUkZDLXRvLWJlIF08YnI+DQo8YnI+DQpQYXJhbWV0ZXIgbmFtZTrC oCBmY2NUdmJkRGV2aWNlVHlwZTxicj4NClBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjrCoCBEZXZp Y2VEZXNjcmlwdG9yPGJyPg0KU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKTrCoCBbIFJGQy10by1i ZSBdPGJyPg0KPGJyPg0KUGFyYW1ldGVyIG5hbWU6wqAgZXRzaUVuRGV2aWNlVHlwZTxicj4NClBh cmFtZXRlciB1c2FnZSBsb2NhdGlvbjrCoCBEZXZpY2VEZXNjcmlwdG9yPGJyPg0KU3BlY2lmaWNh dGlvbiBkb2N1bWVudChzKTrCoCBTcGVjaWZpZXMgdGhlIFdoaXRlIFNwYWNlIERldmljZSB0eXBl LCBhcyBkZWZpbmVkIGJ5IHRoZSBFVFNJIEhhcm1vbml6ZWQgU3RhbmRhcmQgLSBbIDxhIGhyZWY9 Imh0dHA6Ly93d3cuZXRzaS5vcmcvZGVsaXZlci9ldHNpX2VuLzMwMTUwMF8zMDE1OTkvMzAxNTk4 LzAxLjAxLjAxXzYwL2VuXzMwMTU5OHYwMTAxMDFwLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6 Ly93d3cuZXRzaS5vcmcvZGVsaXZlci9ldHNpX2VuLzMwMTUwMF8zMDE1OTkvMzAxNTk4LzAxLjAx LjAxXzYwL2VuXzMwMTU5OHYwMTAxMDFwLnBkZjwvYT4gXTxicj4NCg0KPGJyPg0KUGFyYW1ldGVy IG5hbWU6wqAgZXRzaUVuRGV2aWNlRW1pc3Npb25zQ2xhc3M8YnI+DQpQYXJhbWV0ZXIgdXNhZ2Ug bG9jYXRpb246wqAgRGV2aWNlRGVzY3JpcHRvcjxicj4NClNwZWNpZmljYXRpb24gZG9jdW1lbnQo cyk6wqAgU3BlY2lmaWVzIHRoZSBXaGl0ZSBTcGFjZSBEZXZpY2UgZW1pc3Npb25zIGNsYXNzLCBh cyBkZWZpbmVkIGJ5IHRoZSBFVFNJIEhhcm1vbml6ZWQgU3RhbmRhcmQgLSBbIDxhIGhyZWY9Imh0 dHA6Ly93d3cuZXRzaS5vcmcvZGVsaXZlci9ldHNpX2VuLzMwMTUwMF8zMDE1OTkvMzAxNTk4LzAx LjAxLjAxXzYwL2VuXzMwMTU5OHYwMTAxMDFwLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93 d3cuZXRzaS5vcmcvZGVsaXZlci9ldHNpX2VuLzMwMTUwMF8zMDE1OTkvMzAxNTk4LzAxLjAxLjAx XzYwL2VuXzMwMTU5OHYwMTAxMDFwLnBkZjwvYT4gXTxicj4NCg0KPGJyPg0KUGFyYW1ldGVyIG5h bWU6wqAgZXRzaUVuVGVjaG5vbG9neUlkPGJyPg0KUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOsKg IERldmljZURlc2NyaXB0b3I8YnI+DQpTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOsKgIFNwZWNp ZmllcyB0aGUgV2hpdGUgU3BhY2UgRGV2aWNlIHRlY2hub2xvZ3kgaWRlbnRpZmllciwgYXMgZGVm aW5lZCBieSB0aGUgRVRTSSBIYXJtb25pemVkIFN0YW5kYXJkIC0gWyA8YSBocmVmPSJodHRwOi8v d3d3LmV0c2kub3JnL2RlbGl2ZXIvZXRzaV9lbi8zMDE1MDBfMzAxNTk5LzMwMTU5OC8wMS4wMS4w MV82MC9lbl8zMDE1OTh2MDEwMTAxcC5wZGYiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmV0 c2kub3JnL2RlbGl2ZXIvZXRzaV9lbi8zMDE1MDBfMzAxNTk5LzMwMTU5OC8wMS4wMS4wMV82MC9l bl8zMDE1OTh2MDEwMTAxcC5wZGY8L2E+IF08YnI+DQoNCjxicj4NClBhcmFtZXRlciBuYW1lOsKg IGV0c2lFbkRldmljZUNhdGVnb3J5PGJyPg0KUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOsKgIERl dmljZURlc2NyaXB0b3I8YnI+DQpTcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOsKgIFNwZWNpZmll cyB0aGUgV2hpdGUgU3BhY2UgRGV2aWNlIGNhdGVnb3J5LCBhcyBkZWZpbmVkIGJ5IHRoZSBFVFNJ IEhhcm1vbml6ZWQgU3RhbmRhcmQgLSBbIDxhIGhyZWY9Imh0dHA6Ly93d3cuZXRzaS5vcmcvZGVs aXZlci9ldHNpX2VuLzMwMTUwMF8zMDE1OTkvMzAxNTk4LzAxLjAxLjAxXzYwL2VuXzMwMTU5OHYw MTAxMDFwLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuZXRzaS5vcmcvZGVsaXZlci9l dHNpX2VuLzMwMTUwMF8zMDE1OTkvMzAxNTk4LzAxLjAxLjAxXzYwL2VuXzMwMTU5OHYwMTAxMDFw LnBkZjwvYT4gXTxicj4NCg0KPGJyPg0KUGFyYW1ldGVyIG5hbWU6wqAgZXRzaUVuU2ltdWx0YW5l b3VzQ2hhbm5lbE9wZXJhdGlvblJlc3RyaWN0aW9uPGJyPg0KUGFyYW1ldGVyIHVzYWdlIGxvY2F0 aW9uOsKgIFNwZWN0cnVtU3BlYzxicj4NClNwZWNpZmljYXRpb24gZG9jdW1lbnQocyk6wqAgU3Bl Y2lmaWVzIHRoZSBjb25zdHJhaW50IG9uIHRoZSBkZXZpY2UgbWF4aW11bSB0b3RhbCBFSVJQLCBh cyBkZWZpbmVkIGJ5IHRoZSBFVFNJIEhhcm1vbml6ZWQgU3RhbmRhcmQgLSBbIDxhIGhyZWY9Imh0 dHA6Ly93d3cuZXRzaS5vcmcvZGVsaXZlci9ldHNpX2VuLzMwMTUwMF8zMDE1OTkvMzAxNTk4LzAx LjAxLjAxXzYwL2VuXzMwMTU5OHYwMTAxMDFwLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93 d3cuZXRzaS5vcmcvZGVsaXZlci9ldHNpX2VuLzMwMTUwMF8zMDE1OTkvMzAxNTk4LzAxLjAxLjAx XzYwL2VuXzMwMTU5OHYwMTAxMDFwLnBkZjwvYT4gXTxicj4NCg0KPGJyPg0KVGhpcmQsIGluIHRo ZSBQQVdTIFJlZ2lzdHJ5IGNyZWF0ZWQgYWJvdmUsIGEgbmV3IHJlZ2lzdHJ5IGNhbGxlZCB0aGUg UEFXUyBFcnJvciBDb2RlIFJlZ2lzdHJ5IHdpbGwgYmUgY3JlYXRlZC7CoCBFYWNoIGVudHJ5IGlu IHRoZSByZWdpc3RyeSBoYXMgYW4gZXJyb3IgY29kZSwgbmFtZSwgZGVzY3JpcHRpb24sIGFkZGl0 aW9uYWwgcGFyYW1ldGVycyBhbmQgcmVmZXJlbmNlPGJyPg0KPGJyPg0KTmV3IGVudHJpZXMgaW4g dGhpcyByZWdpc3RyeSBhcmUgZG9uZSB0aHJvdWdoIFNwZWNpZmljYXRpb24gUmVxdWlyZWQgYXMg ZGVmaW5lZCBpbiBSRkMgNTIyNi48YnI+DQo8YnI+DQpUaGVyZSBhcmUgbmV3IGVudHJpZXMgaW4g dGhpcyBzdWJyZWdpc3RyeSwgYWxsIHdpdGggYSByZWZlcmVuY2Ugb2YgWyBSRkMtdG8tYmUgXSwg YXMgZm9sbG93czo8YnI+DQo8YnI+DQpDb2RlwqAgwqBOYW1lwqAgwqAgwqAgwqAgwqAgwqAgwqBE ZXNjcmlwdGlvbiAmYW1wOyBBZGRpdGlvbmFsIHBhcmFtZXRlcnM8YnI+DQotLS0tLS0gLS0tLS0t LS0tLS0tLS0tLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 YnI+DQozMjc2NyB0byAxwqAgwqAgwqAgwqAgwqAgwqAgVW5hc3NpZ25lZDxicj4NCjDCoCDCoCDC oCAocmVzZXJ2ZWQpPGJyPg0KLTEwMMKgIMKgKHJlc2VydmVkKTxicj4NCi0xMDHCoCDCoFZFUlNJ T07CoCDCoCDCoCDCoCDCoCBUaGUgRGF0YWJhc2UgZG9lcyBub3Qgc3VwcG9ydCB0aGUgc3BlY2lm aWVkPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdmVyc2lvbiBvZiB0 aGUgbWVzc2FnZS48YnI+DQotMTAywqAgwqBVTlNVUFBPUlRFRMKgIMKgIMKgIFRoZSBEYXRhYmFz ZSBkb2VzIG5vdCBzdXBwb3J0IHRoZSBEZXZpY2UuIEZvcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIGV4YW1wbGUsIGl0IGRvZXMgbm90IHN1cHBvcnQgdGhlIHJ1bGVz ZXQ8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBzcGVjaWZpZWQgaW4g dGhlIHJlcXVlc3QuPGJyPg0KLTEwM8KgIMKgVU5JTVBMRU1FTlRFRMKgIMKgIFRoZSBEYXRhYmFz ZSBkb2VzIG5vdCBpbXBsZW1lbnQgdGhlIG9wdGlvbmFsPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgcmVxdWVzdCBvciBvcHRpb25hbCBmZWF0dXJlLjxicj4NCi0xMDTC oCDCoE9VVFNJREVfQ09WRVJBR0UgVGhlIHNwZWNpZmllZCBnZW8tbG9jYXRpb24gaXMgb3V0c2lk ZSB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBjb3ZlcmFnZSBh cmVhIG9mIHRoZSBEYXRhYmFzZS4gVGhlIERhdGFiYXNlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgTUFZIGluY2x1ZGUgYSBEYlVwZGF0ZVNwZWM8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwYXJhbWV0ZXIgdG8gcHJvdmlkZSBhIGxpc3Qg b2YgYWx0ZXJuYXRlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGF0 YWJhc2VzIHRoYXQgbWlnaHQgYmUgYXBwcm9wcmlhdGUgZm9yIHRoZTxicj4NCsKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHJlcXVlc3RlZCBsb2NhdGlvbi4gU2VlIE9VVFNJREVf Q09WRVJBR0U8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBFcnJvciBm b3IgbW9yZSBkZXRhaWxzLjxicj4NCi0xMDXCoCDCoERBVEFCQVNFX0NIQU5HRcKgIFRoZSBEYXRh YmFzZSBoYXMgY2hhbmdlZCBpdHMgVVJJLiBUaGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBEYXRhYmFzZSBNQVkgaW5jbHVkZSBhIERiVXBkYXRlU3BlYzxicj4NCsKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHBhcmFtZXRlciBpbiB0aGUgZXJyb3Ig cmVzcG9uc2U8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB0byBwcm92 aWRlIGRldmljZXMgd2l0aCBvbmUgb3IgbW9yZSBhbHRlcm5hdGU8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBkYXRhYmFzZSBVUklzLiBUaGUgRGV2aWNlIG5lZWRzIHRv IHVzZSB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBpbmZvcm1h dGlvbiB0byB1cGRhdGUgaXRzIGxpc3Qgb2Y8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBwcmVjb25maWd1cmVkIGRhdGFiYXNlcyB0byByZXBsYWNlIChvbmx5KSBpdHM8 YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBlbnRyeSBmb3IgdGhlIHJl c3BvbmRpbmcgRGF0YWJhc2Ugd2l0aCB0aGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCBsaXN0IG9mIGFsdGVybmF0ZSBkYXRhYmFzZSBVUklzLiBTZWU8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEQVRBQkFTRV9DSEFOR0UgRXJyb3IgZm9y PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgbW9yZSBkZXRhaWxzLjxi cj4NCi0yMDDCoCDCoChyZXNlcnZlZCk8YnI+DQotMjAxwqAgwqBNSVNTSU5HwqAgwqAgwqAgwqAg wqAgQSByZXF1aXJlZCBwYXJhbWV0ZXIgaXMgbWlzc2luZy4gVGhlIERhdGFiYXNlPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgTVVTVCBpbmNsdWRlIGEgbGlzdCBvZiB0 aGUgcmVxdWlyZWQgcGFyYW1ldGVyPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgbmFtZXMuIFRoZSBEYXRhYmFzZSBNQVkgaW5jbHVkZSBvbmx5IG5hbWVzIG9mPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgcGFyYW1ldGVycyB0aGF0IGFyZSBt aXNzaW5nLCBidXQgTUFZIGluY2x1ZGU8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBhIGZ1bGwgbGlzdC4gSW5jbHVkaW5nIHRoZSBmdWxsIGxpc3Qgb2Y8YnI+DQrCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBtaXNzaW5nIHBhcmFtZXRlcnMgbWF5IHJl ZHVjZSB0aGUgbnVtYmVyIG9mPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgcmUtcXVlcmllcyBmcm9tIHRoZSBEZXZpY2UuIFNlZSBNSVNTSU5HIEVycm9yPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZm9yIG1vcmUgZGV0YWlscy48YnI+DQot MjAywqAgwqBJTlZBTElEX1ZBTFVFwqAgwqAgQSBwYXJhbWV0ZXIgdmFsdWUgaXMgaW52YWxpZCBp biBzb21lIHdheS4gVGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg RGF0YWJhc2UgU0hPVUxEIGluY2x1ZGUgYSBtZXNzYWdlIGluZGljYXRpbmc8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB3aGljaCBwYXJhbWV0ZXIgYW5kIHdoeSBpdHMg dmFsdWUgaXMgaW52YWxpZC48YnI+DQotMzAwwqAgwqAocmVzZXJ2ZWQpPGJyPg0KLTMwMcKgIMKg VU5BVVRIT1JJWkVEwqAgwqAgwqBUaGUgRGV2aWNlIGlzIG5vdCBhdXRob3JpemVkIHRvIHVzZWQg dGhlPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRGF0YWJhc2UuIEF1 dGhvcml6YXRpb24gbWF5IGJlIGRldGVybWluZWQgYnk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB0aGUgcnVsZXNldCBvciBiZSBkZXBlbmRlbnQgb24gcHJpb3I8YnI+ DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBhcnJhbmdlbWVudCBiZXR3ZWVu IHRoZSBEZXZpY2UgYW5kIERhdGFiYXNlLjxicj4NCi0zMDLCoCDCoE5PVF9SRUdJU1RFUkVEwqAg wqBEZXZpY2UgcmVnaXN0cmF0aW9uIHJlcXVpcmVkLCBidXQgdGhlIERldmljZTxicj4NCsKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGlzIG5vdCByZWdpc3RlcmVkLjxicj4NCi0z MjAwMCAocmVzZXJ2ZWQpwqAgwqAgwqAgwqBSZXNlcnZlZCBmb3IgSlNPTi1SUEMgZXJyb3IgY29k ZXMuPGJyPg0KdG88YnI+DQotMzI3Njg8YnI+DQo8YnI+DQpJQU5BIHVuZGVyc3RhbmRzIHRoYXQg dGhlc2UgdGhyZWUgYWN0aW9ucyBhcmUgdGhlIG9ubHkgb25lcyByZXF1aXJlZCB0byBiZSBjb21w bGV0ZWQgdXBvbiBhcHByb3ZhbCBvZiB0aGlzIGRvY3VtZW50Ljxicj4NCjxicj4NCk5vdGU6wqAg VGhlIGFjdGlvbnMgcmVxdWVzdGVkIGluIHRoaXMgZG9jdW1lbnQgd2lsbCBub3QgYmUgY29tcGxl dGVkIHVudGlsIHRoZSBkb2N1bWVudCBoYXMgYmVlbiBhcHByb3ZlZCBmb3IgcHVibGljYXRpb24g YXMgYW4gUkZDLiBUaGlzIG1lc3NhZ2UgaXMgb25seSB0byBjb25maXJtIHdoYXQgYWN0aW9ucyB3 aWxsIGJlIHBlcmZvcm1lZC48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KPGJyPg0KUGVhcmwgTGlh bmc8YnI+DQpJQ0FOTjxicj4NCjxicj4NCihFTkQgSUFOQSBMQVNUIENBTEwgQ09NTUVOVFMpPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gV2VkIEF1ZyAwNiAyMTowOTo1NyAyMDE0LCA8YSBocmVm PSJtYWlsdG86aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmciPmllc2ctc2VjcmV0YXJ5QGlldGYub3Jn PC9hPiB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSBy ZXF1ZXN0IGZyb20gdGhlIFByb3RvY29sIHRvIEFjY2VzcyBXUyBkYXRhYmFzZTxicj4NCiZndDsg V0cgKHBhd3MpIHRvIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6PGJyPg0KJmd0OyAt ICYjMzk7UHJvdG9jb2wgdG8gQWNjZXNzIFdoaXRlLVNwYWNlIChQQVdTKSBEYXRhYmFzZXMmIzM5 Ozxicj4NCiZndDvCoCDCoCZsdDtkcmFmdC1pZXRmLXBhd3MtcHJvdG9jb2wtMTQudHh0Jmd0OyBh cyBQcm9wb3NlZCBTdGFuZGFyZDxicj4NCiZndDs8YnI+DQomZ3Q7IEEgcHJpb3IgTGFzdCBDYWxs IHdhcyBtYWRlIGZvciB2ZXJzaW9uIC0xMiBvZiB0aGlzIGRvY3VtZW50LiBDb21tZW50czxicj4N CiZndDsgcmVjZWl2ZWQgZHVyaW5nIHRoYXQgZGlzY3Vzc2lvbiBsZWFkIHRvIGV4dGVuc2l2ZSBl ZGl0cyB0byB0aGUgZG9jdW1lbnQsPGJyPg0KJmd0OyB3aGljaCBjb3VsZCBiZW5lZml0IGZyb20g YSBzZWNvbmQgcmV2aWV3Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBJRVNHIHBsYW5zIHRvIG1h a2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0czxicj4NCiZn dDsgZmluYWwgY29tbWVudHMgb24gdGhpcyBhY3Rpb24uIFBsZWFzZSBzZW5kIHN1YnN0YW50aXZl IGNvbW1lbnRzIHRvIHRoZTxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmci PmlldGZAaWV0Zi5vcmc8L2E+IG1haWxpbmcgbGlzdHMgYnkgMjAxNC0wOC0yMC4gRXhjZXB0aW9u YWxseSwgY29tbWVudHMgbWF5IGJlPGJyPg0KJmd0OyBzZW50IHRvIDxhIGhyZWY9Im1haWx0bzpp ZXNnQGlldGYub3JnIj5pZXNnQGlldGYub3JnPC9hPiBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwg cGxlYXNlIHJldGFpbiB0aGU8YnI+DQomZ3Q7IGJlZ2lubmluZyBvZiB0aGUgU3ViamVjdCBsaW5l IHRvIGFsbG93IGF1dG9tYXRlZCBzb3J0aW5nLjxicj4NCiZndDs8YnI+DQomZ3Q7IEFic3RyYWN0 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7wqAgwqAgUG9ydGlvbnMgb2YgdGhlIHJhZGlv IHNwZWN0cnVtIHRoYXQgYXJlIGFsbG9jYXRlZCB0byBsaWNlbnNlZXMgYXJlPGJyPg0KJmd0O8Kg IMKgIGF2YWlsYWJsZSBmb3Igbm9uLWludGVyZmVyaW5nIHVzZS7CoCBUaGlzIGF2YWlsYWJsZSBz cGVjdHJ1bSBpcyBjYWxsZWQ8YnI+DQomZ3Q7wqAgwqAgJnF1b3Q7V2hpdGUgU3BhY2UuJnF1b3Q7 wqAgQWxsb3dpbmcgc2Vjb25kYXJ5IHVzZXJzIGFjY2VzcyB0byBhdmFpbGFibGUgc3BlY3RydW08 YnI+DQomZ3Q7wqAgwqAgJnF1b3Q7dW5sb2NrcyZxdW90OyBleGlzdGluZyBzcGVjdHJ1bSB0byBt YXhpbWl6ZSBpdHMgdXRpbGl6YXRpb24gYW5kIHRvPGJyPg0KJmd0O8KgIMKgIHByb3ZpZGUgb3Bw b3J0dW5pdGllcyBmb3IgaW5ub3ZhdGlvbiwgcmVzdWx0aW5nIGluIGdyZWF0ZXIgb3ZlcmFsbDxi cj4NCiZndDvCoCDCoCBzcGVjdHJ1bSB1dGlsaXphdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0O8Kg IMKgIE9uZSBhcHByb2FjaCB0byBtYW5hZ2luZyBzcGVjdHJ1bSBzaGFyaW5nIHVzZXMgZGF0YWJh c2VzIHRvIHJlcG9ydDxicj4NCiZndDvCoCDCoCBzcGVjdHJ1bSBhdmFpbGFiaWxpdHkgdG8gZGV2 aWNlcy7CoCBUbyBhY2hpZXZlIGludGVyb3BlcmFiaWxpdHkgYW1vbmc8YnI+DQomZ3Q7wqAgwqAg bXVsdGlwbGUgZGV2aWNlcyBhbmQgZGF0YWJhc2VzLCBhIHN0YW5kYXJkaXplZCBwcm90b2NvbCBt dXN0IGJlPGJyPg0KJmd0O8KgIMKgIGRlZmluZWQgYW5kIGltcGxlbWVudGVkLsKgIFRoaXMgZG9j dW1lbnQgZGVmaW5lcyBzdWNoIGEgcHJvdG9jb2wsIHRoZTxicj4NCiZndDvCoCDCoCAmcXVvdDtQ cm90b2NvbCB0byBBY2Nlc3MgV2hpdGUgU3BhY2UgKFBBV1MpIERhdGFiYXNlcyZxdW90Oy48YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgZmlsZSBj YW4gYmUgb2J0YWluZWQgdmlhPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcGF3cy1wcm90b2NvbC8iIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcGF3cy1wcm90b2NvbC88 L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgSUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZp YTxicj4NCiZndDsgPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLXBhd3MtcHJvdG9jb2wvYmFsbG90LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wYXdzLXByb3RvY29sL2JhbGxvdC88L2E+ PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBmb2xsb3dpbmcgSVBSIERlY2xhcmF0 aW9ucyBtYXkgYmUgcmVsYXRlZCB0byB0aGlzIEktRDo8YnI+DQomZ3Q7PGJyPg0KJmd0O8KgIMKg IDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMjIwMy8iIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzIyMDMvPC9hPjxicj4NCiZn dDvCoCDCoCA8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzIzNDAvIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yMzQwLzwvYT48 YnI+DQomZ3Q7wqAgwqAgPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8y MjM5LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMjIz OS88L2E+PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KPGJyPg0KPGJyPg0KPC9i bG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGRpdj48YnI+PC9kaXY+LS0gPGJy Pi12aW5jZQ0KPC9kaXY+PC9kaXY+DQo= --001a1132e2102511470500af2e29-- --------------060804020405070503010906-- From nobody Tue Aug 19 18:56:37 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA74B1A6FE0 for ; Tue, 19 Aug 2014 18:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.669 X-Spam-Level: X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTdQuysnwlsM for ; Tue, 19 Aug 2014 18:56:26 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1DA71A6F73 for ; Tue, 19 Aug 2014 18:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408499783; x=1440035783; h=message-id:date:from:mime-version:to:subject; bh=H+L5bQy3i9sv4ro2OrJKIfbDtVcxpqqFzwk+DYiKlf4=; b=C+PHlsZqPeCw+/pmokS9p4QoktngOeumwcd2NVqnSd1xtKdzcL46X/Vj mwvzCQ9K/JAJqRz//RcncN4wQk4aaQUuvu9Is32GcF+Uy3HNBQ4R1czNX niQzWxAHhVXap9yJ+5T5Nb/l+bEdA9dl68fatRoWdLCDtxRF8x0xBJeiu 0=; X-IronPort-AV: E=McAfee;i="5600,1067,7535"; a="72558127" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 19 Aug 2014 18:56:23 -0700 X-IronPort-AV: E=Sophos;i="5.01,898,1400050800"; d="eml'208?scan'208,208";a="734550803" Received: from nasanexhc02.na.qualcomm.com ([10.46.56.110]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2014 18:56:23 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC02.na.qualcomm.com (10.46.56.110) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:56:23 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:56:22 -0700 Message-ID: <53F40045.2040405@qti.qualcomm.com> Date: Tue, 19 Aug 2014 20:56:21 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "paws@ietf.org" Content-Type: multipart/mixed; boundary="------------090608090002060502080403" X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/JvMZvGe9PYKfUuIU7F9gRGeqTYA Subject: [paws] Fwd: [IANA #777162] Re: Second Last Call: (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 01:56:29 -0000 --------------090608090002060502080403 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit --------------090608090002060502080403 Content-Type: message/rfc822; name="[IANA #777162] Re: Second Last Call: (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="[IANA #777162] Re: Second Last Call: X-Original-To: presnick@dev-presnick.qualcomm.com Delivered-To: presnick@dev-presnick.qualcomm.com Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by dev-presnick.qualcomm.com (Postfix) with ESMTPS id 5005C4055C for ; Tue, 19 Aug 2014 09:56:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,895,1400050800"; d="scan'208";a="787738686" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2014 09:56:41 -0700 Resent-From: Received: from Ironmsg03-L.qualcomm.com (172.30.48.1) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 09:56:40 -0700 X-IronPort-AV: E=Sophos;i="5.01,895,1400050800"; d="scan'208";a="719861579" X-ojodefuego: yes X-Forgery: (qualnet-external) Received: from gatewaypony01.qualcomm.com ([65.197.215.24]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Aug 2014 09:56:40 -0700 Received-SPF: Pass (gatewaypony01.qualcomm.com: domain of iesg-bounces@ietf.org designates 4.31.198.44 as permitted sender) identity=mailfrom; client-ip=4.31.198.44; receiver=gatewaypony01.qualcomm.com; envelope-from="iesg-bounces@ietf.org"; x-sender="iesg-bounces@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" Authentication-Results: gatewaypony01.qualcomm.com; dkim=pass (signature verified) header.i=@ietf.org X-SLBL-Result: SAFE-LISTED X-IronPort-AV: E=McAfee;i="5600,1067,7535"; a="134106866" X-DMARC-Status: PASS X-IPAS-Result: AiEEAHuA81MEH8Ysm3poAFmCanZTBIJ8rE+cfRgMh3xmFgEPAQEBAQEGCwsJFCmEBAEBAQECAQIXCQ8BDQEBBAoeCwECAwECBgEBIgICEgEMAwQCAgMBKBsQGQUEiDkBAgUFqxt4hQIBBYF3jVkRBoEshFCGIYJNEQFpAYIlDzIPA4FBhQkCgQuLFIQmhB6CWYFXjHyIR4FGbAEBAYEFBxeBKQEBBQ Received: from mail.ietf.org ([4.31.198.44]) by gatewaypony01.qualcomm.com with ESMTP; 19 Aug 2014 09:56:33 -0700 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DE41A0640; Tue, 19 Aug 2014 09:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1408467391; bh=2ijZp0YmnZ9wZBBICArn6GUwePXIntSydEIycUfS85M=; h=Subject:From:In-Reply-To:References:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Sender; b=csFrNvxXfUbG92srT0IJhF9QghQCO24Xiv6Bokb9NCWghVUNFNN9Udx/UBlnVrMXG 6hxXLB7PNqNeB86YxPTOTyH9D6whq93QsJ8UNw0dIZUCBuAg0nKAQ2NaGbNzihwoh2 258XIDSUAqXqPJIYwLrEgo1L0J2APjwNMPHZAk3w= X-Original-To: iesg@ietfa.amsl.com Delivered-To: iesg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D134B1A064F for ; Tue, 19 Aug 2014 09:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZDzMQB5PFvI for ; Tue, 19 Aug 2014 09:56:24 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA6A1A0475 for ; Tue, 19 Aug 2014 09:56:24 -0700 (PDT) Received: from request1.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id s7JGtQeW028183; Tue, 19 Aug 2014 16:55:26 GMT Received: by request1.lax.icann.org (Postfix, from userid 48) id 4F710560C56; Tue, 19 Aug 2014 16:55:26 +0000 (UTC) RT-Owner: pearl.liang Subject: [IANA #777162] Re: Second Last Call: (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard From: Pearl Liang via RT In-Reply-To: References: <20140806210932.26762.78438.idtracker@ietfa.amsl.com> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #777162 Managed-BY: RT 4.0.8 (http://www.bestpractical.com/rt/) RT-Originator: pearl.liang@icann.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Tue, 19 Aug 2014 16:55:26 +0000 Archived-At: http://mailarchive.ietf.org/arch/msg/iesg/44xb2v7qnbH7OrRuvthh86XhCJU CC: , , , , X-BeenThere: iesg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iesg-bounces@ietf.org Sender: iesg Dear authors, Please see inline comments/questions marked with [pl]. On Fri Aug 15 18:28:18 2014, vchen@google.com wrote: > Thanks for the review. > > > On Thu, Aug 14, 2014 at 10:27 AM, Pearl Liang via RT < > drafts-lastcall@iana.org> wrote: > > > (BEGIN IANA LAST CALL COMMENTS) > > > > IESG/Authors/WG Chairs: > > > > IANA has reviewed draft-ietf-paws-protocol-14. Authors should > review the > > comments and/or questions below. Please report any inaccuracies and > > respond to any questions as soon as possible. > > > > IANA has a question for one of the requested actions in this draft > > document. > > > > We received the following comments/questions from the IANA's > reviewer: > > > > IANA understands that, upon approval of this document there are > three > > actions which IANA must complete. > > > > IANA understands that this document proposes the creation of a PAWS > > protocol registry which will initially consist of three > subregistries: > > > > - the PAWS Ruleset ID Registry > > - the PAWS Parameter Registry > > - the PAWS Error Code Registry > > > > On the IANA Matrix located at: > > > > http://www.iana.org/protocols > > > > the new PAWS registry will be linked with a reference of [ RFC-to-be > ]. > > > > In the new PAWS registry there will be three sub-registries as > follows: > > > > First, in the PAWS Registry created above, a new registry called the > PAWS > > Ruleset ID Registry will be created. Each entry in the registry has > a > > ruleset name, additional parameter requirements and a specification. > > > > New entires in this registry are done through Specification Required > as > > defined in RFC 5226. > > > > There are two initial entries in this new registry as follows: > > > > Ruleset identifier: FccTvBandWhiteSpace-2010 > > Specification: This ruleset refers to the FCC rules for TV-band > White > > Space operations established in the Code of Federal Regulations > (CFR), > > Title 47, Part 15, Subpart H. > > Additional Parameter Requirements for FccTvBandWhiteSpace-2010: > > > > Available Spectrum Request > > +---------------+-----------------------------+-------------+------- > + > > | Parameter | Type | Requirement | Notes > | > > | Name | | | > | > > +---------------+-----------------------------+-------------+------- > + > > | deviceDesc | DeviceDescriptor | REQUIRED | > | > > +---------------+-----------------------------+-------------+------- > + > > > > Available Spectrum Batch Request > > +---------------+-----------------------------+------------- > +-------+ > > | Parameter | Type | Requirement | Notes > | > > | Name | | | > | > > +---------------+-----------------------------+-------------+------- > + > > | deviceDesc | DeviceDescriptor | REQUIRED | > | > > +---------------+-----------------------------+-------------+------- > + > > > > DeviceDescriptor Message > > +-------------------+--------+-------------+------------------------ > + > > | Parameter Name | Type | Requirement | Notes > | > > +-------------------+--------+-------------+------------------------ > + > > | fccId | string | REQUIRED | Specifies a device's > | > > | | | | FCC certification ID > | > > | fccTvbdDeviceType | string | REQUIRED | Specifies the FCC > | > > | | | | Device Type > | > > | | | | of > | > > | | | | TV-band White Space > | > > | | | | device, as defined by > | > > | | | | the FCC rules. > | > > +-------------------+--------+-------------+------------------------ > + > > > > DeviceOwner Message > > +-----------+------- > +-----------------------------------------------+ > > | Parameter | Type | Additional Requirement > | > > | Name | | > | > > +-----------+-------+----------------------------------------------- > + > > | owner | vCard | The owner is required to contain the > formatted| > > | | | name of an individual or organization using > | > > | | | the "fn" property. When the name is that of > an| > > | | | organization, the entry also is required to > | > > | | | contain the "kind" property, with a value of > | > > | | | "org". > | > > | operator | vCard | The operator entry is required to contain the > | > > | | | following properties for the contact person > | > > | | | responsible for the device's operation: "fn", > | > > | | | "adr", "tel", and "email". > | > > +-----------+-------+----------------------------------------------- > + > > > > Ruleset identifier: ETSI-EN-301-598-1.1.1 > > Specification document(s): This ruleset refers to the ETSI > > Harmonised Standard [ETSI-EN-301-598] established by ETSI. > > Additional Parameter Requirements: > > > > DeviceDescriptor > > +-------------------------+-------+-------------+------------------- > + > > | Parameter Name | Type | Requirement | Notes > | > > +-------------------------+-------+-------------+------------------- > + > > | manufacturerId | string| REQUIRED | Specifies a > | > > | | | | device's > | > > | | | | manufacturer's > | > > | | | | identifier. See > | > > | | | | [ RFC-to-be ] > | > > | | | | Section 5.2. > | > > | modelId | string| REQUIRED | Specifies a > | > > | | | | device's model > | > > | | | | identifier. See > | > > | | | | [ RFC-to-be ] > | > > | | | | Section 5.2. > | > > | etsiEnDeviceType | string| REQUIRED | Specifies the > | > > | | | | device's ETSI > | > > | | | | device type > | > > | | | | (Section > | > > | | | | 9.2.2.3). > | > > | etsiEnDeviceEmissionsCl | string| REQUIRED | Specifies the > | > > | ass | | | device's ETSI > | > > | | | | device emissions > | > > | | | | class (Section > | > > | | | | 9.2.2.4). > | > > | etsiEnTechnologyId | string| REQUIRED | Specifies the > | > > | | | | device's ETSI > | > > | | | | technology ID > | > > | | | | (Section > | > > | | | | 9.2.2.5). > | > > | etsiEnDeviceCategory | string| REQUIRED | Specifies the > | > > | | | | device's ETSI > | > > | | | | device category > | > > | | | | (Section > | > > | | | | 9.2.2.6). > | > > +-------------------------+-------+-------------+------------------- > + > > > > AVAIL_SPECTRUM_REQ > > +-------------+--------+-------------+------------------------------ > + > > | Parameter | Type | Requirement | Notes > | > > | Name | | | > | > > +-------------+--------+-------------+------------------------------ > + > > | requestType | string | OPTIONAL | Modifies the available- > | > > | | | | spectrum request type. If > | > > | | | | specified, the only valid > | > > | | | | value is, "Generic Slave", > | > > | | | | and the Database is required > | > > | | | | to respond with generic > | > > | | | | operating parameters for any > | > > | | | | Slave Device. > | > > +-------------+--------+-------------+------------------------------ > + > > > > Available Spectrum Batch Request > > +-------------+--------+-------------+------------------------------ > + > > | Parameter | Type | Requirement | Notes > | > > | Name | | | > | > > +-------------+--------+-------------+------------------------------ > + > > | requestType | string | OPTIONAL | Modifies the available- > | > > | | | | spectrum request type. If > | > > | | | | specified, the only valid > | > > | | | | value is, "Generic Slave", > | > > | | | | and the Database is required > | > > | | | | to respond with generic > | > > | | | | operating parameters for any > | > > | | | | Slave Device. > | > > +-------------+--------+-------------+------------------------------ > + > > > > DeviceDescriptor for AVAIL_SPECTRUM_RESP and > AVAIL_SPECTRUM_BATCH_RESP > > messages > > +--------------------------------+---------+---------- > +---------------+ > > | Parameter Name | Type | Requirem | Notes > | > > | | | ent | > | > > +--------------------------------+---------+---------- > +---------------+ > > | needsSpectrumReport | boolean | REQUIRED | The Database > | > > | | | | is required > | > > | | | | to set this > | > > | | | | to true to > | > > | | | | indicate > that | > > | | | | the device > | > > | | | | must report > | > > | | | | spectrum > | > > | | | | usage. > | > > | maxTotalBwHz | float | REQUIRED | Specifies a > | > > | | | | constraint > on | > > | | | | total > allowed | > > | | | | bandwidth. > | > > | maxContiguousBwHz | float | REQUIRED | Specifies a > | > > | | | | constraint > on | > > | | | | total > allowed | > > | | | | contiguous > | > > | | | | bandwidth. > | > > | etsiEnSimultaneousChannelOpera | string | REQUIRED | Specifies a > | > > | tionRestriction | | | constraint > on | > > | | | | simultaneous > | > > | | | | channel > | > > | | | | operation > | > > | | | | (Section > | > > | | | | 9.2.2.7). If > | > > | | | | it is not > | > > | | | | provided, > the | > > | | | | default > value | > > | | | | is "0". > | > > +--------------------------------+---------+---------- > +---------------+ > > > > RulesetInfo > > +-------------------+-------+-------------+------------------------- > + > > | Parameter Name | Type | Requirement | Notes > | > > +-------------------+-------+-------------+------------------------- > + > > | maxLocationChange | float | OPTIONAL | Specifies a constraint > | > > | | | | on maximum location > | > > | | | | changes. > | > > +-------------------+-------+-------------+------------------------- > + > > > > QUESTION/Note: > > 1) It appears that this document defines multiple tables for > Additional > > Parameter > > Requirements for each Ruleset ID entry in the new requested sub- > registry > > "PAWS > > Ruleset ID Registry" of the new created PAWS protocol registry. How > do > > the authors > > want the registration information presented in the namespace (aka > website)? > > You can visit the following registry that shows a list of sub- > registries > > for iSCSI > > Parameters, and more sub-registries under a sub-registry "iSCSI > Login > > Response > > Status Codes": > > > > http://www.iana.org/assignments/iscsi-parameters > > > Thanks for the pointer to the example. To use this, I can see > organizing it > as follows: > > a) Add a sub-registry "Additional Requirements for Ruleset > Identifier=FccTvBandWhiteSpace-2010", and the multiple tables in the > draft > can be collapsed into a single table with an additional "Location" > column, > e.g.,: > > +-------------------------------------------------------------------------------------------- > + > | Location | Parameter Name | Type | Requirement > | Notes | > +-----------------+-----------------+---------------- > +---------------------+-----------------+ > |Available |deviceDesc |DeviceDescriptor| REQUIRED > | | > |Spectrum | | | > | | > |Request | | | > | | > | | | | > | | > |Available |deviceDesc |DeviceDescriptor| REQUIRED > | | > |Spectrum | | | > | | > |Batch | | | > | | > |Request | | | > | | > | | | | > | | > |DeviceDescriptor |fccId |string |REQUIRED > |Specifies a | > | | | | > |device's FCC | > | | | | > |certification ID | > | | | | > | | > |DeviceDescriptor |fccTvbdDeviceType| | > | | > | | | | > | | > |DeviceOwner |owner |vCard |The owner is > required| | > | | | |to contain the > | | > | | | |formatted name > of an > | | > | | | |individual or > | | > | | | |organization > using > | | > | | | |the "fn" > property. > | | > | | | |When the name is > that| | > | | | |of an > organization, > | | > | | | |the entry also > is > | | > | | | |required to > contain > | | > | | | |contain the > "kind" > | | > | | | |property, with a > | | > | | | |value of "org". > | | > | | | | > | | > |DeviceOwner |operator |vCard |The operator > entry > is| | > | | | |... > | | > +-------------------------------------------------------------------------------------------- > + > > b) Add sub-registry "Additional Requirements for Ruleset > Identifier=ETSI-EN-301-598-1.1.1" and a single table similar to the > above. > > Questions: > - Would something like that work? > - If so, should I update the RFC draft to reflect the above? > > Another option is to preserve the text as-is as the "template" and > refer to > it via a link, like > http://www.iana.org/assignments/lang-subtags-templates/lang-subtags- > templates.xhtml > > [pl] The authors should decide the format and let IANA know the consensus. You should document all IANA actions in the IC section. If you were suggested otherwise, please let us know. You are suggesting to create new sub-registries for Additional Parameter Requirements. Are you suggesting separate Additional Parameter Requirements sub-registries for each Ruleset ID, i.e. FccTvBandWhiteSpace-2010, ETSI-EN-301-598-1.1.1, and later new Ruleset IDs in future drafts? How can a new request for a new PAWS Ruleset ID update the new PAWS Ruleset ID registry and sub-registry Additional Parameter Requirements? keep creating separate table for Additional Parameter Requirements? > > > > > 2) We understand that "Specification document(s)" is the column for > > Reference. > > > > Yes. Agreed. > [pl] Should the same registration procedure apply to all new created Additional Parameter Requirements sub-registries, if you choose to use that? > > > > > Second, in the PAWS Registry created above, a new registry called > the PAWS > > Parameter Registry will be created. Each entry in the registry has > a > > parameter name, parameter usage location and a specification. > > > > > > New entires in this registry are done through Specification Required > as > > defined in RFC 5226. > > > > There are seven initial entries in this new registry as follows: > > > > Parameter name: fccId > > Parameter usage location: DeviceDescriptor > > Specification document(s): [ RFC-to-be ] > > > > Parameter name: fccTvbdDeviceType > > Parameter usage location: DeviceDescriptor > > Specification document(s): [ RFC-to-be ] > > > > Parameter name: etsiEnDeviceType > > Parameter usage location: DeviceDescriptor > > Specification document(s): Specifies the White Space Device type, > as > > defined by the ETSI Harmonized Standard - [ > > > http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf > > ] > > > > Parameter name: etsiEnDeviceEmissionsClass > > Parameter usage location: DeviceDescriptor > > Specification document(s): Specifies the White Space Device > emissions > > class, as defined by the ETSI Harmonized Standard - [ > > > http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf > > ] > > > > Parameter name: etsiEnTechnologyId > > Parameter usage location: DeviceDescriptor > > Specification document(s): Specifies the White Space Device > technology > > identifier, as defined by the ETSI Harmonized Standard - [ > > > http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf > > ] > > > > Parameter name: etsiEnDeviceCategory > > Parameter usage location: DeviceDescriptor > > Specification document(s): Specifies the White Space Device > category, as > > defined by the ETSI Harmonized Standard - [ > > > http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf > > ] > > > > Parameter name: etsiEnSimultaneousChannelOperationRestriction > > Parameter usage location: SpectrumSpec > > Specification document(s): Specifies the constraint on the device > maximum > > total EIRP, as defined by the ETSI Harmonized Standard - [ > > > http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf > > ] > > > > Third, in the PAWS Registry created above, a new registry called the > PAWS > > Error Code Registry will be created. Each entry in the registry has > an > > error code, name, description, additional parameters and reference > > > > New entries in this registry are done through Specification Required > as > > defined in RFC 5226. > > > > There are new entries in this subregistry, all with a reference of [ > > RFC-to-be ], as follows: > > > > Code Name Description & Additional parameters > > ------ ---------------- > --------------------------------------------- > > 32767 to 1 Unassigned > > 0 (reserved) > > -100 (reserved) > > -101 VERSION The Database does not support the specified > > version of the message. > > -102 UNSUPPORTED The Database does not support the Device. > For > > example, it does not support the ruleset > > specified in the request. > > -103 UNIMPLEMENTED The Database does not implement the optional > > request or optional feature. > > -104 OUTSIDE_COVERAGE The specified geo-location is outside the > > coverage area of the Database. The Database > > MAY include a DbUpdateSpec > > parameter to provide a list of alternate > > databases that might be appropriate for the > > requested location. See OUTSIDE_COVERAGE > > Error for more details. > > -105 DATABASE_CHANGE The Database has changed its URI. The > > Database MAY include a DbUpdateSpec > > parameter in the error response > > to provide devices with one or more > alternate > > database URIs. The Device needs to use the > > information to update its list of > > preconfigured databases to replace (only) > its > > entry for the responding Database with the > > list of alternate database URIs. See > > DATABASE_CHANGE Error for > > more details. > > -200 (reserved) > > -201 MISSING A required parameter is missing. The > Database > > MUST include a list of the required > parameter > > names. The Database MAY include only names > of > > parameters that are missing, but MAY include > > a full list. Including the full list of > > missing parameters may reduce the number of > > re-queries from the Device. See MISSING > Error > > for more details. > > -202 INVALID_VALUE A parameter value is invalid in some way. > The > > Database SHOULD include a message indicating > > which parameter and why its value is > invalid. > > -300 (reserved) > > -301 UNAUTHORIZED The Device is not authorized to used the > > Database. Authorization may be determined by > > the ruleset or be dependent on prior > > arrangement between the Device and Database. > > -302 NOT_REGISTERED Device registration required, but the Device > > is not registered. > > -32000 (reserved) Reserved for JSON-RPC error codes. > > to > > -32768 > > > > IANA understands that these three actions are the only ones required > to be > > completed upon approval of this document. > > > > Note: The actions requested in this document will not be completed > until > > the document has been approved for publication as an RFC. This > message is > > only to confirm what actions will be performed. > > > > Thanks, > > > > Pearl Liang > > ICANN > > > > (END IANA LAST CALL COMMENTS) > > > > > > > > On Wed Aug 06 21:09:57 2014, iesg-secretary@ietf.org wrote: > > > > > > The IESG has received a request from the Protocol to Access WS > database > > > WG (paws) to consider the following document: > > > - 'Protocol to Access White-Space (PAWS) Databases' > > > as Proposed Standard > > > > > > A prior Last Call was made for version -12 of this document. > Comments > > > received during that discussion lead to extensive edits to the > document, > > > which could benefit from a second review. > > > > > > The IESG plans to make a decision in the next few weeks, and > solicits > > > final comments on this action. Please send substantive comments to > the > > > ietf@ietf.org mailing lists by 2014-08-20. Exceptionally, comments > may > > be > > > sent to iesg@ietf.org instead. In either case, please retain the > > > beginning of the Subject line to allow automated sorting. > > > > > > Abstract > > > > > > > > > Portions of the radio spectrum that are allocated to licensees > are > > > available for non-interfering use. This available spectrum is > called > > > "White Space." Allowing secondary users access to available > spectrum > > > "unlocks" existing spectrum to maximize its utilization and to > > > provide opportunities for innovation, resulting in greater > overall > > > spectrum utilization. > > > > > > One approach to managing spectrum sharing uses databases to > report > > > spectrum availability to devices. To achieve interoperability > among > > > multiple devices and databases, a standardized protocol must be > > > defined and implemented. This document defines such a > protocol, the > > > "Protocol to Access White Space (PAWS) Databases". > > > > > > > > > > > > > > > The file can be obtained via > > > http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ > > > > > > IESG discussion can be tracked via > > > http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ballot/ > > > > > > > > > The following IPR Declarations may be related to this I-D: > > > > > > http://datatracker.ietf.org/ipr/2203/ > > > http://datatracker.ietf.org/ipr/2340/ > > > http://datatracker.ietf.org/ipr/2239/ > > > > > > > > > > > > > > > > > --------------090608090002060502080403-- From nobody Tue Aug 19 18:56:48 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0861A6F9B for ; Tue, 19 Aug 2014 18:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.668 X-Spam-Level: X-Spam-Status: No, score=-7.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rRi_QPCe1JU for ; Tue, 19 Aug 2014 18:56:35 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3B91A86E9 for ; Tue, 19 Aug 2014 18:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408499796; x=1440035796; h=message-id:date:from:mime-version:to:subject; bh=5OOWqMD+Az/npmzTTl8w8TqV1lUnewOpKMBB+ND5Wr8=; b=Vy7SEydKwN8JKwRdWTZjjhwdMvWEvpX9eRZmp2HCGPcPIrwmn8rIefCP tAdzKH6i9GKs9+j5cwt4u2pu2qm/7yXo+3yQqY5gPM+vU20xijvHRdECB KKnY3lyxGk3sjGD+De+g5ChwN55OnoeDpFVkvBBIzpSBSuXUogbdwUQHp o=; X-IronPort-AV: E=McAfee;i="5600,1067,7535"; a="59185133" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 19 Aug 2014 18:56:36 -0700 X-IronPort-AV: E=Sophos;i="5.01,898,1400050800"; d="eml'208?scan'208,208";a="720167754" Received: from nasanexhc03.na.qualcomm.com ([10.46.56.181]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2014 18:56:34 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC03.na.qualcomm.com (10.46.56.181) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:56:33 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:56:33 -0700 Message-ID: <53F40050.5050708@qti.qualcomm.com> Date: Tue, 19 Aug 2014 20:56:32 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "paws@ietf.org" Content-Type: multipart/mixed; boundary="------------000206000600090906090400" X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/UjnJQgiXG7CQxpjOeJ0VLj16KTg Subject: [paws] Fwd: Re: [IANA #777162] Re: Second Last Call: (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 01:56:45 -0000 --------------000206000600090906090400 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit --------------000206000600090906090400 Content-Type: message/rfc822; name="Re: [IANA #777162] Re: Second Last Call: (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Re: [IANA #777162] Re: Second Last Call: X-Original-To: presnick@dev-presnick.qualcomm.com Delivered-To: presnick@dev-presnick.qualcomm.com Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by dev-presnick.qualcomm.com (Postfix) with ESMTPS id 982C33F899 for ; Tue, 19 Aug 2014 12:16:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,896,1400050800"; d="scan'208";a="787837345" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2014 12:16:40 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 12:16:39 -0700 Resent-From: Received: from Ironmsg03-R.qualcomm.com (172.30.48.1) by nasanexhc05.na.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 12:16:38 -0700 X-IronPort-AV: E=Sophos;i="5.01,896,1400050800"; d="scan'208";a="734360955" X-ojodefuego: yes X-Forgery: (qualnet-external) Received: from gatewaypony02.qualcomm.com ([65.197.215.45]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Aug 2014 12:16:38 -0700 Received-SPF: Pass (gatewaypony02.qualcomm.com: domain of iesg-bounces@ietf.org designates 4.31.198.44 as permitted sender) identity=mailfrom; client-ip=4.31.198.44; receiver=gatewaypony02.qualcomm.com; envelope-from="iesg-bounces@ietf.org"; x-sender="iesg-bounces@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" Authentication-Results: gatewaypony02.qualcomm.com; dkim=pass (signature verified) header.i=@ietf.org X-SLBL-Result: SAFE-LISTED X-IronPort-AV: E=McAfee;i="5600,1067,7535"; a="128100735" X-DMARC-Status: PASS X-IPAS-Result: Ao8BAI2h81MEH8Ysm3poAFmCanZTBASCeK9vmCCBQRgBC4dXgQUIFgEPAQEBAQEGCwsJFCmEAwEBAQEBAQEBAg8IAQgdAQEECh4LAQICAQECBgEBCAILDRYBCQECAwQCAgMBHhIBBQEcGQUDARmIGAkCBQWPaZAna4ozeIUCAQVHjwIRBgqME4JNEQEuOwGCZoFTAYUIAoELhRGDcIUJgTCEHoJZgVeMfIQ+GCmDSIFmTAEBAYEFBxeBKQEBAQ Received: from mail.ietf.org ([4.31.198.44]) by gatewaypony02.qualcomm.com with ESMTP; 19 Aug 2014 12:16:35 -0700 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AAA1A0AD2; Tue, 19 Aug 2014 12:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1408475795; bh=h3VnNdKz3q0WISBO5SgmysxAeZyd4C9PLreeUEKgKag=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type:Cc:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Sender; b=oFq5Plktqr3KB+qakcZ7C6fikJg3ZiD583GMuzyaYg1QGgTn8nVC+RmFLadya8K1P 2WwAa+mSI2Ia49BRmY+DvxSD73rqeyNFCx09IfSYPJ3qCK/7vXjPsYl7BkGmg8xoTF /ZnqG2Z7Y6z8cn550j2p/utHk7IIb51VWm2X94Qg= X-Original-To: iesg@ietfa.amsl.com Delivered-To: iesg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EF81A0AD2 for ; Tue, 19 Aug 2014 12:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm559wmKAAsN for ; Tue, 19 Aug 2014 12:16:26 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552DE1A0686 for ; Tue, 19 Aug 2014 12:16:26 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf12so8040251vcb.12 for ; Tue, 19 Aug 2014 12:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2iykx8g5Y1SCFL3ccIizFHa9w6xVcWZel6dkclLz1EA=; b=Am4Ai8A5tgJsd65Dd0/xcF88MicYFyQR9iM0eVNjctCgDXkkmH2Z3SXeBMWQ9tVRZB XPBu0MiKieOsv3ET23t0E5XvB+LQZlXr8nZENM/7jq0fsV9fhNTHrHvHflpEg5VkxnQp IFnB9p6k1DixmoqpToUlSC4qabozi8ur1/aBzMqGyKBaOQYE8tp/497Gl2LYABRsH6MV ZVyAMyIG4odiXtJS41LDN38dwtNcBsFk+o2NnqxohSpILTHEuas4UoIOpWR3dQuwtAyK 3tebpEaPMhfM8bOgYHA0U3oAg13fO0h1HB6mjc/yIYlOyXRK+jfPLj0hOWmNcY7j+PTe phNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2iykx8g5Y1SCFL3ccIizFHa9w6xVcWZel6dkclLz1EA=; b=HXHEjVSptIaXaY7nu7Is3LPhEOf8AkatHP6Dh6n7Np0NV5QOYZUQJ/k2C+9CPL5OLQ w2Z9rnUDc4+z8YlwUt2ShEnFvgrMzBB5oSWu5K3y7yKisWbk+kT4c/2qUB3Vh5aHFB77 //eqczHsSjAl/oSY8L3F+8LXeqVR/psgdY4OEnMc0CG5eMUNJzgiNsWW3Z8waklXtmE8 b5vYqm39cq5/fViLLvkiHhTMOKYSkDmyOpC33dVwRIrm1nW/Q7cheqAWIcTQeMZzyFrV 1LwMTfu5DK5a9CxDPEbPBW41Cw5khHKymVF8pmC6qSyDBXwdDFSWB5/tmPPrEB2CjsUZ o2tA== X-Gm-Message-State: ALoCoQk0Sb+pBQ/aaT6pAJIReh9/6GqgB8+7rnSqdUaCU9Tzvt4dcOE3NT0RH03vEBF7NGug2byx MIME-Version: 1.0 X-Received: by 10.52.245.101 with SMTP id xn5mr13558030vdc.32.1408475785343; Tue, 19 Aug 2014 12:16:25 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Tue, 19 Aug 2014 12:16:25 -0700 (PDT) In-Reply-To: References: <20140806210932.26762.78438.idtracker@ietfa.amsl.com> Date: Tue, 19 Aug 2014 12:16:25 -0700 Message-ID: Subject: Re: [IANA #777162] Re: Second Last Call: (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard From: Vincent Chen To: Content-Type: multipart/alternative; boundary="089e0160c2eedc579505010052af" Archived-At: http://mailarchive.ietf.org/arch/msg/iesg/LPqmT5RJGGzPYwM_sCr8WXa9WLc CC: "paws-chairs@tools.ietf.org" , , , X-BeenThere: iesg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iesg-bounces@ietf.org Sender: iesg --089e0160c2eedc579505010052af Content-Type: text/plain; charset="UTF-8" Sorry for the confusion. I thought you were suggesting that we create sub-registries and so wanted to confirm whether updated instructions made sense. Clarification: The intent is for Additional Requirements to be documented along with each Ruleset. The tabular presentation is for readability, rather than actual sub-registries. Would the following clarification be acceptable? - IANA will post each registration template - The Additional Requirements column of the new ruleset identifier will contain a reference to the template (similar to http://www.iana.org/assignments/lang-subtags-templates/lang-subtags-templates.xhtml ) -vince On Tue, Aug 19, 2014 at 9:55 AM, Pearl Liang via RT wrote: > Dear authors, > > Please see inline comments/questions marked with [pl]. > > On Fri Aug 15 18:28:18 2014, vchen@google.com wrote: > > Thanks for the review. > > > > > > On Thu, Aug 14, 2014 at 10:27 AM, Pearl Liang via RT < > > drafts-lastcall@iana.org> wrote: > > > > > (BEGIN IANA LAST CALL COMMENTS) > > > > > > IESG/Authors/WG Chairs: > > > > > > IANA has reviewed draft-ietf-paws-protocol-14. Authors should > > review the > > > comments and/or questions below. Please report any inaccuracies and > > > respond to any questions as soon as possible. > > > > > > IANA has a question for one of the requested actions in this draft > > > document. > > > > > > We received the following comments/questions from the IANA's > > reviewer: > > > > > > IANA understands that, upon approval of this document there are > > three > > > actions which IANA must complete. > > > > > > IANA understands that this document proposes the creation of a PAWS > > > protocol registry which will initially consist of three > > subregistries: > > > > > > - the PAWS Ruleset ID Registry > > > - the PAWS Parameter Registry > > > - the PAWS Error Code Registry > > > > > > On the IANA Matrix located at: > > > > > > http://www.iana.org/protocols > > > > > > the new PAWS registry will be linked with a reference of [ RFC-to-be > > ]. > > > > > > In the new PAWS registry there will be three sub-registries as > > follows: > > > > > > First, in the PAWS Registry created above, a new registry called the > > PAWS > > > Ruleset ID Registry will be created. Each entry in the registry has > > a > > > ruleset name, additional parameter requirements and a specification. > > > > > > New entires in this registry are done through Specification Required > > as > > > defined in RFC 5226. > > > > > > There are two initial entries in this new registry as follows: > > > > > > Ruleset identifier: FccTvBandWhiteSpace-2010 > > > Specification: This ruleset refers to the FCC rules for TV-band > > White > > > Space operations established in the Code of Federal Regulations > > (CFR), > > > Title 47, Part 15, Subpart H. > > > Additional Parameter Requirements for FccTvBandWhiteSpace-2010: > > > > > > Available Spectrum Request > > > +---------------+-----------------------------+-------------+------- > > + > > > | Parameter | Type | Requirement | Notes > > | > > > | Name | | | > > | > > > +---------------+-----------------------------+-------------+------- > > + > > > | deviceDesc | DeviceDescriptor | REQUIRED | > > | > > > +---------------+-----------------------------+-------------+------- > > + > > > > > > Available Spectrum Batch Request > > > +---------------+-----------------------------+------------- > > +-------+ > > > | Parameter | Type | Requirement | Notes > > | > > > | Name | | | > > | > > > +---------------+-----------------------------+-------------+------- > > + > > > | deviceDesc | DeviceDescriptor | REQUIRED | > > | > > > +---------------+-----------------------------+-------------+------- > > + > > > > > > DeviceDescriptor Message > > > +-------------------+--------+-------------+------------------------ > > + > > > | Parameter Name | Type | Requirement | Notes > > | > > > +-------------------+--------+-------------+------------------------ > > + > > > | fccId | string | REQUIRED | Specifies a device's > > | > > > | | | | FCC certification ID > > | > > > | fccTvbdDeviceType | string | REQUIRED | Specifies the FCC > > | > > > | | | | Device Type > > | > > > | | | | of > > | > > > | | | | TV-band White Space > > | > > > | | | | device, as defined by > > | > > > | | | | the FCC rules. > > | > > > +-------------------+--------+-------------+------------------------ > > + > > > > > > DeviceOwner Message > > > +-----------+------- > > +-----------------------------------------------+ > > > | Parameter | Type | Additional Requirement > > | > > > | Name | | > > | > > > +-----------+-------+----------------------------------------------- > > + > > > | owner | vCard | The owner is required to contain the > > formatted| > > > | | | name of an individual or organization using > > | > > > | | | the "fn" property. When the name is that of > > an| > > > | | | organization, the entry also is required to > > | > > > | | | contain the "kind" property, with a value of > > | > > > | | | "org". > > | > > > | operator | vCard | The operator entry is required to contain the > > | > > > | | | following properties for the contact person > > | > > > | | | responsible for the device's operation: "fn", > > | > > > | | | "adr", "tel", and "email". > > | > > > +-----------+-------+----------------------------------------------- > > + > > > > > > Ruleset identifier: ETSI-EN-301-598-1.1.1 > > > Specification document(s): This ruleset refers to the ETSI > > > Harmonised Standard [ETSI-EN-301-598] established by ETSI. > > > Additional Parameter Requirements: > > > > > > DeviceDescriptor > > > +-------------------------+-------+-------------+------------------- > > + > > > | Parameter Name | Type | Requirement | Notes > > | > > > +-------------------------+-------+-------------+------------------- > > + > > > | manufacturerId | string| REQUIRED | Specifies a > > | > > > | | | | device's > > | > > > | | | | manufacturer's > > | > > > | | | | identifier. See > > | > > > | | | | [ RFC-to-be ] > > | > > > | | | | Section 5.2. > > | > > > | modelId | string| REQUIRED | Specifies a > > | > > > | | | | device's model > > | > > > | | | | identifier. See > > | > > > | | | | [ RFC-to-be ] > > | > > > | | | | Section 5.2. > > | > > > | etsiEnDeviceType | string| REQUIRED | Specifies the > > | > > > | | | | device's ETSI > > | > > > | | | | device type > > | > > > | | | | (Section > > | > > > | | | | 9.2.2.3). > > | > > > | etsiEnDeviceEmissionsCl | string| REQUIRED | Specifies the > > | > > > | ass | | | device's ETSI > > | > > > | | | | device emissions > > | > > > | | | | class (Section > > | > > > | | | | 9.2.2.4). > > | > > > | etsiEnTechnologyId | string| REQUIRED | Specifies the > > | > > > | | | | device's ETSI > > | > > > | | | | technology ID > > | > > > | | | | (Section > > | > > > | | | | 9.2.2.5). > > | > > > | etsiEnDeviceCategory | string| REQUIRED | Specifies the > > | > > > | | | | device's ETSI > > | > > > | | | | device category > > | > > > | | | | (Section > > | > > > | | | | 9.2.2.6). > > | > > > +-------------------------+-------+-------------+------------------- > > + > > > > > > AVAIL_SPECTRUM_REQ > > > +-------------+--------+-------------+------------------------------ > > + > > > | Parameter | Type | Requirement | Notes > > | > > > | Name | | | > > | > > > +-------------+--------+-------------+------------------------------ > > + > > > | requestType | string | OPTIONAL | Modifies the available- > > | > > > | | | | spectrum request type. If > > | > > > | | | | specified, the only valid > > | > > > | | | | value is, "Generic Slave", > > | > > > | | | | and the Database is required > > | > > > | | | | to respond with generic > > | > > > | | | | operating parameters for any > > | > > > | | | | Slave Device. > > | > > > +-------------+--------+-------------+------------------------------ > > + > > > > > > Available Spectrum Batch Request > > > +-------------+--------+-------------+------------------------------ > > + > > > | Parameter | Type | Requirement | Notes > > | > > > | Name | | | > > | > > > +-------------+--------+-------------+------------------------------ > > + > > > | requestType | string | OPTIONAL | Modifies the available- > > | > > > | | | | spectrum request type. If > > | > > > | | | | specified, the only valid > > | > > > | | | | value is, "Generic Slave", > > | > > > | | | | and the Database is required > > | > > > | | | | to respond with generic > > | > > > | | | | operating parameters for any > > | > > > | | | | Slave Device. > > | > > > +-------------+--------+-------------+------------------------------ > > + > > > > > > DeviceDescriptor for AVAIL_SPECTRUM_RESP and > > AVAIL_SPECTRUM_BATCH_RESP > > > messages > > > +--------------------------------+---------+---------- > > +---------------+ > > > | Parameter Name | Type | Requirem | Notes > > | > > > | | | ent | > > | > > > +--------------------------------+---------+---------- > > +---------------+ > > > | needsSpectrumReport | boolean | REQUIRED | The Database > > | > > > | | | | is required > > | > > > | | | | to set this > > | > > > | | | | to true to > > | > > > | | | | indicate > > that | > > > | | | | the device > > | > > > | | | | must report > > | > > > | | | | spectrum > > | > > > | | | | usage. > > | > > > | maxTotalBwHz | float | REQUIRED | Specifies a > > | > > > | | | | constraint > > on | > > > | | | | total > > allowed | > > > | | | | bandwidth. > > | > > > | maxContiguousBwHz | float | REQUIRED | Specifies a > > | > > > | | | | constraint > > on | > > > | | | | total > > allowed | > > > | | | | contiguous > > | > > > | | | | bandwidth. > > | > > > | etsiEnSimultaneousChannelOpera | string | REQUIRED | Specifies a > > | > > > | tionRestriction | | | constraint > > on | > > > | | | | simultaneous > > | > > > | | | | channel > > | > > > | | | | operation > > | > > > | | | | (Section > > | > > > | | | | 9.2.2.7). If > > | > > > | | | | it is not > > | > > > | | | | provided, > > the | > > > | | | | default > > value | > > > | | | | is "0". > > | > > > +--------------------------------+---------+---------- > > +---------------+ > > > > > > RulesetInfo > > > +-------------------+-------+-------------+------------------------- > > + > > > | Parameter Name | Type | Requirement | Notes > > | > > > +-------------------+-------+-------------+------------------------- > > + > > > | maxLocationChange | float | OPTIONAL | Specifies a constraint > > | > > > | | | | on maximum location > > | > > > | | | | changes. > > | > > > +-------------------+-------+-------------+------------------------- > > + > > > > > > QUESTION/Note: > > > 1) It appears that this document defines multiple tables for > > Additional > > > Parameter > > > Requirements for each Ruleset ID entry in the new requested sub- > > registry > > > "PAWS > > > Ruleset ID Registry" of the new created PAWS protocol registry. How > > do > > > the authors > > > want the registration information presented in the namespace (aka > > website)? > > > You can visit the following registry that shows a list of sub- > > registries > > > for iSCSI > > > Parameters, and more sub-registries under a sub-registry "iSCSI > > Login > > > Response > > > Status Codes": > > > > > > http://www.iana.org/assignments/iscsi-parameters > > > > > > Thanks for the pointer to the example. To use this, I can see > > organizing it > > as follows: > > > > a) Add a sub-registry "Additional Requirements for Ruleset > > Identifier=FccTvBandWhiteSpace-2010", and the multiple tables in the > > draft > > can be collapsed into a single table with an additional "Location" > > column, > > e.g.,: > > > > > +-------------------------------------------------------------------------------------------- > > + > > | Location | Parameter Name | Type | Requirement > > | Notes | > > +-----------------+-----------------+---------------- > > +---------------------+-----------------+ > > |Available |deviceDesc |DeviceDescriptor| REQUIRED > > | | > > |Spectrum | | | > > | | > > |Request | | | > > | | > > | | | | > > | | > > |Available |deviceDesc |DeviceDescriptor| REQUIRED > > | | > > |Spectrum | | | > > | | > > |Batch | | | > > | | > > |Request | | | > > | | > > | | | | > > | | > > |DeviceDescriptor |fccId |string |REQUIRED > > |Specifies a | > > | | | | > > |device's FCC | > > | | | | > > |certification ID | > > | | | | > > | | > > |DeviceDescriptor |fccTvbdDeviceType| | > > | | > > | | | | > > | | > > |DeviceOwner |owner |vCard |The owner is > > required| | > > | | | |to contain the > > | | > > | | | |formatted name > > of an > > | | > > | | | |individual or > > | | > > | | | |organization > > using > > | | > > | | | |the "fn" > > property. > > | | > > | | | |When the name is > > that| | > > | | | |of an > > organization, > > | | > > | | | |the entry also > > is > > | | > > | | | |required to > > contain > > | | > > | | | |contain the > > "kind" > > | | > > | | | |property, with a > > | | > > | | | |value of "org". > > | | > > | | | | > > | | > > |DeviceOwner |operator |vCard |The operator > > entry > > is| | > > | | | |... > > | | > > > +-------------------------------------------------------------------------------------------- > > + > > > > b) Add sub-registry "Additional Requirements for Ruleset > > Identifier=ETSI-EN-301-598-1.1.1" and a single table similar to the > > above. > > > > Questions: > > - Would something like that work? > > - If so, should I update the RFC draft to reflect the above? > > > > Another option is to preserve the text as-is as the "template" and > > refer to > > it via a link, like > > http://www.iana.org/assignments/lang-subtags-templates/lang-subtags- > > templates.xhtml > > > > > > [pl] The authors should decide the format and let IANA know the consensus. > You should document all IANA actions in the IC section. If you were > suggested > otherwise, please let us know. > > You are suggesting to create new sub-registries for Additional Parameter > Requirements. > Are you suggesting separate Additional Parameter Requirements > sub-registries > for each Ruleset ID, i.e. FccTvBandWhiteSpace-2010, ETSI-EN-301-598-1.1.1, > and > later new Ruleset IDs in future drafts? > > How can a new request for a new PAWS Ruleset ID update the new PAWS > Ruleset ID registry > and sub-registry Additional Parameter Requirements? keep creating > separate table > for Additional Parameter Requirements? > > > > > > > > > > 2) We understand that "Specification document(s)" is the column for > > > Reference. > > > > > > > Yes. Agreed. > > > > [pl] Should the same registration procedure apply to all new created > Additional Parameter Requirements sub-registries, if you choose to use that? > > > > > > > > > Second, in the PAWS Registry created above, a new registry called > > the PAWS > > > Parameter Registry will be created. Each entry in the registry has > > a > > > parameter name, parameter usage location and a specification. > > > > > > > > > New entires in this registry are done through Specification Required > > as > > > defined in RFC 5226. > > > > > > There are seven initial entries in this new registry as follows: > > > > > > Parameter name: fccId > > > Parameter usage location: DeviceDescriptor > > > Specification document(s): [ RFC-to-be ] > > > > > > Parameter name: fccTvbdDeviceType > > > Parameter usage location: DeviceDescriptor > > > Specification document(s): [ RFC-to-be ] > > > > > > Parameter name: etsiEnDeviceType > > > Parameter usage location: DeviceDescriptor > > > Specification document(s): Specifies the White Space Device type, > > as > > > defined by the ETSI Harmonized Standard - [ > > > > > > http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf > > > ] > > > > > > Parameter name: etsiEnDeviceEmissionsClass > > > Parameter usage location: DeviceDescriptor > > > Specification document(s): Specifies the White Space Device > > emissions > > > class, as defined by the ETSI Harmonized Standard - [ > > > > > > http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf > > > ] > > > > > > Parameter name: etsiEnTechnologyId > > > Parameter usage location: DeviceDescriptor > > > Specification document(s): Specifies the White Space Device > > technology > > > identifier, as defined by the ETSI Harmonized Standard - [ > > > > > > http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf > > > ] > > > > > > Parameter name: etsiEnDeviceCategory > > > Parameter usage location: DeviceDescriptor > > > Specification document(s): Specifies the White Space Device > > category, as > > > defined by the ETSI Harmonized Standard - [ > > > > > > http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf > > > ] > > > > > > Parameter name: etsiEnSimultaneousChannelOperationRestriction > > > Parameter usage location: SpectrumSpec > > > Specification document(s): Specifies the constraint on the device > > maximum > > > total EIRP, as defined by the ETSI Harmonized Standard - [ > > > > > > http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf > > > ] > > > > > > Third, in the PAWS Registry created above, a new registry called the > > PAWS > > > Error Code Registry will be created. Each entry in the registry has > > an > > > error code, name, description, additional parameters and reference > > > > > > New entries in this registry are done through Specification Required > > as > > > defined in RFC 5226. > > > > > > There are new entries in this subregistry, all with a reference of [ > > > RFC-to-be ], as follows: > > > > > > Code Name Description & Additional parameters > > > ------ ---------------- > > --------------------------------------------- > > > 32767 to 1 Unassigned > > > 0 (reserved) > > > -100 (reserved) > > > -101 VERSION The Database does not support the specified > > > version of the message. > > > -102 UNSUPPORTED The Database does not support the Device. > > For > > > example, it does not support the ruleset > > > specified in the request. > > > -103 UNIMPLEMENTED The Database does not implement the optional > > > request or optional feature. > > > -104 OUTSIDE_COVERAGE The specified geo-location is outside the > > > coverage area of the Database. The Database > > > MAY include a DbUpdateSpec > > > parameter to provide a list of alternate > > > databases that might be appropriate for the > > > requested location. See OUTSIDE_COVERAGE > > > Error for more details. > > > -105 DATABASE_CHANGE The Database has changed its URI. The > > > Database MAY include a DbUpdateSpec > > > parameter in the error response > > > to provide devices with one or more > > alternate > > > database URIs. The Device needs to use the > > > information to update its list of > > > preconfigured databases to replace (only) > > its > > > entry for the responding Database with the > > > list of alternate database URIs. See > > > DATABASE_CHANGE Error for > > > more details. > > > -200 (reserved) > > > -201 MISSING A required parameter is missing. The > > Database > > > MUST include a list of the required > > parameter > > > names. The Database MAY include only names > > of > > > parameters that are missing, but MAY include > > > a full list. Including the full list of > > > missing parameters may reduce the number of > > > re-queries from the Device. See MISSING > > Error > > > for more details. > > > -202 INVALID_VALUE A parameter value is invalid in some way. > > The > > > Database SHOULD include a message indicating > > > which parameter and why its value is > > invalid. > > > -300 (reserved) > > > -301 UNAUTHORIZED The Device is not authorized to used the > > > Database. Authorization may be determined by > > > the ruleset or be dependent on prior > > > arrangement between the Device and Database. > > > -302 NOT_REGISTERED Device registration required, but the Device > > > is not registered. > > > -32000 (reserved) Reserved for JSON-RPC error codes. > > > to > > > -32768 > > > > > > IANA understands that these three actions are the only ones required > > to be > > > completed upon approval of this document. > > > > > > Note: The actions requested in this document will not be completed > > until > > > the document has been approved for publication as an RFC. This > > message is > > > only to confirm what actions will be performed. > > > > > > Thanks, > > > > > > Pearl Liang > > > ICANN > > > > > > (END IANA LAST CALL COMMENTS) > > > > > > > > > > > > On Wed Aug 06 21:09:57 2014, iesg-secretary@ietf.org wrote: > > > > > > > > The IESG has received a request from the Protocol to Access WS > > database > > > > WG (paws) to consider the following document: > > > > - 'Protocol to Access White-Space (PAWS) Databases' > > > > as Proposed Standard > > > > > > > > A prior Last Call was made for version -12 of this document. > > Comments > > > > received during that discussion lead to extensive edits to the > > document, > > > > which could benefit from a second review. > > > > > > > > The IESG plans to make a decision in the next few weeks, and > > solicits > > > > final comments on this action. Please send substantive comments to > > the > > > > ietf@ietf.org mailing lists by 2014-08-20. Exceptionally, comments > > may > > > be > > > > sent to iesg@ietf.org instead. In either case, please retain the > > > > beginning of the Subject line to allow automated sorting. > > > > > > > > Abstract > > > > > > > > > > > > Portions of the radio spectrum that are allocated to licensees > > are > > > > available for non-interfering use. This available spectrum is > > called > > > > "White Space." Allowing secondary users access to available > > spectrum > > > > "unlocks" existing spectrum to maximize its utilization and to > > > > provide opportunities for innovation, resulting in greater > > overall > > > > spectrum utilization. > > > > > > > > One approach to managing spectrum sharing uses databases to > > report > > > > spectrum availability to devices. To achieve interoperability > > among > > > > multiple devices and databases, a standardized protocol must be > > > > defined and implemented. This document defines such a > > protocol, the > > > > "Protocol to Access White Space (PAWS) Databases". > > > > > > > > > > > > > > > > > > > > The file can be obtained via > > > > http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ > > > > > > > > IESG discussion can be tracked via > > > > http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ballot/ > > > > > > > > > > > > The following IPR Declarations may be related to this I-D: > > > > > > > > http://datatracker.ietf.org/ipr/2203/ > > > > http://datatracker.ietf.org/ipr/2340/ > > > > http://datatracker.ietf.org/ipr/2239/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- -vince --089e0160c2eedc579505010052af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the confusion.

I thought you = were suggesting that we create sub-registries and so wanted to confirm whet= her updated instructions made sense.

Clarification= :

The intent is for Additional Requirements to be documen= ted along with each Ruleset.
The tabular presentation is for read= ability, rather than actual sub-registries.

Would the following clarification be acceptable?

= =C2=A0- IANA will post each registration template
=C2=A0- The Add= itional Requirements column of the new ruleset identifier will contain a re= ference to the template



On Tue, Aug 19, 2014 at 9:55 AM, Pearl Liang via RT <iana-issues@iana.org> wrote:
Dear authors,

Please see inline comments/questions marked with [pl].

On Fri Aug 15 18:28:18 2014, vchen@goog= le.com wrote:
> Thanks for the review.
>
>
> On Thu, Aug 14, 2014 at 10:27 AM, Pearl Liang via RT <
> drafts-lastcall@iana.org> wrote:
>
> > (BEGIN IANA LAST CALL COMMENTS)
> >
> > IESG/Authors/WG Chairs:
> >
> > IANA has reviewed draft-ietf-paws-protocol-14.=C2=A0 Authors shou= ld
> review the
> > comments and/or questions below.=C2=A0 Please report any inaccura= cies and
> > respond to any questions as soon as possible.
> >
> > IANA has a question for one of the requested actions in this draf= t
> > document.
> >
> > We received the following comments/questions from the IANA's<= br> > reviewer:
> >
> > IANA understands that, upon approval of this document there are > three
> > actions which IANA must complete.
> >
> > IANA understands that this document proposes the creation of a PA= WS
> > protocol registry which will initially consist of three
> subregistries:
> >
> > - the PAWS Ruleset ID Registry
> > - the PAWS Parameter Registry
> > - the PAWS Error Code Registry
> >
> > On the IANA Matrix located at:
> >
> > http:= //www.iana.org/protocols
> >
> > the new PAWS registry will be linked with a reference of [ RFC-to= -be
> ].
> >
> > In the new PAWS registry there will be three sub-registries as > follows:
> >
> > First, in the PAWS Registry created above, a new registry called = the
> PAWS
> > Ruleset ID Registry will be created.=C2=A0 Each entry in the regi= stry has
> a
> > ruleset name, additional parameter requirements and a specificati= on.
> >
> > New entires in this registry are done through Specification Requi= red
> as
> > defined in RFC 5226.
> >
> > There are two initial entries in this new registry as follows: > >
> > Ruleset identifier:=C2=A0 FccTvBandWhiteSpace-2010
> > Specification:=C2=A0 This ruleset refers to the FCC rules for TV-= band
> White
> > Space operations established in the Code of Federal Regulations > (CFR),
> > Title 47, Part 15, Subpart H.
> > Additional Parameter Requirements for FccTvBandWhiteSpace-2010: > >
> > Available Spectrum Request
> > +---------------+-----------------------------+-------------+----= ---
> +
> > | Parameter=C2=A0 =C2=A0 =C2=A0| Type=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Requirement | Not= es
> |
> > | Name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |
> > +---------------+-----------------------------+-------------+----= ---
> +
> > | deviceDesc=C2=A0 =C2=A0 | DeviceDescriptor=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | REQUIRED=C2=A0 =C2=A0 |
> |
> > +---------------+-----------------------------+-------------+----= ---
> +
> >
> > Available Spectrum Batch Request
> >=C2=A0 +---------------+-----------------------------+------------= -
> +-------+
> > | Parameter=C2=A0 =C2=A0 =C2=A0| Type=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Requirement | Not= es
> |
> > | Name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |
> > +---------------+-----------------------------+-------------+----= ---
> +
> > | deviceDesc=C2=A0 =C2=A0 | DeviceDescriptor=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | REQUIRED=C2=A0 =C2=A0 |
> |
> > +---------------+-----------------------------+-------------+----= ---
> +
> >
> > DeviceDescriptor Message
> > +-------------------+--------+-------------+---------------------= ---
> +
> > | Parameter Name=C2=A0 =C2=A0 | Type=C2=A0 =C2=A0| Requirement | = Notes
> |
> > +-------------------+--------+-------------+---------------------= ---
> +
> > | fccId=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| string |= REQUIRED=C2=A0 =C2=A0 | Specifies a device's
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| FCC certification ID
> |
> > | fccTvbdDeviceType | string | REQUIRED=C2=A0 =C2=A0 | Specifies = the FCC
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Device Type
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| of
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| TV-band White Space
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| device, as defined by
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| the FCC rules.
> |
> > +-------------------+--------+-------------+---------------------= ---
> +
> >
> > DeviceOwner Message
> >=C2=A0 +-----------+-------
> +-----------------------------------------------+
> > | Parameter | Type=C2=A0 | Additional Requirement
> |
> > | Name=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |
> > +-----------+-------+--------------------------------------------= ---
> +
> > | owner=C2=A0 =C2=A0 =C2=A0| vCard | The owner is required to con= tain the
> formatted|
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0| name of an individual or organization using
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0| the "fn" property. When the name is that of
> an|
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0| organization, the entry also is required to
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0| contain the "kind" property, with a value of
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0| "org".
> |
> > | operator=C2=A0 | vCard | The operator entry is required to cont= ain the
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0| following properties for the contact person
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0| responsible for the device's operation: "fn",
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0| "adr", "tel", and "email".
> |
> > +-----------+-------+--------------------------------------------= ---
> +
> >
> > Ruleset identifier:=C2=A0 ETSI-EN-301-598-1.1.1
> > Specification document(s):=C2=A0 This ruleset refers to the ETSI<= br> > >=C2=A0 =C2=A0 =C2=A0 Harmonised Standard [ETSI-EN-301-598] establi= shed by ETSI.
> > Additional Parameter Requirements:
> >
> > DeviceDescriptor
> > +-------------------------+-------+-------------+----------------= ---
> +
> > | Parameter Name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Type=C2=A0 |= Requirement | Notes
> |
> > +-------------------------+-------+-------------+----= ---------------
> +
> > | manufacturerId=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | string| REQU= IRED=C2=A0 =C2=A0 | Specifies a
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| device's
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| manufacturer's
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| identifier. See
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [ RFC-to-be ]
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Section 5.2.
> |
> > | modelId=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| string| REQUIRED=C2=A0 =C2=A0 | Specifies a
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| device's model
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| identifier. See
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [ RFC-to-be ]
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Section 5.2.
> |
> > | etsiEnDeviceType=C2=A0 =C2=A0 =C2=A0 =C2=A0 | string| REQUIRED= =C2=A0 =C2=A0 | Specifies the
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| device's ETSI
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| device type
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| (Section
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 9.2.2.3).
> |
> > | etsiEnDeviceEmissionsCl | string| REQUIRED=C2=A0 =C2=A0 | Speci= fies the
> |
> > | ass=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| device's ETSI
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| device emissions
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| class (Section
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 9.2.2.4).
> |
> > | etsiEnTechnologyId=C2=A0 =C2=A0 =C2=A0 | string| REQUIRED=C2=A0= =C2=A0 | Specifies the
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| device's ETSI
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| technology ID
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| (Section
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 9.2.2.5).
> |
> > | etsiEnDeviceCategory=C2=A0 =C2=A0 | string| REQUIRED=C2=A0 =C2= =A0 | Specifies the
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| device's ETSI
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| device category
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| (Section
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 9.2.2.6).
> |
> > +-------------------------+-------+-------------+----------------= ---
> +
> >
> > AVAIL_SPECTRUM_REQ
> > +-------------+--------+-------------+---------------------------= ---
> +
> > | Parameter=C2=A0 =C2=A0| Type=C2=A0 = =C2=A0| Requirement | Notes
> |
> > | Name=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |
> > +-------------+--------+-------------+---------------------= ---------
> +
> > | requestType | string | OPTIONAL=C2=A0 =C2=A0 | Modifies the ava= ilable-
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| spectrum r= equest type. If
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| specified,= the only valid
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| value is, = "Generic Slave",
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| and the Da= tabase is required
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| to respond= with generic
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| operating = parameters for any
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Slave Devi= ce.
> |
> > +-------------+--------+-------------+---------------------------= ---
> +
> >
> > Available Spectrum Batch Request
> > +-------------+--------+-------------+---------------------------= ---
> +
> > | Parameter=C2=A0 =C2=A0| Type=C2=A0 =C2=A0= | Requirement | Notes
> |
> > | Name=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |
> > +-------------+--------+-------------+---------------------= ---------
> +
> > | requestType | string | OPTIONAL=C2=A0 =C2=A0 | Modifies the ava= ilable-
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| spectrum r= equest type. If
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| specified,= the only valid
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| value is, = "Generic Slave",
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| and the Da= tabase is required
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| to respond= with generic
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| operating = parameters for any
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Slave Devi= ce.
> |
> > +-------------+--------+-------------+---------------------------= ---
> +
> >
> > DeviceDescriptor for AVAIL_SPECTRUM_= RESP and
> AVAIL_SPECTRUM_BATCH_RESP
> > messages
> > +--------------------------------+---------+----------
> +---------------+
> > | Parameter Name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| Type=C2=A0 =C2=A0 | Requirem | Notes
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| ent=C2=A0 =C2=A0 =C2=A0 |
> |
> > +--------------------------------+---------+----------
> +---------------+
> > | needsSpectrumReport=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = boolean | REQUIRED | The Database
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | is required
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | to set this
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | to true to
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | indicate
> that |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | the device
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | must report
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | spectrum
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | usage.
> |
> > | maxTotalBwHz=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| float=C2=A0 =C2=A0| REQUIRED | Specifies a
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | constraint
> on |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | total
> allowed |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | bandwidth.
> |
> > | maxContiguousBwHz=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | float=C2=A0 =C2=A0| REQUIRED | Specifies a
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | constraint
> on |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | total
> allowed |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | contiguous
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | bandwidth.
> |
> > | etsiEnSimultaneousChannelOpera | string=C2=A0 | REQUIRED | Spec= ifies a
> |
> > | tionRestriction=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | constraint
> on |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | simultaneous
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | channel
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | operation
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | (Section
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 9.2.2.7). If
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | it is not
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | provided,
> the |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | default
> value |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | is "0".
> |
> > +--------------------------------+---------+----------
> +---------------+
> >
> > RulesetInfo
> > +-------------------+-------+-------------+----------------------= ---
> +
> > | Parameter Name=C2=A0 =C2=A0 | Type= =C2=A0 | Requirement | Notes
> |
> > +-------------------+-------+-------------+----------------= ---------
> +
> > | maxLocationChange | float | OPTIONAL=C2=A0 =C2=A0 | Specifies a= constraint
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| on maximum location
> |
> > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| changes.
> |
> > +-------------------+-------+-------------+----------------------= ---
> +
> >
> > QUESTION/Note:
> > 1) It appears that this document defines multiple tables for
> Additional
> > Parameter
> > Requirements for each Ruleset ID entry in the new requested sub-<= br> > registry
> > "PAWS
> > Ruleset ID Registry" of the new created PAWS protocol regist= ry.=C2=A0 How
> do
> > the authors
> > want the registration information presented in the namespace (aka=
> website)?
> > You can visit the following registry that shows a list of sub- > registries
> > for iSCSI
> > Parameters, and more sub-registries under a sub-registry "iS= CSI
> Login
> > Response
> > Status Codes":
> >
> > http://www.iana.org/assignments/iscsi-parameters
>
>
> Thanks for the pointer to the example. To use this, I can see
> organizing it
> as follows:
>
>=C2=A0 =C2=A0a) Add a sub-registry "Additional Requirements for Ru= leset
> Identifier=3DFccTvBandWhiteSpace-2010", and the multiple tables i= n the
> draft
> can be collapsed into a single table with an additional "Location= "
> column,
> e.g.,:
>
> +---------------------------------------------------------------------= -----------------------
> +
> | Location=C2=A0 =C2=A0 =C2=A0 =C2=A0 | Parameter Name=C2=A0 | Type=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Requirement
> | Notes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> +-----------------+-----------------+----------------
> +---------------------+-----------------+
> |Available=C2=A0 =C2=A0 =C2=A0 =C2=A0 |deviceDesc=C2=A0 =C2=A0 =C2=A0 = =C2=A0|DeviceDescriptor| REQUIRED
>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
> |Spectrum=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |Request=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |Available=C2=A0 =C2=A0 =C2=A0 =C2=A0 |deviceDesc=C2=A0 =C2=A0 =C2=A0 = =C2=A0|DeviceDescriptor| REQUIRED
>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
> |Spectrum=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |Batch=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |Request=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |DeviceDescriptor |fccId=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |str= ing=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |REQUIRED
> |Specifies a=C2=A0 =C2=A0 =C2=A0 |
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> |device's=C2=A0 FCC=C2=A0 =C2=A0 |
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> |certification ID |
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |DeviceDescriptor |fccTvbdDeviceType|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |DeviceOwner=C2=A0 =C2=A0 =C2=A0 |owner=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |vCard=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|The owner is
> required|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |to contain the
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |formatted name
> of an
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |individual or
>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |organization
> using
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |the "fn"
> property.
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |When the name is
> that|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| > |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |of an
> organization,
>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |the entry also
> is
>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |required to
> contain
>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |contain the
> "kind"
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |property, with a
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |value of "org".
>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |DeviceOwner=C2=A0 =C2=A0 =C2=A0 |operator=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|vCard=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|The operator
> entry
> is|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |...
>=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
> +---------------------------------------------------------------------= -----------------------
> +
>
>=C2=A0 b) Add sub-registry "Additional Requirements for Ruleset > Identifier=3DETSI-EN-301-598-1.1.1" and a single table similar to= the
> above.
>
> Questions:
>=C2=A0 - Would something like that work?
>=C2=A0 - If so, should I update the RFC draft to reflect the above?
>
> Another option is to preserve the text as-is as the "template&quo= t; and
> refer to
> it via a link, like
> http://www.iana.org/assignments/lang-subtags-t= emplates/lang-subtags-
> templates.xhtml
>
>

[pl] The authors should decide the format and let IANA know the= consensus.
You should document all IANA actions in the IC section.=C2=A0 If you were s= uggested
otherwise, please let us know.

You are suggesting to create new sub-registries for Additional Parameter Re= quirements.
Are you suggesting separate Additional Parameter Requirements sub-registrie= s
for each Ruleset ID, i.e. FccTvBandWhiteSpace-2010, ETSI-EN-301-598-1.1.1, = and
later new Ruleset IDs in future drafts?

How can a new request for a new PAWS Ruleset ID update the new PAWS Ruleset= ID registry
and sub-registry Additional Parameter Requirements?=C2=A0 keep creating sep= arate table
for Additional Parameter Requirements?


>
> >
> > 2) We understand that "Specification document(s)" is th= e column for
> > Reference.
> >
>
> Yes. Agreed.
>

[pl] Should the same registration procedure apply to all new created = Additional Parameter Requirements sub-registries, if you choose to use that= ?

>
> >
> > Second, in the PAWS Registry created above, a new registry called=
> the PAWS
> > Parameter Registry will be created.=C2=A0 Each entry in the regis= try has
> a
> > parameter name, parameter usage location and a specification.
> >
> >
> > New entires in this registry are done through Specification Requi= red
> as
> > defined in RFC 5226.
> >
> > There are seven initial entries in this new registry as follows:<= br> > >
> > Parameter name:=C2=A0 fccId
> > Parameter usage location:=C2=A0 DeviceDescriptor
> > Specification document(s):=C2=A0 [ RFC-to-be ]
> >
> > Parameter name:=C2=A0 fccTvbdDeviceType
> > Parameter usage location:=C2=A0 DeviceDescriptor
> > Specification document(s):=C2=A0 [ RFC-to-be ]
> >
> > Parameter name:=C2=A0 etsiEnDeviceType
> > Parameter usage location:=C2=A0 DeviceDescriptor
> > Specification document(s):=C2=A0 Specifies the White Space Device= type,
> as
> > defined by the ETSI Harmonized Standard - [
> >
> http://www.etsi.org/deli= ver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf
> > ]
> >
> > Parameter name:=C2=A0 etsiEnDeviceEmissionsClass
> > Parameter usage location:=C2=A0 DeviceDescriptor
> > Specification document(s):=C2=A0 Specifies the White Space Device=
> emissions
> > class, as defined by the ETSI Harmonized Standard - [
> >
> http://www.etsi.org/deli= ver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf
> > ]
> >
> > Parameter name:=C2=A0 etsiEnTechnologyId
> > Parameter usage location:=C2=A0 DeviceDescriptor
> > Specification document(s):=C2=A0 Specifies the White Space Device=
> technology
> > identifier, as defined by the ETSI Harmonized Standard - [
> >
> http://www.etsi.org/deli= ver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf
> > ]
> >
> > Parameter name:=C2=A0 etsiEnDeviceCategory
> > Parameter usage location:=C2=A0 DeviceDescriptor
> > Specification document(s):=C2=A0 Specifies the White Space Device=
> category, as
> > defined by the ETSI Harmonized Standard - [
> >
> http://www.etsi.org/deli= ver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf
> > ]
> >
> > Parameter name:=C2=A0 etsiEnSimultaneousChannelOperationRestricti= on
> > Parameter usage location:=C2=A0 SpectrumSpec
> > Specification document(s):=C2=A0 Specifies the constraint on the = device
> maximum
> > total EIRP, as defined by the ETSI Harmonized Standard - [
> >
> http://www.etsi.org/deli= ver/etsi_en/301500_301599/301598/01.01.01_60/en_301598v010101p.pdf
> > ]
> >
> > Third, in the PAWS Registry created above, a new registry called = the
> PAWS
> > Error Code Registry will be created.=C2=A0 Each entry in the regi= stry has
> an
> > error code, name, description, additional parameters and referenc= e
> >
> > New entries in this registry are done through Specification Requi= red
> as
> > defined in RFC 5226.
> >
> > There are new entries in this subregistry, all with a reference o= f [
> > RFC-to-be ], as follows:
> >
> > Code=C2=A0 =C2=A0Name=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Description & Additional parameters
> > ------ ----------------
> ---------------------------------------------
> > 32767 to 1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Unassigned > > 0=C2=A0 =C2=A0 =C2=A0 (reserved)
> > -100=C2=A0 =C2=A0(reserved)
> > -101=C2=A0 =C2=A0VERSION=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The Da= tabase does not support the specified
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0version of the message.
> > -102=C2=A0 =C2=A0UNSUPPORTED=C2=A0 =C2=A0 =C2=A0 The Database doe= s not support the Device.
> For
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0example, it does not support the ruleset
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0specified in the request.
> > -103=C2=A0 =C2=A0UNIMPLEMENTED=C2=A0 =C2=A0 The Database does not= implement the optional
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0request or optional feature.
> > -104=C2=A0 =C2=A0OUTSIDE_COVERAGE The specified geo-location is o= utside the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0coverage area of the Database. The Database
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0MAY include a DbUpdateSpec
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0parameter to provide a list of alternate
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0databases that might be appropriate for the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0requested location. See OUTSIDE_COVERAGE
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Error for more details.
> > -105=C2=A0 =C2=A0DATABASE_CHANGE=C2=A0 The Database has changed i= ts URI. The
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Database MAY include a DbUpdateSpec
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0parameter in the error response
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0to provide devices with one or more
> alternate
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0database URIs. The Device needs to use the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0information to update its list of
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0preconfigured databases to replace (only)
> its
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0entry for the responding Database with the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0list of alternate database URIs. See
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0DATABASE_CHANGE Error for
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0more details.
> > -200=C2=A0 =C2=A0(reserved)
> > -201=C2=A0 =C2=A0MISSING=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A requ= ired parameter is missing. The
> Database
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0MUST include a list of the required
> parameter
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0names. The Database MAY include only names
> of
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0parameters that are missing, but MAY include
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0a full list. Including the full list of
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0missing parameters may reduce the number of
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0re-queries from the Device. See MISSING
> Error
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0for more details.
> > -202=C2=A0 =C2=A0INVALID_VALUE=C2=A0 =C2=A0 A parameter value is = invalid in some way.
> The
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Database SHOULD include a message indicating
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0which parameter and why its value is
> invalid.
> > -300=C2=A0 =C2=A0(reserved)
> > -301=C2=A0 =C2=A0UNAUTHORIZED=C2=A0 =C2=A0 =C2=A0The Device is no= t authorized to used the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Database. Authorization may be determined by
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0the ruleset or be dependent on prior
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0arrangement between the Device and Database.
> > -302=C2=A0 =C2=A0NOT_REGISTERED=C2=A0 =C2=A0Device registration r= equired, but the Device
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0is not registered.
> > -32000 (reserved)=C2=A0 =C2=A0 =C2=A0 =C2=A0Reserved for JSON-RPC= error codes.
> > to
> > -32768
> >
> > IANA understands that these three actions are the only ones requi= red
> to be
> > completed upon approval of this document.
> >
> > Note:=C2=A0 The actions requested in this document will not be co= mpleted
> until
> > the document has been approved for publication as an RFC. This > message is
> > only to confirm what actions will be performed.
> >
> > Thanks,
> >
> > Pearl Liang
> > ICANN
> >
> > (END IANA LAST CALL COMMENTS)
> >
> >
> >
> > On Wed Aug 06 21:09:57 2014, iesg-secretary@ietf.org wrote:
> > >
> > > The IESG has received a request from the Protocol to Access = WS
> database
> > > WG (paws) to consider the following document:
> > > - 'Protocol to Access White-Space (PAWS) Databases'<= br> > > >=C2=A0 =C2=A0<draft-ietf-paws-protocol-14.txt> as Propo= sed Standard
> > >
> > > A prior Last Call was made for version -12 of this document.=
> Comments
> > > received during that discussion lead to extensive edits to t= he
> document,
> > > which could benefit from a second review.
> > >
> > > The IESG plans to make a decision in the next few weeks, and=
> solicits
> > > final comments on this action. Please send substantive comme= nts to
> the
> > > ietf@ietf.org mailing l= ists by 2014-08-20. Exceptionally, comments
> may
> > be
> > > sent to iesg@ietf.org i= nstead. In either case, please retain the
> > > beginning of the Subject line to allow automated sorting. > > >
> > > Abstract
> > >
> > >
> > >=C2=A0 =C2=A0 Portions of the radio spectrum that are allocat= ed to licensees
> are
> > >=C2=A0 =C2=A0 available for non-interfering use.=C2=A0 This a= vailable spectrum is
> called
> > >=C2=A0 =C2=A0 "White Space."=C2=A0 Allowing seconda= ry users access to available
> spectrum
> > >=C2=A0 =C2=A0 "unlocks" existing spectrum to maximi= ze its utilization and to
> > >=C2=A0 =C2=A0 provide opportunities for innovation, resulting= in greater
> overall
> > >=C2=A0 =C2=A0 spectrum utilization.
> > >
> > >=C2=A0 =C2=A0 One approach to managing spectrum sharing uses = databases to
> report
> > >=C2=A0 =C2=A0 spectrum availability to devices.=C2=A0 To achi= eve interoperability
> among
> > >=C2=A0 =C2=A0 multiple devices and databases, a standardized = protocol must be
> > >=C2=A0 =C2=A0 defined and implemented.=C2=A0 This document de= fines such a
> protocol, the
> > >=C2=A0 =C2=A0 "Protocol to Access White Space (PAWS) Dat= abases".
> > >
> > >
> > >
> > >
> > > The file can be obtained via
> > > http://datatracker.ietf.org/doc/draft-ietf-paws= -protocol/
> > >
> > > IESG discussion can be tracked via
> > > http://datatracker.ietf.org/doc/draft-ie= tf-paws-protocol/ballot/
> > >
> > >
> > > The following IPR Declarations may be related to this I-D: > > >
> > >=C2=A0 =C2=A0 http://datatracker.ietf.org/ipr/2203/
> > >=C2=A0 =C2=A0 http://datatracker.ietf.org/ipr/2340/
> > >=C2=A0 =C2=A0 http://datatracker.ietf.org/ipr/2239/
> > >
> > >
> > >
> >
> >
> >
>
>





--
= -vince
--089e0160c2eedc579505010052af-- --------------000206000600090906090400-- From nobody Tue Aug 19 18:56:56 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68431A86E9 for ; Tue, 19 Aug 2014 18:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.669 X-Spam-Level: X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPF73bNmvch6 for ; Tue, 19 Aug 2014 18:56:45 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1661A6F9B for ; Tue, 19 Aug 2014 18:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408499805; x=1440035805; h=message-id:date:from:mime-version:to:subject; bh=2ne4fdtaq7eCVpjyJXsv63XuPxgEpY3KAkDCOAaB5Oo=; b=fH5D+vsYw0F3wGwQTjUK8e563DATQAvaZTxEoegYDVaj0R41CePhIPyj HVTIUldMWLmy+zmtCIBnMdBc5KITzsd+hqr3AM+DKBjJGzsch5vPekkGh zxgxolkTMrTGuGmc6Px99ZhXxAGMMuAZk5IY1+03o3F5vC33xf3WunANj Q=; X-IronPort-AV: E=McAfee;i="5600,1067,7535"; a="150689958" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine02.qualcomm.com with ESMTP; 19 Aug 2014 18:56:45 -0700 X-IronPort-AV: E=Sophos;i="5.01,898,1400050800"; d="eml'208?scan'208,208";a="30399372" Received: from nasanexhc01.na.qualcomm.com ([10.46.57.53]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2014 18:56:45 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC01.na.qualcomm.com (10.46.57.53) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:56:44 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:56:44 -0700 Message-ID: <53F4005B.3060800@qti.qualcomm.com> Date: Tue, 19 Aug 2014 20:56:43 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "paws@ietf.org" Content-Type: multipart/mixed; boundary="------------040802020708070400040605" X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/0e3Aq5-08t_qQM2tezAS-rzbRlE Subject: [paws] Fwd: Stephen Farrell's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 01:56:47 -0000 --------------040802020708070400040605 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit --------------040802020708070400040605 Content-Type: message/rfc822; name="Stephen Farrell's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT).eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Stephen Farrell's Discuss on draft-ietf-paws-protocol-14: (w"; filename*1="ith DISCUSS and COMMENT).eml" Return-Path: X-Original-To: presnick@dev-presnick.qualcomm.com Delivered-To: presnick@dev-presnick.qualcomm.com Received: from Ironmsg03-R.qualcomm.com (ironmsg03-R.qualcomm.com [172.30.46.17]) by dev-presnick.qualcomm.com (Postfix) with ESMTPS id 094F43F883 for ; Tue, 19 Aug 2014 18:42:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,898,1400050800"; d="scan'208";a="734542704" Received: from nasanexhc15.na.qualcomm.com ([129.46.52.215]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Aug 2014 18:42:52 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc15.na.qualcomm.com (129.46.52.215) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:42:51 -0700 Resent-From: Received: from Ironmsg04-R.qualcomm.com (172.30.48.1) by nasanexhc05.na.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 19 Aug 2014 18:42:50 -0700 X-IronPort-AV: E=Sophos;i="5.01,898,1400050800"; d="scan'208";a="788061329" X-ojodefuego: yes X-Forgery: (qualnet-external) Received: from gatewayhorse2.qualcomm.com ([199.106.114.132]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Aug 2014 18:42:50 -0700 Received-SPF: Pass (gatewayhorse2.qualcomm.com: domain of iesg-bounces@ietf.org designates 4.31.198.44 as permitted sender) identity=mailfrom; client-ip=4.31.198.44; receiver=gatewayhorse2.qualcomm.com; envelope-from="iesg-bounces@ietf.org"; x-sender="iesg-bounces@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" Authentication-Results: gatewayhorse2.qualcomm.com; dkim=pass (signature verified) header.i=@ietf.org X-SLBL-Result: SAFE-LISTED X-IronPort-AV: E=McAfee;i="5600,1067,7535"; a="233218445" X-DMARC-Status: PASS X-IPAS-Result: Ak8LAFj881MEH8Ysm3poAFqCanZXgnyIU8EEHAqHWYEMFgEPAQEBAQEGCwsJFCmEBwQCIB0BAQQKDg4NAQIDAQIGAiQCIgQCAgMBQxYYBIg6AgqrbniFAgEFgXyONBEGgSyNPg4DAS4JglgPMhKBQYYWhRGGA1eDT4Z2AYFXii+LFIFmTAGBDoFAAQEB Received: from mail.ietf.org ([4.31.198.44]) by gatewayhorse2.qualcomm.com with ESMTP; 19 Aug 2014 18:42:50 -0700 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 327A31A6F50; Tue, 19 Aug 2014 18:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1408498969; bh=MCB/QdYrsolV9YEhD0SmFgB78ZUW2FuEogXDYPrxYsw=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: Subject:Message-ID:Date:Cc:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Sender; b=PhEFNgCCa4zU2QicG7ZwDPv0EPVpw7VTM1qGTyyMOQt3rvEa2kRO4SfNoQ6Q/XN3F rE8+mwGbNLJqnoFuYp81Am+7m3844udbZ4P+uQAi7T2uKSShd/1ZG1lNjm1k0m4lS8 ogJeMbSl65fmlD8sF6cnG7tf+czI7xZ+ysIp6kbs= X-Original-To: iesg@ietfa.amsl.com Delivered-To: iesg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D671A6F50 for ; Tue, 19 Aug 2014 18:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXs4GJwIIH0T; Tue, 19 Aug 2014 18:42:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E331A6F30; Tue, 19 Aug 2014 18:42:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell To: The IESG Subject: Stephen Farrell's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820014244.17716.34331.idtracker@ietfa.amsl.com> Date: Tue, 19 Aug 2014 18:42:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/iesg/zHFb7TY5LQNa8gZpGOW1IkHWcCk CC: , X-BeenThere: iesg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iesg-bounces@ietf.org Sender: iesg Stephen Farrell has entered the following ballot position for draft-ietf-paws-protocol-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi, I've a few things to discuss, but I think only the first is possibly tricky... (1) 4.4.1 - why are location and deviceOwner required? The FCC may require those but why does the protocol? I don't see that those are needed for interop. Isn't that latter the right criterion for inclusion as a required field? I could see a reason for the location-from-which-I-want-to-use-WS but that's not what is described I think. The discuss here is both relating to the privacy issues with requiring exposure of identifying information but also relating to the criteria used to determine required vs. optional and how those map to interop vs. to current known sets of regulatory rules. (Same for 5.2 serialNumber, though there a dynamic/random choice may be needed instead.) (2) 4.4.1 - is the location here the location of the device or the location from which spectrum is to be used? I think you need to disambiguate those. I continue to think there should be a way to ask for spectrum in London, tomorrow; even whilst still in Dublin, today. 4.5.1 seems to imply this may be allowed sometimes, but I'm not clear if that works - how would the "tomorrow" value be sent? (3) Section 7: I think it'd be a good idea to either reference the UTA TLS BCP for ciphersuites etc or else (if you'd rather not have a dependency to another WG's I-D, which I'd understand) to specify some here. The MTIs from 5246 are looking pretty jaded right now. You may also want to mandate use of OCSP or even stapling - there are a few more TLS things you can do that help interop and to speed things up. I'm not trying to insist you do/document all of those things, but would like to chat about it for a bit. (4) Section 7: You are assuming some kind of PKI is used to authenticate DBs. Now that might work with the current Web PKI, except that then any public Web PKI CA can fake any DB but are regulator's ok with that? Secondly, TLS requires that the DB nominate the acceptable CAs for client auth, so there's a bit of specification missing here which is maybe that a DB's description needs to include information about its acceptable trust anchors. I don't think you necessarily need to fix all of that in this document, but what is the plan here? (And maybe some of it ought be fixed here, not sure.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - write-up: its a pity that coders haven't gotten together more openly and done interop, but I guess different businesses are different. - section 1, last para: I realise authorized devices is what the WG are interested in, but the protocol ought not require that, so the last sentence here is wrong - it surely should be: s/device is authorized to operate/device operates/ - Ruleset: I hope there's a NULL, meaning "no rules":-) - 4.4.1 - nothing stops a device lying about location, right? - 4.5 - the slave location vs. master location seems unclear to me. Can you clarify? - 4.5.1 - timestamp has to be UTC right? You only seem to indicate that via the "Z" in the timestamp format which I expect could be easily missed. Suggest you emphasise that. You should probably also say if truncated timestamps are ok, for example just to the minute granularity without specifying seconds. I assume that's not allowed? And lastly, please specify if the start (resp. end) of the second (or whatever) unit is when a device gains (resp. looses) spectrum. (Or add a global statement on timezones where you earlier said that identifiers are case sensitive by default.) Some of this is in 5.14, but I'm not sure if that's enough. (It could be.) - 5.2 - I don't get why you need X.520 here. - 5.5 - could a vCard value just be (the moral equivalent of) "Internet" or "I'm not telling"? - section 7: Saying the master device MUST implement server auth is confusing, since the master device is the TLS client, right? - Section 10: Under the privacy bullet you should also recognise that an authorized entity can be privacy invasive (e.g. selling contact information, sending all on to law enforcement without permission). - Section 10: Given diginotar and similar (incl. by nation states), having the master device send its identifying information in its first message means that simply saying "use TLS" is not enough. You need to say "TLS, assuming the PKI used is ok,..." or similar. --------------040802020708070400040605-- From nobody Wed Aug 20 00:08:49 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39891A0AE5; Wed, 20 Aug 2014 00:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KdQt0Zm1WnY; Wed, 20 Aug 2014 00:08:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3971A0119; Wed, 20 Aug 2014 00:08:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org, paws@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820070842.4140.65615.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 00:08:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/3h9r-lyQTpk5oWnW9WPhsb-Qiy8 Cc: iesg-secretary@ietf.org Subject: [paws] Last Call Expired: X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 07:08:44 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Wed Aug 20 09:52:44 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E74C1A049D; Wed, 20 Aug 2014 09:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVWVA8Vtbmbv; Wed, 20 Aug 2014 09:52:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D98701A04A7; Wed, 20 Aug 2014 09:52:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 09:52:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/Yjj9knK6CDyyp7HBgZJYcguX8eo Cc: paws@ietf.org, paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org Subject: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 16:52:40 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-paws-protocol-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm glad this work is being done in the IETF, thanks for all your effort. A couple of my points below have overlaps with some of Stephen's points. = Shepherd write-up = "Yes, there were 2 IPR disclosures filed that reference this document. They were discussed in the WG, and nobody came forward to say that they'd like to change anything in the document because of the disclosures." But there are 3 IPR disclosures in the tracker, not 2. Were all three discussed in the WG? = Section 4.1 = "A Database MAY change its URI, but before it changes its URI, it MUST indicate so by including the URI of one or more alternate databases using DbUpdateSpec (Section 5.7) in its responses to devices." The behavior here seems ambiguous. Does the database need to send responses containing the updated URI to all devices it has ever communicated with, or all registered devices, before it can actually change the URI? Does the database even maintain such lists? If not, how many such responses does it need to send out before changing its URI, or how long does it need to wait? Just saying that sending the new URI needs to happen "before" the URI changes does not seem specific enough for devices to know whether the URI has changed, or for databases to know when they can disable an old URI or stop sending the DbUpdateSpec indication. = Section 4.5 = These two sentences seem to contradict each other: "The device identifier, capabilities, and characteristics communicated in the AVAIL_SPECTRUM_REQ message MUST be those of the Slave Device, but the location MUST be that of the Master Device." "When the request is made by the Master Device on behalf of a Slave Device, the location is that of the Slave Device and it is OPTIONAL (see also masterDeviceLocation)." Perhaps this can be solved by making the reference to "the location" in the first sentence more specific -- the masterDeviceLocation -- but I'm not really sure from reading the text. Then later in the section, I started getting even more confused by this: "When the request is made by the Master Device on behalf of a Slave Device, the location is that of the Slave Device and it is OPTIONAL (see also masterDeviceLocation). ... masterDeviceLocation: When the request is made by the Master Device on behalf of a Slave Device, the Master Device MAY provide its own GeoLocation (Section 5.1)." Does this mean it's acceptable for a Master device acting on behalf of a Slave device to send neither the Slave device location (in the location parameter) nor the Master device location (in the masterDeviceLocation parameter)? I believe that the current text allows this. If so, why is location required in the registration step (and in batch available spectrum requests) but not in the available spectrum step? Seems like it should be the other way around -- that a device could register without specifying its location, but not request available spectrum without it. If the above interpretation was not intended, something needs to be fixed in one part or the other of the above text to indicate that either the Master device location or the Slave device location (or both) must be present in the request. The same issue arises in Section 4.5.5. = Section 5.1 = I'd like to discuss why the single point location format needs to be supported here. Is it really the case that a portion of whitespace spectrum will ever be available only at a single point, as opposed to a region? If not, it seems like sending a point (and, moreover, allowing region to be unsupported but not point) divulges more precise information about the requesting device than is ever actually necessary to fulfill the goals of this protocol. Do regulators require a single point? Why? = Section 5.2 = I'd like to discuss why the device serial number needs to be included in the device descriptor, rather than some (perhaps persistent) randomly generated device identifier that is used only in the context of this protocol (which would better protect the privacy of the user of the device, since the whitespaces database administrator wouldn't be able to correlate the device's spectrum requests with other activities linked to the serial number). It's not really clear why serial number is collected since both this document and RFC 6953 note the protocol does not defend against abuse or mis-use of spectrum. I'm asking the above two questions in light of requirement P.7 from RFC 6953, "The PAWS protocol SHOULD support privacy-sensitive handling of device-provided data where such protection is feasible, allowed, and desired." A separate interesting question that does not seem to be addressed anywhere in the draft is whether a device can be fingerprinted by the database operator by virtue of the collection of elements it sends (rulesetIds, manufacturer, model, antenna characteristics, device capabilities, etc.) even if it doesn't send a serial number or device owner information that uniquely identify it. That seems worth discussion in Section 10. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = Shepherd write-up= "An in-depth review by a JSON expert might be useful." Did that happen? = Section 1 = "It opens the door for innovations in spectrum management that can incorporate a variety of parameters, including user location and time. In the future, it also can include other parameters, such as user priority, time, signal type and power, spectrum supply and demand, payment or micro-auction bidding, and more." Time seems to be listed both as a current parameter and a future one, which is confusing. = Section 4.4 = "FCC rules, for example, require that a 'Fixed Device' register its owner and operator contact information, its device identifier, its location, and its antenna height." It would be nice to have a citation for the rules referenced here. = Section 5.1 = Feel free to ignore this if it's completely misguided, but does altitude really not matter? Are we sure this protocol won't be re-used for devices on airplanes trying to find available spectrum? (I note that in RFC 6953, requirement D.1 specifies that the data model must support "the height and its uncertainty" -- I have no idea what "the height" means or if it is related to altitude.) = Section 10 = I agree with Stephen that the database operator should be considered as a potential adversary from the standpoint of potentially being able to create a fine-grained database that tracks the locations and spectrum use patterns of individual devices. That data could certainly be abused. From nobody Wed Aug 20 12:32:09 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7600E1A06C3; Wed, 20 Aug 2014 12:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXhUHP3Cj-0P; Wed, 20 Aug 2014 12:32:05 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4AD1A06C0; Wed, 20 Aug 2014 12:32:05 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 9464CF3C024; Wed, 20 Aug 2014 15:31:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id OQIy+o23ufiC; Wed, 20 Aug 2014 15:31:29 -0400 (EDT) Received: from [10.0.0.3] (nc-76-3-83-124.dhcp.embarqhsd.net [76.3.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 00EA4F3C030; Wed, 20 Aug 2014 15:31:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 15:31:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> To: draft-ietf-paws-protocol@tools.ietf.org X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/paws/QlloQ9wdvN5955tEsBmshzwA3s8 Cc: paws@ietf.org, paws-chairs@tools.ietf.org, The IESG Subject: [paws] Comment on draft-ietf-paws-protocol-14 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 19:32:06 -0000 I would like to see Sections 9.1 say something more about the ruleset = specification. In particular, I wonder if it is possible to say = anything about stability, availability, or free access. Russ From nobody Wed Aug 20 12:40:37 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7091A06C5; Wed, 20 Aug 2014 12:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQRNg9c1Hv9I; Wed, 20 Aug 2014 12:40:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5709D1A06B0; Wed, 20 Aug 2014 12:40:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820194033.9083.72875.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 12:40:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/UhitQZzsEJaQ0KVsR4xEo_89Row Cc: paws@ietf.org, paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org Subject: [paws] Adrian Farrel's No Objection on draft-ietf-paws-protocol-14: (with COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 19:40:35 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-paws-protocol-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Stephen asked a geolocation question about RFC 6953 as it was being processed to try to establish whether the location information supplied for a query needed to be the location of the querrier or the location about which the querry is being made. Going back to the text in 1.2 of 6953, it is pretty clear that the intent is to issue a queery that relates to the whitespace at a location. Given this, I agree with Stephen that including location info in the INIT_REQ and REGISTRATION_REQ seems unnecessary. It seems to be being used as some form of authorisation check, and I don't see how that is safe or valid. But also I don't see what stops the sender from lying. Surely the important thing is about where the whitespace is available, not from where the requester operates? But even in 4.5.1 there is some confusion... location: The GeoLocation (Section 5.1) for the device requesting available spectrum. The location SHOULD be the current location of the device, but more precisely, the location of the radiation center of the device's antenna. When the request is made by the Master Device on its own behalf, the location is that of the Master Device and it is REQUIRED. When the request is made by the Master Device on behalf of a Slave Device, the location is that of the Slave Device and it is OPTIONAL (see also masterDeviceLocation). The location may be an anticipated position of the device to support mobile devices, but its use depends on the ruleset. If the location specifies a region, rather than a point, the Database MAY return an error with the UNIMPLEMENTED (Table 1) code, if it does not implement query by region. I don't see why you have SHOULD given the subsequent lowercase may. Surely you need "the location it the location about which the enquiry is being made." Reading all this and going back to 6953 I am not sure I understand the difference between having permission to operate on a frequency at a location (which seems to be granted by registration) and discovering which frequencies are available (which seems to be determined by AVAIL_SPECTRUM_RESP). Clearly I am missing something in my read through. If you think it is already covered, that's fine. But if not, perhaps you could add some text to explain things. From nobody Wed Aug 20 14:03:53 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16211A6F55; Wed, 20 Aug 2014 14:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.669 X-Spam-Level: X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv6lB98nCPw6; Wed, 20 Aug 2014 14:03:45 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98861A6EF1; Wed, 20 Aug 2014 14:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408568625; x=1440104625; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WfLyjZzjr8ITtUxxJtNYgYOT+7cFClBGHpAbBGJFOlw=; b=O60E83Q31CwK8nEAULQ2kGN5cCQqVpSEvE/lsbwy3DaE1TZ6b9yPu/fe cF/3Dji2EQPGmG/WnvGWUzl0EudjOabjcX3dfnSkW9e3I0tGTOnNG0lfN 7OiDyYFKQx6vHmKZTDuN/nzWchn10B6wn31b72AxlW5UN+2j2UaTy8geP A=; X-IronPort-AV: E=McAfee;i="5600,1067,7536"; a="59388815" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine01.qualcomm.com with ESMTP; 20 Aug 2014 14:03:44 -0700 X-IronPort-AV: E=Sophos;i="5.01,904,1400050800"; d="scan'208";a="31119459" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Aug 2014 14:03:43 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 20 Aug 2014 14:03:43 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 20 Aug 2014 14:03:42 -0700 Message-ID: <53F50D2D.2010203@qti.qualcomm.com> Date: Wed, 20 Aug 2014 16:03:41 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Kathleen Moriarty References: <20140820203127.25270.64032.idtracker@ietfa.amsl.com> In-Reply-To: <20140820203127.25270.64032.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/bZz70gPi9bLQ_KqTEo5ZlOkUDOw Cc: paws@ietf.org, paws-chairs@tools.ietf.org, The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 21:03:48 -0000 On 8/20/14 3:31 PM, Kathleen Moriarty wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > [...] > Can clients query any database entries or is the interface restricted to > the list of supported interactions? I assume the answer is that it is > limited to the set of database interactions defined, but could not find > any statement saying that in this draft or the prior requirements in > RFC6953. > I'm not sure exactly what you mean here. Are you asking whether the client or server ask for/send back more than the minimum data? Sure, that's what the "*other" business is about. Or are you asking whether additional queries/responses can be defined? I suppose they could. But I'm not sure what you're asking, or what the concern is. Can you elaborate? > Authentication is only a MAY in the Security Considerations Section, > which raises another possible concern for me. > > Since clients can get back pretty much all of the defined datatypes > (DeviceDescriptor is one example) The client only gets back the DeviceDescriptor that it sent to the server in the request so that the client can match the response to the query. > and authentication is not required, > there should be a discussion on the risks of revealing this information > for both the privacy reasons Stephen and Alissa outlined as well as > possible security concerns. I think this should be on a field basis in > terms of sensitive elements where relevant. > The rest of the responses are the publicly available spectrum information. I'm not seeing sensitive data there. > I could see how you might want/need the types of information gathered > within an administrative domain or accessed by a restricted set of users, > but revealing data like what is contained in deviceDescriptor (includes > model) as well as sensitive fields in other classes > (AntennaCharacteristics) seems like a risk as it could be used in > targeted attacks if there are known vulnerabilities to those devices. > The attacks could target specific regions at specific times to effect > events or to be used as part of some larger attack (could include > physical). This may sound crazy, but layered attacks are very real. > This seems like it would be a problem for sniffing unencrypted data *from* another client, but I'm not getting how this sort of attack works by a client owned by the attacker querying the database. Before I get back to the rest of your query, help me understand this far. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Aug 20 21:04:36 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1141A6FFE; Wed, 20 Aug 2014 21:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.669 X-Spam-Level: X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M_yncArVeAw; Wed, 20 Aug 2014 21:04:32 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514D51A7004; Wed, 20 Aug 2014 21:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408593872; x=1440129872; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=8DEuwQGXjtiy7tLIh4OYLEAIoAAkN+OseJ/3GzF2Amk=; b=R6CcvK1g+/Dh/AXAZNGtodqf8Pbx345CzPs9uzwj4hZkAyy1Dk5Wy6vq cUwDWus27pyN6fMfQEpQeIlTzOKwbmZbXI8cTFcwL03ohAuf2rCSxFLwd ccfV6+ug5Z8qC8HcisGIREgapgj/YMAZTyaSrfu7Y5p/e8cn5y7ihuItp 4=; X-IronPort-AV: E=McAfee;i="5600,1067,7536"; a="59457395" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine01.qualcomm.com with ESMTP; 20 Aug 2014 21:04:31 -0700 X-IronPort-AV: E=Sophos;i="5.01,906,1400050800"; d="scan'208";a="31121434" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 20 Aug 2014 21:04:30 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 20 Aug 2014 21:04:30 -0700 Message-ID: <53F56FCB.3030003@qti.qualcomm.com> Date: Wed, 20 Aug 2014 23:04:27 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Alissa Cooper References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> In-Reply-To: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/ssy6dZIcNDOTiMXvzEuHBHuJ0Jc Cc: paws@ietf.org, paws-chairs@tools.ietf.org, The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 04:04:34 -0000 Wow! We never received notification of that 3rd IPR disclosure and I therefore totally missed it. The fact is that it appears to be on the as-yet-undefined and perhaps never-to-be-finished discovery part of the protocol, so the WG may not care. But the WG must be consulted. Good catch! Don't know how I missed it in my final check. (I'll independently check with the secretariat about how we missed the announcement.) pr On 8/20/14 11:52 AM, Alissa Cooper wrote: > = Shepherd write-up = > "Yes, there were 2 IPR disclosures filed that reference this document. > They were discussed in the WG, and nobody came forward to say that they'd > like to change anything in the document because of the disclosures." > > But there are 3 IPR disclosures in the tracker, not 2. Were all three > discussed in the WG? > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Aug 21 00:10:50 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2191A0424 for ; Thu, 21 Aug 2014 00:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjriNz3ioh9c for ; Thu, 21 Aug 2014 00:10:44 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1231A00D8 for ; Thu, 21 Aug 2014 00:10:43 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id hq11so10406444vcb.10 for ; Thu, 21 Aug 2014 00:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=efYl1ih3rvn4oB359noKz73zvBmlQOu6lcQH/IenJRo=; b=EjFqJmc9DShn8FMdPAuzvtJKSBGXGsllZ2uHwMRHKPLRWlBfjZBCh9ROwBr+zWKknT NcBjpE7vA+eYUK7PGoaeuhM7JJ+n1sv/pZJ6t4SAJC6Q0l+yerYwDhN6zKkz7aWhQ9B1 17Jmsf1mgWG1Nq8VxEBfKicpABdLtCEVQRTD4QD8QQ3rXAT6yY56MGEDiPJWpWXM0zpM drLmmerMW01wKK4ewx5JKAHp+YTmK2U/2E5AdAutY6ao4vOuJICs1WltvBL3TT6vMJyE whB8CnxIHWU6CAebi0mbIibnJjf2PwtuomVTXFXyaftDtNKMi4QCJeIP6XRhhQnzTIsC a4Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=efYl1ih3rvn4oB359noKz73zvBmlQOu6lcQH/IenJRo=; b=WPh8J7xZZK7XnsALgh/mLmxntcE3ZWVqHfE1utfTjDzOkKaw4LJv9BSuHIwc5oIwnz qfK4giqPtE5Snt5oa/9OHIxRGROxWFbfBhxMUqqHSFcPwTLi+BZ6E6zQmTSMcK/LJqFH kl2LQfB7uh/Rsd9fyok3EdLx24tzc/ChI1IZ01D/YNcDCFLfyqO4AxM7uIPXV5U/moI2 inDV0ipRaZxI8g/SLNHAbYJlFzP+X8VdRJ5r2lkQH7mDBbJ3mMzMXYo23QMP+8YzXsVa U8r5eUQgKYX4hPvmuZDK2eBW1Ny50pt2KR0qXKC6bAbU+05E+G4PeApxN1d7kh5+kdlC gWMQ== X-Gm-Message-State: ALoCoQm81IMyNWTxBX6ILhvbPRNi7Z+OopocC0vB8bKInB4I7M0hprYqcHNKnFOz6LX737WDF/2O MIME-Version: 1.0 X-Received: by 10.52.146.17 with SMTP id sy17mr11310084vdb.29.1408605042842; Thu, 21 Aug 2014 00:10:42 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Thu, 21 Aug 2014 00:10:42 -0700 (PDT) In-Reply-To: <20140820194033.9083.72875.idtracker@ietfa.amsl.com> References: <20140820194033.9083.72875.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 00:10:42 -0700 Message-ID: From: Vincent Chen To: Adrian Farrel Content-Type: multipart/alternative; boundary=bcaec52d5987353cb605011e6b80 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/jGfHPx3fJuJnWQ0XpSyt9IxaN2U Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Adrian Farrel's No Objection on draft-ietf-paws-protocol-14: (with COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 07:10:47 -0000 --bcaec52d5987353cb605011e6b80 Content-Type: text/plain; charset=UTF-8 Adrian, On Wed, Aug 20, 2014 at 12:40 PM, Adrian Farrel wrote: > Adrian Farrel has entered the following ballot position for > draft-ietf-paws-protocol-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Stephen asked a geolocation question about RFC 6953 as it was being > processed to try to establish whether the location information supplied > for a query needed to be the location of the querrier or the location > about which the querry is being made. Going back to the text in 1.2 of > 6953, it is pretty clear that the intent is to issue a queery that > relates to the whitespace at a location. > Given this, I agree with Stephen that including location info in the > INIT_REQ and REGISTRATION_REQ seems unnecessary. It seems to be being > used as some form of authorisation check, and I don't see how that is > safe or valid. But also I don't see what stops the sender from lying. > Surely the important thing is about where the whitespace is available, > not from where the requester operates? > Please see my response to Stephen regarding registration. Location is required for both INIT_REQ and REGISTRATION_REQ, because the DB must determine which ruleset is applicable (based on location) before it can return the proper set of information. Especially for INIT_REQ, the DB should respond with only the ruleset IDs that are applicable for the location. Also, registration, at least for FCC, is for fixed devices and is for "a device at a location", not the registration of a device. > > But even in 4.5.1 there is some confusion... > > location: The GeoLocation (Section 5.1) for the device requesting > available spectrum. The location SHOULD be the current location > of the device, but more precisely, the location of the radiation > center of the device's antenna. When the request is made by the > Master Device on its own behalf, the location is that of the > Master Device and it is REQUIRED. When the request is made by the > Master Device on behalf of a Slave Device, the location is that of > the Slave Device and it is OPTIONAL (see also > masterDeviceLocation). The location may be an anticipated > position of the device to support mobile devices, but its use > depends on the ruleset. If the location specifies a region, > rather than a point, the Database MAY return an error with the > UNIMPLEMENTED (Table 1) code, if it does not implement query by > region. > > I don't see why you have SHOULD given the subsequent lowercase may. > Surely you need "the location it the location about which the enquiry > is being made." > Thanks for pointing that out. SHOULD should be relaxed to "is typically". > > Reading all this and going back to 6953 I am not sure I understand the > difference between having permission to operate on a frequency at a > location (which seems to be granted by registration) and discovering > which frequencies are available (which seems to be determined by > AVAIL_SPECTRUM_RESP). > As mentioned in my reply to Stephen, registration is simply to tell FCC where high-power devices are operating so that it can contact the operator to shut down if there are problems. The spectrum it's allowed to use still needs to be retrieved via AVAIL_SPECTRUM_RESP, since that can change on a daily basis. Registration does not include what spectrum the device intends to use. > > Clearly I am missing something in my read through. If you think it is > already covered, that's fine. But if not, perhaps you could add some > text to explain things. > > Let me see if I can add some text to the "registration". -vince > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- -vince --bcaec52d5987353cb605011e6b80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adrian,



<= div class=3D"gmail_quote">On Wed, Aug 20, 2014 at 12:40 PM, Adrian Farrel <= span dir=3D"ltr"><adrian@olddog.co.uk> wrote:
Adrian Farrel has entered the following ball= ot position for
draft-ietf-paws-protocol-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/<= br>


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

Stephen asked a geolocation question about RFC 6953 as it was being
processed to try to establish whether the location information supplied
for a query needed to be the location of the querrier or the location
about which the querry is being made. Going back to the text in 1.2 of
6953, it is pretty clear that the intent is to issue a queery that
relates to the whitespace at a location.=C2=A0

Given this, I agree with Stephen that including location info in the
INIT_REQ and REGISTRATION_REQ seems unnecessary. It seems to be being
used as some form of authorisation check, and I don't see how that is safe or valid. But also I don't see what stops the sender from lying. Surely the important thing is about where the whitespace is available,
not from where the requester operates?

= Please see my response to Stephen regarding registration.

=C2=A0Location is required for both INIT_REQ and REGISTRATION_REQ, = because the
=C2=A0DB must determine which ruleset is applicable (based on location= ) before it can
=C2=A0return the proper set of information.
=

=C2=A0Especially for INIT_REQ, the DB should respond wi= th only the ruleset IDs that are applicable
=C2=A0for the location.

Also, registration, a= t least for FCC, is for fixed devices and is for "a device at a locati= on", not
the registration of a device.
=C2=A0
<= /div>

But even in 4.5.1 there is some confusion...

=C2=A0 =C2=A0location:=C2=A0 The GeoLocation (Section 5.1) for the device r= equesting
=C2=A0 =C2=A0 =C2=A0 available spectrum.=C2=A0 The location SHOULD be the c= urrent location
=C2=A0 =C2=A0 =C2=A0 of the device, but more precisely, the location of the= radiation
=C2=A0 =C2=A0 =C2=A0 center of the device's antenna.=C2=A0 When the req= uest is made by the
=C2=A0 =C2=A0 =C2=A0 Master Device on its own behalf, the location is that = of the
=C2=A0 =C2=A0 =C2=A0 Master Device and it is REQUIRED.=C2=A0 When the reque= st is made by the
=C2=A0 =C2=A0 =C2=A0 Master Device on behalf of a Slave Device, the locatio= n is that of
=C2=A0 =C2=A0 =C2=A0 the Slave Device and it is OPTIONAL (see also
=C2=A0 =C2=A0 =C2=A0 masterDeviceLocation).=C2=A0 The location may be an an= ticipated
=C2=A0 =C2=A0 =C2=A0 position of the device to support mobile devices, but = its use
=C2=A0 =C2=A0 =C2=A0 depends on the ruleset.=C2=A0 If the location specifie= s a region,
=C2=A0 =C2=A0 =C2=A0 rather than a point, the Database MAY return an error = with the
=C2=A0 =C2=A0 =C2=A0 UNIMPLEMENTED (Table 1) code, if it does not implement= query by
=C2=A0 =C2=A0 =C2=A0 region.

I don't see why you have SHOULD given the subsequent lowercase may.
Surely you need "the location it the location about which the enquiry<= br> is being made."

Thanks for pointin= g that out. SHOULD should be relaxed to "is typically".
=C2=A0

Reading all this and going back to 6953 I am not sure I understand the
difference between having permission to operate on a frequency at a
location (which seems to be granted by registration) and discovering
which frequencies are available (which seems to be determined by
AVAIL_SPECTRUM_RESP).

As mentioned in m= y reply to Stephen, registration is simply to tell FCC
where high= -power devices are operating so that it can contact the operator
to shut down if there are problems. The spectrum it's allowed to u= se still
needs to be retrieved via AVAIL_SPECTRUM_RESP, since tha= t can change
on a daily basis.

Registrat= ion does not include what spectrum the device intends to use.
=C2=A0

Clearly I am missing something in my read through. If you think it is
already covered, that's fine. But if not, perhaps you could add some text to explain things.


Let me see if I can add some text to t= he "registration".

-vince=C2=A0

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



--
-vince
--bcaec52d5987353cb605011e6b80-- From nobody Thu Aug 21 00:59:13 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12CE1A0704 for ; Thu, 21 Aug 2014 00:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXcJRMKCsfG7 for ; Thu, 21 Aug 2014 00:59:01 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D1E1A0476 for ; Thu, 21 Aug 2014 00:59:01 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id im17so10373172vcb.17 for ; Thu, 21 Aug 2014 00:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CZ3hLSruhtPNq+NaD+PPnPfR0jfVIPkgQGK2ESFufpU=; b=HFmH7BgYzoF+3bSBtAnhBppVUEebc2b9ksmv08Oz/K/5hMfg5oFMkBCcWilzQP78ku /JgS85iDE/Qrj5ayasxU/HpOyRSoadfVMiWRw2jVLe6OEdDBiSnAzwlLK3cmpjFu/h7c 0y5R5dGP/PjLmVI+ObBk1M/mcsrhmfc2Tv1hS4o95z0UTdFjBJsHVWrTkgh92uTQp0E4 g626dQ5T7GIZlTg/zetw2FHSmjwaEsIPJEuM92K4OAMKO4FXxARa1HGcQW60KPMEm9ym Qur6DIoazlEeAoqEbJkPQlyDz7Fm6SJ7SG7CvmqVZ3gHRYL2eKrvZxzc016o0vyiMdSJ G0UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CZ3hLSruhtPNq+NaD+PPnPfR0jfVIPkgQGK2ESFufpU=; b=QHErLzXL1kGGpkAYUJCX7wz3pS0sRs3cmXnAWdHwrwranaJyvXaCyGgl9EbpvdPCmG jHk9tqG7IzPd9OxyFtnY3/o2qNjJTuZgyD1mApghiGnTHCfQ3xQGTFYTAz25k1F2TN3A RCqL0EVw0aaQL1Dl4Gl6jxYhj8Nf+uG6LhtdTYF9Y1EEzcC7ZrYEIwC8glWzfrckqlux ocpFxMJkcjKV1Qvpa07m9Gl+MXI8hBQhq4wAH9uzZk084yYAj6XQ6BYctoygzsSghpd4 4UdWJLYSDNpfmXvWqg7weN1gMt3zNrWwY3Q939Ug4YH7EclI8fDMxh/s2HZEll4Nwdd4 Z7NA== X-Gm-Message-State: ALoCoQk6Ta95WHvjhFFfnGpLSq/N1jDTuJXySwwdp/zb/eRVjiH5Y5h/CFfZUTnVGqFz9zytDkzv MIME-Version: 1.0 X-Received: by 10.52.146.194 with SMTP id te2mr35171450vdb.4.1408607940727; Thu, 21 Aug 2014 00:59:00 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Thu, 21 Aug 2014 00:59:00 -0700 (PDT) In-Reply-To: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 00:59:00 -0700 Message-ID: From: Vincent Chen To: Alissa Cooper Content-Type: multipart/alternative; boundary=bcaec51ba211ef805305011f17cf Archived-At: http://mailarchive.ietf.org/arch/msg/paws/Wo8Xm7OdKAXx2ph7wXI2VKIcOpc Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 07:59:05 -0000 --bcaec51ba211ef805305011f17cf Content-Type: text/plain; charset=UTF-8 Alissa, Thanks and sorry for the delay. Please see answers inline. On Wed, Aug 20, 2014 at 9:52 AM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-paws-protocol-14: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm glad this work is being done in the IETF, thanks for all your > effort. > > A couple of my points below have overlaps with some of Stephen's points. > > = Shepherd write-up = > "Yes, there were 2 IPR disclosures filed that reference this document. > They were discussed in the WG, and nobody came forward to say that they'd > like to change anything in the document because of the disclosures." > > But there are 3 IPR disclosures in the tracker, not 2. Were all three > discussed in the WG? > Pete addressed this. > > = Section 4.1 = > "A Database MAY change its URI, but before it changes its URI, it MUST > indicate so by including the URI of one or more alternate databases > using DbUpdateSpec (Section 5.7) in its responses to devices." > > The behavior here seems ambiguous. Does the database need to send > responses containing the updated URI to all devices it has ever > communicated with, or all registered devices, before it can actually > change the URI? Does the database even maintain such lists? If not, how > many such responses does it need to send out before changing its URI, or > how long does it need to wait? Just saying that sending the new URI needs > to happen "before" the URI changes does not seem specific enough for > devices to know whether the URI has changed, or for databases to know > when they can disable an old URI or stop sending the DbUpdateSpec > indication. > Thanks for pointing this out. Note that this is not a push mechanism, so there is no list of clients to maintain. Rather, the DbUpdateSpec is added to the responses when a Device contacts the Database. Propose adding the following clarifying points to add to the text: - The database SHOULD reply with DbUpdateSpec for a minimum of 2 weeks before disabling the old URI. > > = Section 4.5 = > These two sentences seem to contradict each other: > > "The device identifier, capabilities, and characteristics > communicated in the AVAIL_SPECTRUM_REQ message MUST be those of the > Slave Device, but the location MUST be that of the Master Device." > Ouch! I'll fix that. "... location MUST be that of the Slave Device." > > "When the request is made by the > Master Device on behalf of a Slave Device, the location is that of > the Slave Device and it is OPTIONAL (see also > masterDeviceLocation)." > > Perhaps this can be solved by making the reference to "the location" in > the first sentence more specific -- the masterDeviceLocation -- but I'm > not really sure from reading the text. > > Then later in the section, I started getting even more confused by this: > > "When the request is made by the > Master Device on behalf of a Slave Device, the location is that of > the Slave Device and it is OPTIONAL (see also > masterDeviceLocation). > ... > masterDeviceLocation: When the request is made by the Master Device > on behalf of a Slave Device, the Master Device MAY provide its own > GeoLocation (Section 5.1)." > You're right to be confused. Sorry. masterDeviceLocation is required when the Master Device is making a request on behalf of a Slave Device. Needs to be fixed for BATCH request also (4.5.3 and 4.5.5) > > Does this mean it's acceptable for a Master device acting on behalf of a > Slave device to send neither the Slave device location (in the location > parameter) nor the Master device location (in the masterDeviceLocation > parameter)? I believe that the current text allows this. If so, why is > location required in the registration step (and in batch available > spectrum requests) but not in the available spectrum step? Seems like it > should be the other way around -- that a device could register without > specifying its location, but not request available spectrum without it. > > If the above interpretation was not intended, something needs to be fixed > in one part or the other of the above text to indicate that either the > Master device location or the Slave device location (or both) must be > present in the request. > The same issue arises in Section 4.5.5. > Yes. Will fix. > > = Section 5.1 = > I'd like to discuss why the single point location format needs to be > supported here. Is it really the case that a portion of whitespace > spectrum will ever be available only at a single point, as opposed to a > region? If not, it seems like sending a point (and, moreover, allowing > region to be unsupported but not point) divulges more precise information > about the requesting device than is ever actually necessary to fulfill > the goals of this protocol. Do regulators require a single point? Why? > The resulting spectrum is valid for 100m (typically) radius around that point. Computation of available spectrum for a region is actually complex and not well defined... > > = Section 5.2 = > I'd like to discuss why the device serial number needs to be included in > the device descriptor, rather than some (perhaps persistent) randomly > generated device identifier that is used only in the context of this > protocol (which would better protect the privacy of the user of the > device, since the whitespaces database administrator wouldn't be able to > correlate the device's spectrum requests with other activities linked to > the serial number). It's not really clear why serial number is collected > since both this document and RFC 6953 note the protocol does not defend > against abuse or mis-use of spectrum. > The regulator want to have the ability to black list ranges of serial numbers, if it determines that a series was defective. The Databases must use the serial number to determine it can return available spectrum. > > I'm asking the above two questions in light of requirement P.7 from RFC > 6953, "The PAWS protocol SHOULD support privacy-sensitive handling of > device-provided data where such protection is feasible, allowed, and > desired." > > A separate interesting question that does not seem to be addressed > anywhere in the draft is whether a device can be fingerprinted by the > database operator by virtue of the collection of elements it sends > (rulesetIds, manufacturer, model, antenna characteristics, device > capabilities, etc.) even if it doesn't send a serial number or device > owner information that uniquely identify it. That seems worth discussion > in Section 10. > What should the discussion say? Just that it is possible? or does it need to have a solution? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > = Shepherd write-up= > "An in-depth review by a JSON expert might be useful." > > Did that happen? > Tim Bray had looked at it before final call. > > = Section 1 = > "It opens the door for innovations in spectrum > management that can incorporate a variety of parameters, including > user location and time. In the future, it also can include other > parameters, such as user priority, time, signal type and power, > spectrum supply and demand, payment or micro-auction bidding, and > more." > > Time seems to be listed both as a current parameter and a future one, > which is confusing. > Agreed. The second "time" should be removed. > > = Section 4.4 = > "FCC rules, for example, require that a 'Fixed Device' > register its owner and operator contact information, its device > identifier, its location, and its antenna height." > > It would be nice to have a citation for the rules referenced here. > OK. > > = Section 5.1 = > Feel free to ignore this if it's completely misguided, but does altitude > really not matter? Are we sure this protocol won't be re-used for devices > on airplanes trying to find available spectrum? (I note that in RFC 6953, > requirement D.1 specifies that the data model must support "the height > and its uncertainty" -- I have no idea what "the height" means or if it > is related to altitude.) > See Section 5.3 on "height" of the antenna. It's separated out, from the "latitude, longitude" specification of GeoLocation. It allows specification with respect to ground level or mean sea level, and is intended for Fixed devices, rather than mobile devices. >From the current regulator's perspective, the allowed power for mobile devices is low enough that height does not matter. > > = Section 10 = > I agree with Stephen that the database operator should be considered as a > potential adversary from the standpoint of potentially being able to > create a fine-grained database that tracks the locations and spectrum use > patterns of individual devices. That data could certainly be abused. > > So just listing that as a potential threat and declare that fixing this as out of scope is sufficient? Or do we need to state that Databases MUST not track? I can see how anonymized tracking can be useful for spectrum management in the future, much like anonymized tracking of car locations provide valuable traffic information for navigation systems. -- -vince --bcaec51ba211ef805305011f17cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alissa,

Thanks and sorry for the delay.= Please see answers inline.


On Wed, Aug 20, 2014 at 9:52 AM, Alissa Cooper <alissa= @cooperw.in> wrote:
Alissa Cooper has entered the following ball= ot position for
draft-ietf-paws-protocol-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/<= br>


----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm glad this work is being done in the IETF, thanks for all your
effort.

A couple of my points below have overlaps with some of Stephen's points= .

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

Pete addressed thi= s.
=C2=A0

=3D Section 4.1 =3D
"A Database MAY change its URI, but before it changes its URI, it MUST=
=C2=A0 =C2=A0indicate so by including the URI of one or more alternate data= bases
=C2=A0 =C2=A0using DbUpdateSpec (Section 5.7) in its responses to devices.&= quot;

The behavior here seems ambiguous. Does the database need to send
responses containing the updated URI to all devices it has ever
communicated with, or all registered devices, before it can actually
change the URI? Does the database even maintain such lists? If not, how
many such responses does it need to send out before changing its URI, or how long does it need to wait? Just saying that sending the new URI needs to happen "before" the URI changes does not seem specific enough = for
devices to know whether the URI has changed, or for databases to know
when they can disable an old URI or stop sending the DbUpdateSpec
indication.

Thanks for pointing this ou= t. Note that this is not a push mechanism, so there
is no list of= clients to maintain. Rather, the DbUpdateSpec is added
to the re= sponses when a Device contacts the Database.

Propose adding the following clarifying points to add t= o the text:
=C2=A0 - The database SHOULD reply with DbUpdateSpec = for a minimum of 2 weeks before disabling the old URI.
=C2=A0

=3D Section 4.5 =3D
These two sentences seem to contradict each other:

"The device identifier, capabilities, and characteristics
=C2=A0 =C2=A0communicated in the AVAIL_SPECTRUM_REQ message MUST be those o= f the
=C2=A0 =C2=A0Slave Device, but the location MUST be that of the Master Devi= ce."

Ouch! I'll fix that. &quo= t;... location MUST be that of the Slave Device."=C2=A0

"When the request is made by the
=C2=A0 =C2=A0 =C2=A0 Master Device on behalf of a Slave Device, the locatio= n is that of
=C2=A0 =C2=A0 =C2=A0 the Slave Device and it is OPTIONAL (see also
=C2=A0 =C2=A0 =C2=A0 masterDeviceLocation)."

Perhaps this can be solved by making the reference to "the location&qu= ot; in
the first sentence more specific -- the masterDeviceLocation -- but I'm=
not really sure from reading the text.

Then later in the section, I started getting even more confused by this:
"When the request is made by the
=C2=A0 =C2=A0 =C2=A0 Master Device on behalf of a Slave Device, the locatio= n is that of
=C2=A0 =C2=A0 =C2=A0 the Slave Device and it is OPTIONAL (see also
=C2=A0 =C2=A0 =C2=A0 masterDeviceLocation).
=C2=A0 =C2=A0 =C2=A0 ...
masterDeviceLocation:=C2=A0 When the request is made by the Master Device =C2=A0 =C2=A0 =C2=A0 on behalf of a Slave Device, the Master Device MAY pro= vide its own
=C2=A0 =C2=A0 =C2=A0 GeoLocation (Section 5.1)."
=
You're right to be confused. Sorry. masterDeviceLocation= is required when the
Master Device is making a request on behalf= of a Slave Device.
Needs to be fixed for BATCH request also (4.5.3 and 4.5.5)
= =C2=A0

Does this mean it's acceptable for a Master device acting on behalf of = a
Slave device to send neither the Slave device location (in the location
parameter) nor the Master device location (in the masterDeviceLocation
parameter)? I believe that the current text allows this. If so, why is
location required in the registration step (and in batch available
spectrum requests) but not in the available spectrum step? Seems like it should be the other way around -- that a device could register without
specifying its location, but not request available spectrum without it.

If the above interpretation was not intended, something needs to be fixed in one part or the other of the above text to indicate that either the
Master device location or the Slave device location (or both) must be
present in the request.

The same issue arises in Section 4.5.5.

Yes. Will fix.=C2=A0

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

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

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

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

T= he regulator want to have the ability to black list ranges of serial number= s, if it
determines that a series was defective. The Databases mu= st use the serial number
to determine it can return available spectrum.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
I'm asking the above two questions in light of requirement P.7 from RFC=
6953, "The PAWS protocol SHOULD support privacy-sensitive handling of<= br> device-provided data where such protection is feasible, allowed, and
desired."

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

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


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

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

Did that happen?

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

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

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

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

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

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

OK.
=C2=A0

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

See Section 5.= 3 on "height" of the antenna. It's separated out, from the &q= uot;latitude, longitude" specification
of GeoLocation. It al= lows specification with respect to ground level or mean sea level, and is i= ntended
for Fixed devices, rather than mobile devices.

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

=C2=A0

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


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

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

--
-vince
--bcaec51ba211ef805305011f17cf-- From nobody Thu Aug 21 01:16:04 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BBA1A0720 for ; Thu, 21 Aug 2014 01:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yglCmDVFBrwP for ; Thu, 21 Aug 2014 01:15:56 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18951A0716 for ; Thu, 21 Aug 2014 01:15:55 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id hq11so10194971vcb.24 for ; Thu, 21 Aug 2014 01:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XHnsqSnbPqz7kzeWeZSC10kMoJ7RMFp0DPerXYFA+8c=; b=FeU0nR0siTFYuhZyinxdlFGqzFfO/Pm2kFAZwHoJDbp0PmS6EJy4G2oMi/oA4rsT2o JAgt3DJ2no63NKxr02CkXUKVrMHwFBEHv5BU8HrqD+/9BPpr5RFwzGKosi3/QOvOpVrm ojCxP/PiSLtyy6ncXoe8Ra2MxemfdE5h0y9s59PFNNxNVJxCMhdGq6FmRQ8wiDBR7H5s UvgkU+30ad7XzMMHF2ama06l6jS5eIMCJjGe/uc44GV30szEgsrU9Ja7NBBGsqhORLCq Da5h+OU3vijKTlBJGE92VgwMF5rWoF+qqQ55C+Ll75Qf/GphZUdtaOdCq2mT+3ZxUAq6 fDOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XHnsqSnbPqz7kzeWeZSC10kMoJ7RMFp0DPerXYFA+8c=; b=P6pjScXXJiZspYdh2jAMCVbHqXOkiKysoMKwulIVaYooXxSe16LQu2dZQ52DHqhfvd wW+75vyhftQoTfsMCNkOONI+HwfQpRt0IDq7W2hWHU5wo4M5+L3dc0uo41Qi9bXiCae1 JuGsLS/9etPNcwryyKAE39HtKU9X4FGCt47ChU0GZ1rg04rGNU88GPdzcFavmYyoCtDY YZ1/ZgWWt7LqW4iINTmoOJ3xr2mSmEpDmzgX05WwNZSCnB9buhOMRWuJGrhpgqaUkPow 4qO6YySHAnHc3VPmXc17Lx4g3XYnAgT38BP5JhLEaQy2/cyWfJlrhS45Le9MdZXHxZ9N OlWQ== X-Gm-Message-State: ALoCoQlVe0uTZka39VUWW0nzipf7dEWKi9WqqzWenLWYGg8slE93XzFIv+GjVHZoQOiKEgYMtv13 MIME-Version: 1.0 X-Received: by 10.52.146.17 with SMTP id sy17mr11494357vdb.29.1408608954799; Thu, 21 Aug 2014 01:15:54 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Thu, 21 Aug 2014 01:15:54 -0700 (PDT) In-Reply-To: References: <20140820203127.25270.64032.idtracker@ietfa.amsl.com> <53F50D2D.2010203@qti.qualcomm.com> Date: Thu, 21 Aug 2014 01:15:54 -0700 Message-ID: From: Vincent Chen To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=bcaec52d598760fded05011f5475 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/BBmdGjQy77fCf7mClp4u3L5IF6o Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , Pete Resnick , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 08:15:58 -0000 --bcaec52d598760fded05011f5475 Content-Type: text/plain; charset=UTF-8 Thanks to Pete for responding. Additional comments inline. On Wed, Aug 20, 2014 at 3:09 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > > > > On Wed, Aug 20, 2014 at 5:03 PM, Pete Resnick > wrote: > >> On 8/20/14 3:31 PM, Kathleen Moriarty wrote: >> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> [...] >>> >>> Can clients query any database entries or is the interface restricted to >>> the list of supported interactions? I assume the answer is that it is >>> limited to the set of database interactions defined, but could not find >>> any statement saying that in this draft or the prior requirements in >>> RFC6953. >>> >>> >> >> I'm not sure exactly what you mean here. Are you asking whether the >> client or server ask for/send back more than the minimum data? Sure, that's >> what the "*other" business is about. Or are you asking whether additional >> queries/responses can be defined? I suppose they could. But I'm not sure >> what you're asking, or what the concern is. Can you elaborate? > > > There wasn't an explicit statement that you need to define new > query/responses through extensions, so that coupled with the possibility of > unauthenticated sessions had me worrying that more data could be exposed > then intended. A statement in the security considerations section (maybe) > after the MAY for authentication that helps state the limitation of the > interface to this and approved extensions would help. The risk would be > additional query/responses that let you get at more data than was intended > (some of the privacy related information or fingerprinting possibilities > would be the concern. > The security considerations section started by saying that the Database provides available spectrum information, which is public information. Nothing else can be retrieved from the Database. Does Pete's point about the DeviceDescriptor being an echo of the request also resolve this concern? > > Earlier in the draft it sounds as if authentication is required until you > get to that statement towards the end of the security considerations > section. > NOTE: Since the Database returns the same available-spectrum answer for the same combination of (device type, location), regardless of what requests came before or after, authentication of the client seems to add little benefit. I.e., spoofing by rogue devices does not impact the answer given to well-behaved devices. > >> >> Authentication is only a MAY in the Security Considerations Section, >>> which raises another possible concern for me. >>> >>> Since clients can get back pretty much all of the defined datatypes >>> (DeviceDescriptor is one example) >>> >> >> The client only gets back the DeviceDescriptor that it sent to the server >> in the request so that the client can match the response to the query. >> >> Sorry, I missed that very important point in the query/response > description somehow. > > >> >> and authentication is not required, >>> there should be a discussion on the risks of revealing this information >>> for both the privacy reasons Stephen and Alissa outlined as well as >>> possible security concerns. I think this should be on a field basis in >>> terms of sensitive elements where relevant. >>> >>> >> >> The rest of the responses are the publicly available spectrum >> information. I'm not seeing sensitive data there. >> >> Yep, for the current queries, I missed that you were only getting the > response that included the DeviceDescriptor information you sent. Sorry > about that! > >> >> I could see how you might want/need the types of information gathered >>> within an administrative domain or accessed by a restricted set of users, >>> but revealing data like what is contained in deviceDescriptor (includes >>> model) as well as sensitive fields in other classes >>> (AntennaCharacteristics) seems like a risk as it could be used in >>> targeted attacks if there are known vulnerabilities to those devices. >>> The attacks could target specific regions at specific times to effect >>> events or to be used as part of some larger attack (could include >>> physical). This may sound crazy, but layered attacks are very real. >>> >>> >> >> This seems like it would be a problem for sniffing unencrypted data >> *from* another client, but I'm not getting how this sort of attack works by >> a client owned by the attacker querying the database. >> > This is just the kind of thing you might be able to do with the full set > of info. I think just responding on the first item would be good enough as > I missed an important point. > >> >> Before I get back to the rest of your query, help me understand this far. > > > Thank you! > >> >> >> pr >> >> -- >> Pete Resnick >> Qualcomm Technologies, Inc. - +1 (858)651-4478 >> >> > > > -- > > Best regards, > Kathleen > -- -vince --bcaec52d598760fded05011f5475 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks to Pete for responding.

Addition= al comments inline.


On Wed, Aug 20, 2014 at 3:09 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:



On Wed, Aug 20, 2014= at 5:03 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
On 8/20/14 3:31 PM, Kathleen Moriarty wrote:=
-------------------------------------------------------------= ---------
DISCUSS:
-------------------------------------------------------------= ---------
[...]

Can clients query any database entries or is the interface restricted to the list of supported interactions?=C2=A0 =C2=A0I assume the answer is that= it is
limited to the set of database interactions defined, but could not find
any statement saying that in this draft or the prior requirements in
RFC6953.
=C2=A0 =C2=A0

I'm not sure exactly what you mean here. Are you asking whether the cli= ent or server ask for/send back more than the minimum data? Sure, that'= s what the "*other" business is about. Or are you asking whether = additional queries/responses can be defined? I suppose they could. But I= 9;m not sure what you're asking, or what the concern is. Can you elabor= ate?

There wasn't an explicit statement that you n= eed to define new query/responses through extensions, so that coupled with = the possibility of unauthenticated sessions had me worrying that more data = could be exposed then intended. =C2=A0A statement in the security considera= tions section (maybe) after the MAY for authentication that helps state the= limitation of the interface to this and approved extensions would help. = =C2=A0The risk would be additional query/responses that let you get at more= data than was intended (some of the privacy related information or fingerp= rinting possibilities would be the concern.=C2=A0

The security considerati= ons section started by saying that the Database provides
availabl= e spectrum information, which is public information. Nothing else can be re= trieved
from the Database.

Does Pete's point abou= t the DeviceDescriptor being an echo of the request also resolve this
=
concern?
=C2=A0

Earlier in the draft it sounds as if authentication is = required until you get to that statement towards the end of the security co= nsiderations section.

NOTE: Since the Database returns the same available-spectrum answer fo= r the same combination of (device type, location), regardless of what reque= sts came before or after, authentication of the client seems to add little = benefit. I.e., spoofing by rogue devices does not impact the answer given t= o well-behaved devices.

=C2=A0
=


Authentication is only a MAY in the Security Considerations Section,
which raises another possible concern for me.

Since clients can get back pretty much all of the defined datatypes
(DeviceDescriptor is one example)

The client only gets back the DeviceDescriptor that it sent to the server i= n the request so that the client can match the response to the query.
<= br>
Sorry, I missed that very important point = in the query/response description somehow.
=C2=A0

and authentication is not required,
there should be a discussion on the risks of revealing this information
for both the privacy reasons Stephen and Alissa outlined as well as
possible security concerns.=C2=A0 I think this should be on a field basis i= n
terms of sensitive elements where relevant.
=C2=A0 =C2=A0

The rest of the responses are the publicly available spectrum information. = I'm not seeing sensitive data there.

<= div>Yep, for the current queries, I missed that you were only getting the r= esponse that included the DeviceDescriptor information you sent. =C2=A0Sorr= y about that!=C2=A0

I could see how you might want/need the types of information gathered
within an administrative domain or accessed by a restricted set of users, but revealing data like what is contained in deviceDescriptor (includes
model) as well as sensitive fields in other classes
(AntennaCharacteristics) seems like a risk as it could be used in
targeted attacks if there are known vulnerabilities to those devices.
The attacks could target specific regions at specific times to effect
events or to be used as part of some larger attack (could include
physical).=C2=A0 This may sound crazy, but layered attacks are very real. =C2=A0 =C2=A0

This seems like it would be a problem for sniffing unencrypted data *from* = another client, but I'm not getting how this sort of attack works by a = client owned by the attacker querying the database.
This is just the kind of thing you might be able to do with the full set of= info. =C2=A0I think just responding on the first item would be good enough= as I missed an important point.=C2=A0

Before I get back to the rest of your query, help me understand this far.

Thank you!=C2=A0
=


pr

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




--
<= br>
Best regards,
Kathleen



--
-vince
--bcaec52d598760fded05011f5475-- From nobody Thu Aug 21 06:30:28 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668051A02DB; Thu, 21 Aug 2014 06:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5EIgIq5GPsO; Thu, 21 Aug 2014 06:30:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0BA1A02D8; Thu, 21 Aug 2014 06:30:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 06:30:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/ii0fXQdIcGjEeYB7QilE4eiuWrU Cc: paws@ietf.org, paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org Subject: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 13:30:27 -0000 Ted Lemon has entered the following ballot position for draft-ietf-paws-protocol-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a cool document—I'm glad the IETF is working on this. Please don't take the following comments as anything other than an attempt to address what I think are some relatively minor issues with the document, hopefully easily addressed. 4.1 says "Some regulatory domains may have specific rules regarding how long the spectrum data remains valid in these cases." It might be worth adding that in such cases the initialization procedure is required. This is addressed to some extent in section 4.3, but I'm not sure it's completely addressed. The potential problem I see is that a device might be used in a regulatory regime where this is required, but might have pre-configured values for some other regulatory regime. If these values are not valid in the regime that applies for its current location, it might have a too-long refresh interval configured, fail to detect that this is the case, and as a result accidentally break the law. Can a scenario like this occur in practice? Section 5.2 says that the manufacturer ID and model ID are optional, but may be required by some rulesets. Section 4.3.1 does not say what error is returned when a deviceDesc that does not contain one or both of these parameters is sent to the server, but the matching ruleset requires either parameter. I suspect the answer is straightforward, but I think it needs to be stated explicitly in 4.3.1. E.g., if the optional but required parameters are accepted in the initialization but rejected in the registration, it would be good to say so explicitly. In 4.4.2, I think that if none of the rulesets are accepted, the intent is that the database should return a REGISTRATION_RESP with the error element, and will not return a rulesetInfos list. However, the specification does not make an exception for this case when it says "A RulesetInfo list MUST be included" and "The list MUST contain at least one entry". I can't think of another valid interpretation, but you've stated a MUST, so you need to say that it doesn't apply in the case of the error. In 4.5: If some locations within a batch request are outside the regulatory domain supported by the Database, the Database MAY return an OK response with available spectrum for only the valid locations; otherwise, if all locations within a batch request are outside the regulatory domain, the Database MUST respond with an OUTSIDE_COVERAGE error. What should the database do if it doesn't follow the MAY? Should it return an OUTSIDE_COVERAGE error? It seems to me that this MAY is going to require some unclear heuristics on the side of the master device. Why isn't this a MUST? I think if this were a MUST, it would be clear how implementations should behave; by making it a MAY, there's a big gap that I think will lead to interoperability problems as different implementors make different choices about how to treat this situation. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3 describes spectrum-usage messages as purely informational. Section 4.5 says that the database can require that such messages be sent. Which is it: is it sometimes required, or always purely informational? Or does "purely informational" just mean that the protocol provides no mechanism for tracking such notifications? It would be helpful if this were clearer. In 4.1, the database URI change spec seems incomplete. Is there a time when a database starts announcing its URI change after which it need no longer provide service on the old URI? I see Alissa asked a similar question, so I imagine you could address both questions together. In 4.1 and 5.17, the meaning described for UNSUPPORTED appears to be somewhat fluid. I think you intend for it to mean one specific thing, which might imply one of several other things. But you don't say the one thing that it means: instead you mention possible implications. It would be helpful to try to make this more explicit. I think Stephen noticed this same problem, but to be clear, it appears that section 4.5 says that when the master is sending a request on behalf of a slave, it sends its own location. But section 4.5.1 says that the master sends the slave's location. It appears that there are two parameters, one being the master location, which is required, and the other being the slave location, which is optional. However, this is never really stated explicitly; it might be helpful if it were. I have to confess that the use of "master" and "slave" throughout this document makes me quite uncomfortable in reading it. It would really be preferable to use terms that have less painful history associated with them, like "core" and "leaf" or "coordinator" and "supplicant." I realize this is a matter of taste, and I do not at all mean to suggest that there's anything wrong with the use of these terms, which are certainly common in the computing industry. This is just a comment, and whether you address it is entirely up to you. In 4.6.1, it would help to have text that explains what it means to validate a device. It's certainly not required for interoperability, but might be helpful for implementors of database servers. In 5.3, it's a little puzzling that antenna direction, radiation pattern, gain and polarization aren't defined, because they seem like properties that should have universal applicability, even if they are not required in all cases. Is this being left as future work, or is there some more subtle reason why these haven't been defined explicitly? In 5.11, power is expressed in dbm, which leads me to wonder if this is the product of the antenna gain and the input power to the output amplifier, or whether it's just the input power to the amplifier, or whether it's being left intentionally ambiguous. From nobody Thu Aug 21 07:16:30 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BBE1A7007; Thu, 21 Aug 2014 07:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4Z6y5WeogxX; Thu, 21 Aug 2014 07:16:20 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 223E41A0344; Thu, 21 Aug 2014 07:16:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1F0FE2CED4; Thu, 21 Aug 2014 17:16:19 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84MbfimRhFzz; Thu, 21 Aug 2014 17:16:15 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 20EDA2CD0E; Thu, 21 Aug 2014 17:16:15 +0300 (EEST) Content-Type: multipart/signed; boundary="Apple-Mail=_59A88BB9-9C87-4825-AEDF-140167B9CD0A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: <53E2DC72.8020301@nostrum.com> Date: Thu, 21 Aug 2014 17:16:13 +0300 Message-Id: <3955DD41-6022-4EFE-B1DB-2081AFF8FA44@piuha.net> References: <20140806210932.26762.11590.idtracker@ietfa.amsl.com> <53E2DC72.8020301@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/paws/5EnDEDvAThowKrz2trPcQO0AxzI Cc: paws@ietf.org, General Area Review Team , draft-ietf-paws-protocol.all@tools.ietf.org, "ietf@ietf.org list" Subject: Re: [paws] [Gen-art] Genart LC review draft-ietf-paws-protocol-14 (was Re: Second Last Call: (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:16:22 -0000 --Apple-Mail=_59A88BB9-9C87-4825-AEDF-140167B9CD0A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you very much for the review and re-review, Robert. And thanks for = the updates, Vincent. Jari On 07 Aug 2014, at 04:54, Robert Sparks wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-paws-protocol-14 > Reviewer: Robert Sparks > Review Date: 6-Aug-2014 > IETF LC End Date: 20-Aug-2014 > IESG Telechat date: 21-Aug-2014 >=20 > Summary: Ready for publication as Proposed Standard >=20 > Version -14 addresses the concerns I raised with -12. > Thanks again to the WG and the authors for such quick and effective = responses. >=20 > RjS --Apple-Mail=_59A88BB9-9C87-4825-AEDF-140167B9CD0A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT9f8tAAoJEM80gCTQU46qEU4P/jMcx0ZbDnVwL+yMY8KVBy9V A74Q5h9MPxmU0mQmCzwqVo72IYW+gFlNNdeV2hyJOj9ob3e08P1m6dPQsVC+5nkf MAaSHYHOiZiKqOdJBPdW3k9WcIEMo60k00cyy6TWLhfTGLKruyeuScHXIi9UGaEu 6+QthxnhhTTBdy6Q2v67sw4Ky2PiGkxWEB43fW03zdMwgzQ10q5GAF2qeIsx+Rvw wxZsNVwJWqX6ecKlB2vGgWIa7eIGUN8ZsUSi2LAVnAghRbQnEleCzuEIupdChCf3 gYJ4wenQsObh3PJf1zHzoY+dygrHaGmpjAZvH/4ROeJNrdiyKta3IYSU6J/ma1t4 GciTBImXGdHvV1aer49liNMFoXbiAxE5vH4jkIBmZ89zuGp2uOQJgcRNx4XMc/OJ aa4yhmwGW3guWcEJLNFkbm+IzhFTxtMSGu+dnm+YyZf/2Kgjp8VjnPr8mHSCWO3A OBnOeyOUV8JZkKZMUyF2IYEgHpUmxbuTWPnFmfADaGWHvNLsjevG+B3rq8z0tdSN P3D+tjpEYbyxdqkuOJKZfxztBrd1w9VWtxIrHkMvO+ZInZLhc054WtkzcPa66Vkx ibzLJcmJNmR4Gr3Af7jmod6UqqPpjSTA69bapjgnXoiDeAJNErcg+zi97yxSGNyr tIcAiAfsgR3mTxHASrl0 =CdoE -----END PGP SIGNATURE----- --Apple-Mail=_59A88BB9-9C87-4825-AEDF-140167B9CD0A-- From nobody Thu Aug 21 07:54:46 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF091A03CA for ; Thu, 21 Aug 2014 07:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.669 X-Spam-Level: X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niDvx566YcF8 for ; Thu, 21 Aug 2014 07:54:42 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D611F1A038F for ; Thu, 21 Aug 2014 07:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408632881; x=1440168881; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=eVnRibTVAgP39a24IDwwuF+Mxol+H0VkGsCHS20N7is=; b=YZrIdp0AcwHpoPtAPKJ2nw6qCVR+2U6LnI5O0sGbWKuG4b5U8kMeVjqp MXkAIS5C6DYsL6is4XIYjyankl3Fhk1K7Vo3B1BiDOsNZPKi4Dln9Ia4M HSqFYPlPxTtHz8c5bSZUDniizwgLXcoAxT6CLHW+N7RkSD2Sd57EWrgab Y=; X-IronPort-AV: E=McAfee;i="5600,1067,7536"; a="72654012" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 21 Aug 2014 07:54:41 -0700 X-IronPort-AV: E=Sophos;i="5.01,909,1400050800"; d="scan'208";a="789206069" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Aug 2014 07:54:41 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 21 Aug 2014 07:54:41 -0700 Message-ID: <53F60830.3020506@qti.qualcomm.com> Date: Thu, 21 Aug 2014 09:54:40 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: X-Priority: 2 (High) Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/Rm-Ru-ctNh64IQ8M5yBw9_95oSo Subject: [paws] Please review IPR disclosure https://datatracker.ietf.org/ipr/2340/ X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 14:54:44 -0000 PAWS participants: Somehow an IPR disclosure was filed on the PAWS protocol document for which we did not see an announcement: https://datatracker.ietf.org/ipr/2340/ As far as I can tell from the title (given that the referenced IP is an as-yet-unpublished patent), this applies to the database discovery portion of the protocol. Since we have removed much of that discussion, we expect mostly pre-configuration, and we have yet to (and may never) complete the actual database discovery work, I think this may have no effect on folks implementing the protocol. But I do need to confirm that the WG is aware of this and still thinks it's OK to move forward with the protocol document. If there are any objections to moving forward, I need to hear that immediately. However, I would like to hear an overt, "Yes, understood, and it's fine to move forward" from some folks who might be implementing the protocol. Thanks, pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Aug 21 08:05:09 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F4B1A047B; Thu, 21 Aug 2014 08:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.668 X-Spam-Level: X-Spam-Status: No, score=-7.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41ax1ChZtKYv; Thu, 21 Aug 2014 08:04:47 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48AA11A8973; Thu, 21 Aug 2014 08:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408633468; x=1440169468; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=l9fHpdXVg+O6eZITOP7lztXDRdpLRtC5Bx1DCaBGugc=; b=M0p1n2fbh8f7FcikyLo+VdS6TMk9B6MuyePJE1uY150w1UiMAVZTNdrQ mlxN/AqnBBHFbEfxAfmMIMZm54gWsQnCbjl7E0D4VAGMtX4YQ1yA67GGo my2j1njErVbmQ5Rs51XBEJmEn7KVa3Ph2yu9Yw7l0nvbKWwnI2UiGcdep A=; X-IronPort-AV: E=McAfee;i="5600,1067,7536"; a="72654489" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 21 Aug 2014 08:04:27 -0700 X-IronPort-AV: E=Sophos;i="5.01,909,1400050800"; d="scan'208,217";a="695868941" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Aug 2014 08:04:26 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 21 Aug 2014 08:04:26 -0700 Message-ID: <53F60A78.9010406@qti.qualcomm.com> Date: Thu, 21 Aug 2014 10:04:24 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Vincent Chen References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090606070608050608090307" X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/ul_CW6TRO8Mr4uSzOGqm9Tu2A3U Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 15:04:54 -0000 --------------090606070608050608090307 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 8/21/14 2:59 AM, Vincent Chen wrote: > > = Section 4.5 = > These two sentences seem to contradict each other: > > "The device identifier, capabilities, and characteristics > communicated in the AVAIL_SPECTRUM_REQ message MUST be those of the > Slave Device, but the location MUST be that of the Master Device." > > > Ouch! I'll fix that. "... location MUST be that of the Slave Device." > Do we have any idea how that got in there in the first place? That seems like it was a conscious decision, and I want to make sure we're not missing something. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------090606070608050608090307 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 8/21/14 2:59 AM, Vincent Chen wrote:
= Section 4.5 =
These two sentences seem to contradict each other:

"The device identifier, capabilities, and characteristics
   communicated in the AVAIL_SPECTRUM_REQ message MUST be those of the
   Slave Device, but the location MUST be that of the Master Device."

Ouch! I'll fix that. "... location MUST be that of the Slave Device." 

Do we have any idea how that got in there in the first place? That seems like it was a conscious decision, and I want to make sure we're not missing something.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------090606070608050608090307-- From nobody Thu Aug 21 08:59:57 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1001A03FE; Thu, 21 Aug 2014 08:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.668 X-Spam-Level: X-Spam-Status: No, score=-7.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jy6_h2-3H-_u; Thu, 21 Aug 2014 08:59:41 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E4D1A037E; Thu, 21 Aug 2014 08:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1408636781; x=1440172781; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Exm+TGPqrngpaqNPjC+rLINE1dnyViUHKklDThHy79A=; b=Q7X7AZSdOUdD4fcEyEm0UWU7gQqg9YfGLj1aHduWn361oyCTaJxkROBT PiNrSp2ObgRzrXEOPJyMHUthvZAADiZ4tEYhcIQ0ZpKcZjext/MtJ4fH6 jTTjDOhk7Ch2JdPMuNRV28eGPaWSPLq+vlJMOAPuJ5gsVsl26SxmdxICb 0=; X-IronPort-AV: E=McAfee;i="5600,1067,7536"; a="151100492" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 21 Aug 2014 08:59:40 -0700 X-IronPort-AV: E=Sophos;i="5.01,909,1400050800"; d="scan'208,217";a="695892734" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Aug 2014 08:59:39 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 21 Aug 2014 08:59:39 -0700 Message-ID: <53F61768.7030007@qti.qualcomm.com> Date: Thu, 21 Aug 2014 10:59:36 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Vincent Chen References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090700000409000106020000" X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/7mmV3-F7lg2SMUHqMFnI3dwzT1Y Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 15:59:45 -0000 --------------090700000409000106020000 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 8/21/14 2:59 AM, Vincent Chen wrote: > > = Section 5.2 = > I'd like to discuss why the device serial number needs to be > included in > the device descriptor, rather than some (perhaps persistent) randomly > generated device identifier that is used only in the context of this > protocol (which would better protect the privacy of the user of the > device, since the whitespaces database administrator wouldn't be > able to > correlate the device's spectrum requests with other activities > linked to > the serial number). It's not really clear why serial number is > collected > since both this document and RFC 6953 note the protocol does not > defend > against abuse or mis-use of spectrum. > > > The regulator want to have the ability to black list ranges of serial > numbers, if it > determines that a series was defective. The Databases must use the > serial number > to determine it can return available spectrum. But that makes this a "required by ruleset but not by protocol" issue, right? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------090700000409000106020000 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 8/21/14 2:59 AM, Vincent Chen wrote:
= Section 5.2 =
I'd like to discuss why the device serial number needs to be included in
the device descriptor, rather than some (perhaps persistent) randomly
generated device identifier that is used only in the context of this
protocol (which would better protect the privacy of the user of the
device, since the whitespaces database administrator wouldn't be able to
correlate the device's spectrum requests with other activities linked to
the serial number). It's not really clear why serial number is collected
since both this document and RFC 6953 note the protocol does not defend
against abuse or mis-use of spectrum.

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

But that makes this a "required by ruleset but not by protocol" issue, right?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------090700000409000106020000-- From nobody Thu Aug 21 09:34:47 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4981A0AF0; Wed, 20 Aug 2014 13:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tZFiItyl72V; Wed, 20 Aug 2014 13:31:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C20431A0B0E; Wed, 20 Aug 2014 13:31:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820203127.25270.64032.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 13:31:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/2HxfQN4Ly_o-Hw2Uv07OS0r7s-w X-Mailman-Approved-At: Thu, 21 Aug 2014 09:34:43 -0700 Cc: paws@ietf.org, paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org Subject: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 20:31:29 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-paws-protocol-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for doing this work, the draft looks good and my discuss should be easy enough to address as I am just looking for some clarifying information that may be helpful if I didn't miss the answer somewhere else. Can clients query any database entries or is the interface restricted to the list of supported interactions? I assume the answer is that it is limited to the set of database interactions defined, but could not find any statement saying that in this draft or the prior requirements in RFC6953. Authentication is only a MAY in the Security Considerations Section, which raises another possible concern for me. Since clients can get back pretty much all of the defined datatypes (DeviceDescriptor is one example) and authentication is not required, there should be a discussion on the risks of revealing this information for both the privacy reasons Stephen and Alissa outlined as well as possible security concerns. I think this should be on a field basis in terms of sensitive elements where relevant. I could see how you might want/need the types of information gathered within an administrative domain or accessed by a restricted set of users, but revealing data like what is contained in deviceDescriptor (includes model) as well as sensitive fields in other classes (AntennaCharacteristics) seems like a risk as it could be used in targeted attacks if there are known vulnerabilities to those devices. The attacks could target specific regions at specific times to effect events or to be used as part of some larger attack (could include physical). This may sound crazy, but layered attacks are very real. Is there anything that prevents a client from fingerprinting? Perhaps recommendations at the field level would help implementors understand these risks (privacy & security) and then they may be more motivated to enable authenticated and encrypted access. This wouldn't be necessary for all fields, just the ones that could be used in attacks or reveal privacy related information. Implementers may take the optional field use more seriously or create options in application interfaces so that users are then aware of the risks with these fields and make different choices. Ideally, there would be a limited set of data returned based on role information so that devices or other clients only get what they need as opposed to what is available. I didn't see any mention of restrictions on who could access what (role based access), is that possible? I'm not sure if the primary & secondary users allow for this? Thanks in advance. From nobody Thu Aug 21 09:34:48 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C9D1A6EF3; Wed, 20 Aug 2014 14:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZL95hu1yU3HU; Wed, 20 Aug 2014 14:26:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A16E51A0BE8; Wed, 20 Aug 2014 14:26:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820212615.5267.85995.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 14:26:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/-FzaiG67PaTD5jdimbsZvPHK7Qw X-Mailman-Approved-At: Thu, 21 Aug 2014 09:34:44 -0700 Cc: paws@ietf.org, paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org Subject: [paws] Alia Atlas' No Objection on draft-ietf-paws-protocol-14: (with COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 21:26:17 -0000 Alia Atlas has entered the following ballot position for draft-ietf-paws-protocol-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Alissa's discuss - clarifying what is in the location, privacy around why point is required, and other privacy concerns. From nobody Thu Aug 21 09:34:49 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BB91A6F01; Wed, 20 Aug 2014 15:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAy4kE5TR6jJ; Wed, 20 Aug 2014 15:09:16 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458E81A88F8; Wed, 20 Aug 2014 15:09:15 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id 10so7455563lbg.12 for ; Wed, 20 Aug 2014 15:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a1FjUbc34r9H4wc4Vui6LoH4TBp91ym9EnDadu+A28c=; b=0yLhaCDfDDL2zGNgvyhldGlaUZMCT6AYx7bfqcTSCpMngFWdZJQ0FNxzI3IIrFB5PU htXyAT3hOyLCPt05Zq658dUPDxuqNzF6nN0R1SUTeyfh1/WeTSsaRJRgJ+x/FPUcQpbQ aRbAWXZ0u9sqDA/TNmv19RcwGUUFJRq5F3Q4pEx03aV1RocUAfTwS+YutKIppEVhZvsE ybYGen0SlQ7MOVaHBsr+zKNyNostWppqly1hjL3ojDCTW5PRUAOFx8RLlr5o+AN+wAUK p1Oism2+dhbvnOmhXv1Tvq+MZ/iv2nVWTw/b3WX30a2hsc2ea/vWTkz4E+HD+kisNv1o R5fw== MIME-Version: 1.0 X-Received: by 10.112.219.234 with SMTP id pr10mr41453530lbc.59.1408572552511; Wed, 20 Aug 2014 15:09:12 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Wed, 20 Aug 2014 15:09:12 -0700 (PDT) In-Reply-To: <53F50D2D.2010203@qti.qualcomm.com> References: <20140820203127.25270.64032.idtracker@ietfa.amsl.com> <53F50D2D.2010203@qti.qualcomm.com> Date: Wed, 20 Aug 2014 18:09:12 -0400 Message-ID: From: Kathleen Moriarty To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11c25eb2a206a1050116da76 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/L0WB4XLKtmXFNlU4glPLNmrnL8g X-Mailman-Approved-At: Thu, 21 Aug 2014 09:34:43 -0700 Cc: paws@ietf.org, paws-chairs@tools.ietf.org, The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 22:09:22 -0000 --001a11c25eb2a206a1050116da76 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 20, 2014 at 5:03 PM, Pete Resnick wrote: > On 8/20/14 3:31 PM, Kathleen Moriarty wrote: > >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> [...] >> >> Can clients query any database entries or is the interface restricted to >> the list of supported interactions? I assume the answer is that it is >> limited to the set of database interactions defined, but could not find >> any statement saying that in this draft or the prior requirements in >> RFC6953. >> >> > > I'm not sure exactly what you mean here. Are you asking whether the client > or server ask for/send back more than the minimum data? Sure, that's what > the "*other" business is about. Or are you asking whether additional > queries/responses can be defined? I suppose they could. But I'm not sure > what you're asking, or what the concern is. Can you elaborate? There wasn't an explicit statement that you need to define new query/responses through extensions, so that coupled with the possibility of unauthenticated sessions had me worrying that more data could be exposed then intended. A statement in the security considerations section (maybe) after the MAY for authentication that helps state the limitation of the interface to this and approved extensions would help. The risk would be additional query/responses that let you get at more data than was intended (some of the privacy related information or fingerprinting possibilities would be the concern. Earlier in the draft it sounds as if authentication is required until you get to that statement towards the end of the security considerations section. > > > Authentication is only a MAY in the Security Considerations Section, >> which raises another possible concern for me. >> >> Since clients can get back pretty much all of the defined datatypes >> (DeviceDescriptor is one example) >> > > The client only gets back the DeviceDescriptor that it sent to the server > in the request so that the client can match the response to the query. > > Sorry, I missed that very important point in the query/response description somehow. > > and authentication is not required, >> there should be a discussion on the risks of revealing this information >> for both the privacy reasons Stephen and Alissa outlined as well as >> possible security concerns. I think this should be on a field basis in >> terms of sensitive elements where relevant. >> >> > > The rest of the responses are the publicly available spectrum information. > I'm not seeing sensitive data there. > > Yep, for the current queries, I missed that you were only getting the response that included the DeviceDescriptor information you sent. Sorry about that! > > I could see how you might want/need the types of information gathered >> within an administrative domain or accessed by a restricted set of users, >> but revealing data like what is contained in deviceDescriptor (includes >> model) as well as sensitive fields in other classes >> (AntennaCharacteristics) seems like a risk as it could be used in >> targeted attacks if there are known vulnerabilities to those devices. >> The attacks could target specific regions at specific times to effect >> events or to be used as part of some larger attack (could include >> physical). This may sound crazy, but layered attacks are very real. >> >> > > This seems like it would be a problem for sniffing unencrypted data *from* > another client, but I'm not getting how this sort of attack works by a > client owned by the attacker querying the database. > This is just the kind of thing you might be able to do with the full set of info. I think just responding on the first item would be good enough as I missed an important point. > > Before I get back to the rest of your query, help me understand this far. Thank you! > > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > -- Best regards, Kathleen --001a11c25eb2a206a1050116da76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Aug 20, 2014 at 5:03 PM, Pete Resnick <= ;presnick@qt= i.qualcomm.com> wrote:
On 8/20/14 3:31 PM, Kathleen Moriarty wrote:=
-------------------------------------------------------------= ---------
DISCUSS:
-------------------------------------------------------------= ---------
[...]

Can clients query any database entries or is the interface restricted to the list of supported interactions?=C2=A0 =C2=A0I assume the answer is that= it is
limited to the set of database interactions defined, but could not find
any statement saying that in this draft or the prior requirements in
RFC6953.
=C2=A0 =C2=A0

I'm not sure exactly what you mean here. Are you asking whether the cli= ent or server ask for/send back more than the minimum data? Sure, that'= s what the "*other" business is about. Or are you asking whether = additional queries/responses can be defined? I suppose they could. But I= 9;m not sure what you're asking, or what the concern is. Can you elabor= ate?

There wasn't an explicit statement that you need to= define new query/responses through extensions, so that coupled with the po= ssibility of unauthenticated sessions had me worrying that more data could = be exposed then intended. =C2=A0A statement in the security considerations = section (maybe) after the MAY for authentication that helps state the limit= ation of the interface to this and approved extensions would help. =C2=A0Th= e risk would be additional query/responses that let you get at more data th= an was intended (some of the privacy related information or fingerprinting = possibilities would be the concern.=C2=A0

Earlier in the draft it sounds as if authentication is = required until you get to that statement towards the end of the security co= nsiderations section.


Authentication is only a MAY in the Security Considerations Section,
which raises another possible concern for me.

Since clients can get back pretty much all of the defined datatypes
(DeviceDescriptor is one example)

The client only gets back the DeviceDescriptor that it sent to the server i= n the request so that the client can match the response to the query.

Sorry, I missed that very important p= oint in the query/response description somehow.
=C2=A0

and authentication is not required,
there should be a discussion on the risks of revealing this information
for both the privacy reasons Stephen and Alissa outlined as well as
possible security concerns.=C2=A0 I think this should be on a field basis i= n
terms of sensitive elements where relevant.
=C2=A0 =C2=A0

The rest of the responses are the publicly available spectrum information. = I'm not seeing sensitive data there.

Yep, for the current queries, I missed that you were only getting = the response that included the DeviceDescriptor information you sent. =C2= =A0Sorry about that!=C2=A0

I could see how you might want/need the types of information gathered
within an administrative domain or accessed by a restricted set of users, but revealing data like what is contained in deviceDescriptor (includes
model) as well as sensitive fields in other classes
(AntennaCharacteristics) seems like a risk as it could be used in
targeted attacks if there are known vulnerabilities to those devices.
The attacks could target specific regions at specific times to effect
events or to be used as part of some larger attack (could include
physical).=C2=A0 This may sound crazy, but layered attacks are very real. =C2=A0 =C2=A0

This seems like it would be a problem for sniffing unencrypted data *from* = another client, but I'm not getting how this sort of attack works by a = client owned by the attacker querying the database.
This is just the kind of thing you might be able to do with the full set of= info. =C2=A0I think just responding on the first item would be good enough= as I missed an important point.=C2=A0

Before I get back to the rest of your query, help me understand this far.

Thank you!=C2=A0


pr

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




--

Best regards,
Kathleen
--001a11c25eb2a206a1050116da76-- From nobody Thu Aug 21 09:34:50 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A481A6F7A; Thu, 21 Aug 2014 05:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQEyND--plZV; Thu, 21 Aug 2014 05:05:10 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777241A6F73; Thu, 21 Aug 2014 05:05:09 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id c11so7962570lbj.23 for ; Thu, 21 Aug 2014 05:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6wk3HbDKDgEZqRWK7b8xv+xVNjBJMeSG8BSSGydmC3g=; b=LbkS1T5yyY9g77z/vSnO8QBfsJT4hNt1C9J+CusU7TmbUK5DdM89qFAgAt3A3sAl8e aTe8M8aZgcY7n+Hr3jnniAd2lj42zSL6JJ6PiEymF4FuKPm+1GyU1xPhS0UEyxNG/9iD 6MeEzQlIpYBkx2OGVw22k62ndVVkR28b/nnw/MjFO+nHpdicX0Q480/FZ47fZgBfuTty YnF71pU1tpHsloEnSWcaqvY/G8QlHguaIk9Yv0pEPTe4mhvAixNZd9JaE2iU9aFAUGQS hTkDDtxE3x2YJMvuJmBQVhtQaDb/1Hve2OdgkxDUHwi7EjQtwm2K6HorzAh/p/dNR16i AhtQ== MIME-Version: 1.0 X-Received: by 10.112.189.97 with SMTP id gh1mr27135428lbc.40.1408622707731; Thu, 21 Aug 2014 05:05:07 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Thu, 21 Aug 2014 05:05:07 -0700 (PDT) In-Reply-To: References: <20140820203127.25270.64032.idtracker@ietfa.amsl.com> <53F50D2D.2010203@qti.qualcomm.com> Date: Thu, 21 Aug 2014 08:05:07 -0400 Message-ID: From: Kathleen Moriarty To: Vincent Chen Content-Type: multipart/alternative; boundary=001a11c36fd21df553050122888f Archived-At: http://mailarchive.ietf.org/arch/msg/paws/hGhhoL5gi86VzUw2__GG9vWVLiM X-Mailman-Approved-At: Thu, 21 Aug 2014 09:34:43 -0700 Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , Pete Resnick , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 12:05:13 -0000 --001a11c36fd21df553050122888f Content-Type: text/plain; charset=UTF-8 On Thu, Aug 21, 2014 at 4:15 AM, Vincent Chen wrote: > Thanks to Pete for responding. > > Additional comments inline. > > > On Wed, Aug 20, 2014 at 3:09 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> >> >> >> On Wed, Aug 20, 2014 at 5:03 PM, Pete Resnick >> wrote: >> >>> On 8/20/14 3:31 PM, Kathleen Moriarty wrote: >>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> [...] >>>> >>>> Can clients query any database entries or is the interface restricted to >>>> the list of supported interactions? I assume the answer is that it is >>>> limited to the set of database interactions defined, but could not find >>>> any statement saying that in this draft or the prior requirements in >>>> RFC6953. >>>> >>>> >>> >>> I'm not sure exactly what you mean here. Are you asking whether the >>> client or server ask for/send back more than the minimum data? Sure, that's >>> what the "*other" business is about. Or are you asking whether additional >>> queries/responses can be defined? I suppose they could. But I'm not sure >>> what you're asking, or what the concern is. Can you elaborate? >> >> >> There wasn't an explicit statement that you need to define new >> query/responses through extensions, so that coupled with the possibility of >> unauthenticated sessions had me worrying that more data could be exposed >> then intended. A statement in the security considerations section (maybe) >> after the MAY for authentication that helps state the limitation of the >> interface to this and approved extensions would help. The risk would be >> additional query/responses that let you get at more data than was intended >> (some of the privacy related information or fingerprinting possibilities >> would be the concern. >> > > The security considerations section started by saying that the Database > provides > available spectrum information, which is public information. Nothing else > can be retrieved > from the Database. > > Does Pete's point about the DeviceDescriptor being an echo of the request > also resolve this > concern? > > >> >> Earlier in the draft it sounds as if authentication is required until you >> get to that statement towards the end of the security considerations >> section. >> > > NOTE: Since the Database returns the same available-spectrum answer for > the same combination of (device type, location), regardless of what > requests came before or after, authentication of the client seems to add > little benefit. I.e., spoofing by rogue devices does not impact the answer > given to well-behaved devices. > Yes, Pete's point on DeviceDescriptor did help with some of my concerns and sorry that I somehow missed it on my first read of the draft. I'm not asking for authentication to be required, so maybe that was misunderstood. I didn't see anywhere a statement that extensions to this interface have to be defined and should consider this premise information (authentication is not required and the larger database does contain information that could be used for profiling the overall system or fingerprinting devices. Although, watching the other discusses, some of the requirements on fields are changing a bit and maybe the concerns are lowering as a result, but we'll have to see where that winds up. I understand that the current interface limits what can be retrieved. In some other protocols, I've seen an informational statement to ensure those writing extensions are cognizant of the reasons for the limitations imposed. It looks like you have done a pretty good job on it and I was hoping to see a statement on the limitations for the purpose of possible extensions in the future following the patterns. I don't think I saw them spelled out in the requirements RFC. Thanks, Kathleen > > > >> >>> >>> Authentication is only a MAY in the Security Considerations Section, >>>> which raises another possible concern for me. >>>> >>>> Since clients can get back pretty much all of the defined datatypes >>>> (DeviceDescriptor is one example) >>>> >>> >>> The client only gets back the DeviceDescriptor that it sent to the >>> server in the request so that the client can match the response to the >>> query. >>> >>> Sorry, I missed that very important point in the query/response >> description somehow. >> >> >>> >>> and authentication is not required, >>>> there should be a discussion on the risks of revealing this information >>>> for both the privacy reasons Stephen and Alissa outlined as well as >>>> possible security concerns. I think this should be on a field basis in >>>> terms of sensitive elements where relevant. >>>> >>>> >>> >>> The rest of the responses are the publicly available spectrum >>> information. I'm not seeing sensitive data there. >>> >>> Yep, for the current queries, I missed that you were only getting the >> response that included the DeviceDescriptor information you sent. Sorry >> about that! >> >>> >>> I could see how you might want/need the types of information gathered >>>> within an administrative domain or accessed by a restricted set of >>>> users, >>>> but revealing data like what is contained in deviceDescriptor (includes >>>> model) as well as sensitive fields in other classes >>>> (AntennaCharacteristics) seems like a risk as it could be used in >>>> targeted attacks if there are known vulnerabilities to those devices. >>>> The attacks could target specific regions at specific times to effect >>>> events or to be used as part of some larger attack (could include >>>> physical). This may sound crazy, but layered attacks are very real. >>>> >>>> >>> >>> This seems like it would be a problem for sniffing unencrypted data >>> *from* another client, but I'm not getting how this sort of attack works by >>> a client owned by the attacker querying the database. >>> >> This is just the kind of thing you might be able to do with the full set >> of info. I think just responding on the first item would be good enough as >> I missed an important point. >> >>> >>> Before I get back to the rest of your query, help me understand this far. >> >> >> Thank you! >> >>> >>> >>> pr >>> >>> -- >>> Pete Resnick >>> Qualcomm Technologies, Inc. - +1 (858)651-4478 >>> >>> >> >> >> -- >> >> Best regards, >> Kathleen >> > > > > -- > -vince > -- Best regards, Kathleen --001a11c36fd21df553050122888f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 21, 2014 at 4:15 AM, Vincent Chen <= ;vchen@google.com= > wrote:
Thanks to Pete for respondi= ng.

Additional comments inline.


On Wed, Aug 20, 2014 at = 3:09 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.co= m> wrote:



On Wed, Aug 20, 2014 at 5:03 PM= , Pete Resnick <presnick@qti.qualcomm.com> wrote:
On 8/20/14 3:31 PM, Kathleen Moriarty wrote:=
-------------------------------------------------------------= ---------
DISCUSS:
-------------------------------------------------------------= ---------
[...]

Can clients query any database entries or is the interface restricted to the list of supported interactions?=C2=A0 =C2=A0I assume the answer is that= it is
limited to the set of database interactions defined, but could not find
any statement saying that in this draft or the prior requirements in
RFC6953.
=C2=A0 =C2=A0

I'm not sure exactly what you mean here. Are you asking whether the cli= ent or server ask for/send back more than the minimum data? Sure, that'= s what the "*other" business is about. Or are you asking whether = additional queries/responses can be defined? I suppose they could. But I= 9;m not sure what you're asking, or what the concern is. Can you elabor= ate?

There wasn't an explicit statement that you n= eed to define new query/responses through extensions, so that coupled with = the possibility of unauthenticated sessions had me worrying that more data = could be exposed then intended. =C2=A0A statement in the security considera= tions section (maybe) after the MAY for authentication that helps state the= limitation of the interface to this and approved extensions would help. = =C2=A0The risk would be additional query/responses that let you get at more= data than was intended (some of the privacy related information or fingerp= rinting possibilities would be the concern.=C2=A0

The security consi= derations section started by saying that the Database provides
av= ailable spectrum information, which is public information. Nothing else can= be retrieved
from the Database.

Does Pete's point abou= t the DeviceDescriptor being an echo of the request also resolve this
=
concern?
=C2=A0

Earlier in the draft it sounds as if authentication is = required until you get to that statement towards the end of the security co= nsiderations section.

NOTE: Since the Database returns the same available-spectrum ans= wer for the same combination of (device type, location), regardless of what= requests came before or after, authentication of the client seems to add l= ittle benefit. I.e., spoofing by rogue devices does not impact the answer g= iven to well-behaved devices.

Yes, Pete's point on= DeviceDescriptor did help with some of my concerns and sorry that I someho= w missed it on my first read of the draft. =C2=A0 I'm not asking for au= thentication to be required, so maybe that was misunderstood. =C2=A0I didn&= #39;t see anywhere a statement that extensions to this interface have to be= defined and should consider this premise information (authentication is no= t required and the larger database does contain information that could be u= sed for profiling the overall system or fingerprinting devices. =C2=A0Altho= ugh, watching the other discusses, some of the requirements on fields are c= hanging a bit and maybe the concerns are lowering as a result, but we'l= l have to see where that winds up. =C2=A0I understand that the current inte= rface limits what can be retrieved. =C2=A0In some other protocols, I've= seen an informational statement to ensure those writing extensions are cog= nizant of the reasons for the limitations imposed. =C2=A0It looks like you = have done a pretty good job on it and I was hoping to see a statement on th= e limitations for the purpose of possible extensions in the future followin= g the patterns. =C2=A0I don't think I saw them spelled out in the requi= rements RFC.

Thanks,
Kathleen

=C2=A0


Authentication is only a MAY in the Security Considerations Section,
which raises another possible concern for me.

Since clients can get back pretty much all of the defined datatypes
(DeviceDescriptor is one example)

The client only gets back the DeviceDescriptor that it sent to the server i= n the request so that the client can match the response to the query.
<= br>
Sorry, I missed that very important point = in the query/response description somehow.
=C2=A0

and authentication is not required,
there should be a discussion on the risks of revealing this information
for both the privacy reasons Stephen and Alissa outlined as well as
possible security concerns.=C2=A0 I think this should be on a field basis i= n
terms of sensitive elements where relevant.
=C2=A0 =C2=A0

The rest of the responses are the publicly available spectrum information. = I'm not seeing sensitive data there.

<= div>Yep, for the current queries, I missed that you were only getting the r= esponse that included the DeviceDescriptor information you sent. =C2=A0Sorr= y about that!=C2=A0

I could see how you might want/need the types of information gathered
within an administrative domain or accessed by a restricted set of users, but revealing data like what is contained in deviceDescriptor (includes
model) as well as sensitive fields in other classes
(AntennaCharacteristics) seems like a risk as it could be used in
targeted attacks if there are known vulnerabilities to those devices.
The attacks could target specific regions at specific times to effect
events or to be used as part of some larger attack (could include
physical).=C2=A0 This may sound crazy, but layered attacks are very real. =C2=A0 =C2=A0

This seems like it would be a problem for sniffing unencrypted data *from* = another client, but I'm not getting how this sort of attack works by a = client owned by the attacker querying the database.
This is just the kind of thing you might be able to do with the full set of= info. =C2=A0I think just responding on the first item would be good enough= as I missed an important point.=C2=A0

Before I get back to the rest of your query, help me understand this far.

Thank you!=C2=A0


pr

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



--

Best regard= s,
Kathleen



--
-vince


--

Best regards,
Kathleen
--001a11c36fd21df553050122888f-- From nobody Thu Aug 21 09:34:51 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035B41A041F; Thu, 21 Aug 2014 08:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4APsVvKmrivl; Thu, 21 Aug 2014 08:13:15 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371A71A00C6; Thu, 21 Aug 2014 08:13:13 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id l4so8260508lbv.1 for ; Thu, 21 Aug 2014 08:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UCi2wGJHlWAfqFvNipYLO4sCgk2SO+oivhOXNDVcqCc=; b=ZYQKusuKZLUFvyjwDbxzXQIaeSgz8LvO8+JdQFkNx8swbabzSj3uMF1LN7K8qNJfqQ ZFDBHKnhp7K7ESAXNIqNVL/iiY48GhIa0jdQeIGwZeIIoupwHJrRV87R2cZp369T2CJZ JXMf12otKaIVuVj+vj7BbgZpnyKKdC/YGu4UBOMhI2W2Euw230Z2eH3GP0mENwC7Ypgj TR9JFF8XGbkLLYp09Tfr+u/4XwMhZWXw3Z2uEBCEVywAYW3bCZ13yvxMrq+Iicg6YfYV fxwHmNGYelw+ZLWQbmyEiz2i0m859LxqdTOw8jM083nO1YBdS6SUxmh517AM/g84hAe7 4FnA== MIME-Version: 1.0 X-Received: by 10.152.4.39 with SMTP id h7mr49784216lah.49.1408633992380; Thu, 21 Aug 2014 08:13:12 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Thu, 21 Aug 2014 08:13:12 -0700 (PDT) In-Reply-To: References: <20140820203127.25270.64032.idtracker@ietfa.amsl.com> <53F50D2D.2010203@qti.qualcomm.com> Date: Thu, 21 Aug 2014 11:13:12 -0400 Message-ID: From: Kathleen Moriarty To: Vincent Chen Content-Type: multipart/alternative; boundary=089e013d1c46bc0ade05012528f7 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/Puc3UlbTR_aXtrmXian9j8E-fxs X-Mailman-Approved-At: Thu, 21 Aug 2014 09:34:44 -0700 Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , Pete Resnick , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 15:13:18 -0000 --089e013d1c46bc0ade05012528f7 Content-Type: text/plain; charset=UTF-8 Chatted a bit with Pete and he sees the point we are down to now. To be clear, I think we are down to a comment and would just like to finish up the discussion and then I'll update the tracker since we are close here. On Thu, Aug 21, 2014 at 8:05 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > > > > On Thu, Aug 21, 2014 at 4:15 AM, Vincent Chen wrote: > >> Thanks to Pete for responding. >> >> Additional comments inline. >> >> >> On Wed, Aug 20, 2014 at 3:09 PM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >>> >>> >>> >>> On Wed, Aug 20, 2014 at 5:03 PM, Pete Resnick >> > wrote: >>> >>>> On 8/20/14 3:31 PM, Kathleen Moriarty wrote: >>>> >>>>> ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> ---------------------------------------------------------------------- >>>>> [...] >>>>> >>>>> Can clients query any database entries or is the interface restricted >>>>> to >>>>> the list of supported interactions? I assume the answer is that it is >>>>> limited to the set of database interactions defined, but could not find >>>>> any statement saying that in this draft or the prior requirements in >>>>> RFC6953. >>>>> >>>>> >>>> >>>> I'm not sure exactly what you mean here. Are you asking whether the >>>> client or server ask for/send back more than the minimum data? Sure, that's >>>> what the "*other" business is about. Or are you asking whether additional >>>> queries/responses can be defined? I suppose they could. But I'm not sure >>>> what you're asking, or what the concern is. Can you elaborate? >>> >>> >>> There wasn't an explicit statement that you need to define new >>> query/responses through extensions, so that coupled with the possibility of >>> unauthenticated sessions had me worrying that more data could be exposed >>> then intended. A statement in the security considerations section (maybe) >>> after the MAY for authentication that helps state the limitation of the >>> interface to this and approved extensions would help. The risk would be >>> additional query/responses that let you get at more data than was intended >>> (some of the privacy related information or fingerprinting possibilities >>> would be the concern. >>> >> >> The security considerations section started by saying that the Database >> provides >> available spectrum information, which is public information. Nothing else >> can be retrieved >> from the Database. >> > I don't see this text, can you point it out? I may be missing it, but would have expected it as one of the listed protection steps in section 10 or maybe as part of 10.1. I really think what I am looking for should have been in the requirements document for the protocol and any extensions. With an assumption that only public information will be provided over the unauthenticated sessions, limiting the scope of access to public information access through the defined interface (which you are doing) would be good to close out with a statement to that requirement. Since I think this does really belong in the prior document, but could go here, I will consider this at the comment level and would appreciate it if you could point out where I might be missing text that only public information is available through the defined interface. Thank you! >> Does Pete's point about the DeviceDescriptor being an echo of the request >> also resolve this >> concern? >> >> >>> >>> Earlier in the draft it sounds as if authentication is required until >>> you get to that statement towards the end of the security considerations >>> section. >>> >> >> NOTE: Since the Database returns the same available-spectrum answer for >> the same combination of (device type, location), regardless of what >> requests came before or after, authentication of the client seems to add >> little benefit. I.e., spoofing by rogue devices does not impact the answer >> given to well-behaved devices. >> > > Yes, Pete's point on DeviceDescriptor did help with some of my concerns > and sorry that I somehow missed it on my first read of the draft. I'm not > asking for authentication to be required, so maybe that was misunderstood. > I didn't see anywhere a statement that extensions to this interface have > to be defined and should consider this premise information (authentication > is not required and the larger database does contain information that could > be used for profiling the overall system or fingerprinting devices. > Although, watching the other discusses, some of the requirements on fields > are changing a bit and maybe the concerns are lowering as a result, but > we'll have to see where that winds up. I understand that the current > interface limits what can be retrieved. In some other protocols, I've seen > an informational statement to ensure those writing extensions are cognizant > of the reasons for the limitations imposed. It looks like you have done a > pretty good job on it and I was hoping to see a statement on the > limitations for the purpose of possible extensions in the future following > the patterns. I don't think I saw them spelled out in the requirements RFC. > > Thanks, > Kathleen > >> >> >> >>> >>>> >>>> Authentication is only a MAY in the Security Considerations Section, >>>>> which raises another possible concern for me. >>>>> >>>>> Since clients can get back pretty much all of the defined datatypes >>>>> (DeviceDescriptor is one example) >>>>> >>>> >>>> The client only gets back the DeviceDescriptor that it sent to the >>>> server in the request so that the client can match the response to the >>>> query. >>>> >>>> Sorry, I missed that very important point in the query/response >>> description somehow. >>> >>> >>>> >>>> and authentication is not required, >>>>> there should be a discussion on the risks of revealing this information >>>>> for both the privacy reasons Stephen and Alissa outlined as well as >>>>> possible security concerns. I think this should be on a field basis in >>>>> terms of sensitive elements where relevant. >>>>> >>>>> >>>> >>>> The rest of the responses are the publicly available spectrum >>>> information. I'm not seeing sensitive data there. >>>> >>>> Yep, for the current queries, I missed that you were only getting the >>> response that included the DeviceDescriptor information you sent. Sorry >>> about that! >>> >>>> >>>> I could see how you might want/need the types of information gathered >>>>> within an administrative domain or accessed by a restricted set of >>>>> users, >>>>> but revealing data like what is contained in deviceDescriptor (includes >>>>> model) as well as sensitive fields in other classes >>>>> (AntennaCharacteristics) seems like a risk as it could be used in >>>>> targeted attacks if there are known vulnerabilities to those devices. >>>>> The attacks could target specific regions at specific times to effect >>>>> events or to be used as part of some larger attack (could include >>>>> physical). This may sound crazy, but layered attacks are very real. >>>>> >>>>> >>>> >>>> This seems like it would be a problem for sniffing unencrypted data >>>> *from* another client, but I'm not getting how this sort of attack works by >>>> a client owned by the attacker querying the database. >>>> >>> This is just the kind of thing you might be able to do with the full >>> set of info. I think just responding on the first item would be good >>> enough as I missed an important point. >>> >>>> >>>> Before I get back to the rest of your query, help me understand this >>>> far. >>> >>> >>> Thank you! >>> >>>> >>>> >>>> pr >>>> >>>> -- >>>> Pete Resnick >>>> Qualcomm Technologies, Inc. - +1 (858)651-4478 >>>> >>>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >> >> >> >> -- >> -vince >> > > > > -- > > Best regards, > Kathleen > -- Best regards, Kathleen --089e013d1c46bc0ade05012528f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Chatted a bit with Pete and he sees the point we are down = to now. =C2=A0To be clear, I think we are down to a comment and would just = like to finish up the discussion and then I'll update the tracker since= we are close here.


On Thu, Aug 21, 2014 at 8:05 AM, Kathlee= n Moriarty <kathleen.moriarty.ietf@gmail.com>= wrote:



On Thu, Aug 21, 2014= at 4:15 AM, Vincent Chen <vchen@google.com> wrote:
Thanks to Pete for respondi= ng.

Additional comments inline.


On Wed, Aug 20, 2014 at 3:09 PM, Ka= thleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:



On Wed, Aug 20, 2014 at 5:03 PM= , Pete Resnick <presnick@qti.qualcomm.com> wrote:
On 8/20/14 3:31 PM, Kathleen Moriarty wrote:=
-------------------------------------------------------------= ---------
DISCUSS:
-------------------------------------------------------------= ---------
[...]

Can clients query any database entries or is the interface restricted to the list of supported interactions?=C2=A0 =C2=A0I assume the answer is that= it is
limited to the set of database interactions defined, but could not find
any statement saying that in this draft or the prior requirements in
RFC6953.
=C2=A0 =C2=A0

I'm not sure exactly what you mean here. Are you asking whether the cli= ent or server ask for/send back more than the minimum data? Sure, that'= s what the "*other" business is about. Or are you asking whether = additional queries/responses can be defined? I suppose they could. But I= 9;m not sure what you're asking, or what the concern is. Can you elabor= ate?

There wasn't an explicit statement that you n= eed to define new query/responses through extensions, so that coupled with = the possibility of unauthenticated sessions had me worrying that more data = could be exposed then intended. =C2=A0A statement in the security considera= tions section (maybe) after the MAY for authentication that helps state the= limitation of the interface to this and approved extensions would help. = =C2=A0The risk would be additional query/responses that let you get at more= data than was intended (some of the privacy related information or fingerp= rinting possibilities would be the concern.=C2=A0

The security consi= derations section started by saying that the Database provides
av= ailable spectrum information, which is public information. Nothing else can= be retrieved
from the Database.
=C2=A0
I don't see this text, can = you point it out? =C2=A0I may be missing it, but would have expected it as = one of the listed protection steps in section 10 or maybe as part of 10.1. = =C2=A0

I really think what I am looking for should have been i= n the requirements document for the protocol and any extensions. =C2=A0With= an assumption that only public information will be provided over the unaut= henticated sessions, limiting the scope of access to public information acc= ess through the defined interface (which you are doing) would be good to cl= ose out with a statement to that requirement.

Since I think this does really belong in the prior docu= ment, but could go here, I will consider this at the comment level and woul= d appreciate it if you could point out where I might be missing text that o= nly public information is available through the defined interface.

Thank you!

=

Does Pete's point about = the DeviceDescriptor being an echo of the request also resolve this
concern?
=C2=A0

Earlier in the draft it sounds as if authentication is = required until you get to that statement towards the end of the security co= nsiderations section.

NOTE: Since the Database returns the same available-spectrum ans= wer for the same combination of (device type, location), regardless of what= requests came before or after, authentication of the client seems to add l= ittle benefit. I.e., spoofing by rogue devices does not impact the answer g= iven to well-behaved devices.

Yes, Pete's po= int on DeviceDescriptor did help with some of my concerns and sorry that I = somehow missed it on my first read of the draft. =C2=A0 I'm not asking = for authentication to be required, so maybe that was misunderstood. =C2=A0I= didn't see anywhere a statement that extensions to this interface have= to be defined and should consider this premise information (authentication= is not required and the larger database does contain information that coul= d be used for profiling the overall system or fingerprinting devices. =C2= =A0Although, watching the other discusses, some of the requirements on fiel= ds are changing a bit and maybe the concerns are lowering as a result, but = we'll have to see where that winds up. =C2=A0I understand that the curr= ent interface limits what can be retrieved. =C2=A0In some other protocols, = I've seen an informational statement to ensure those writing extensions= are cognizant of the reasons for the limitations imposed. =C2=A0It looks l= ike you have done a pretty good job on it and I was hoping to see a stateme= nt on the limitations for the purpose of possible extensions in the future = following the patterns. =C2=A0I don't think I saw them spelled out in t= he requirements RFC.

Thanks,
Kathleen
=
=

=C2=A0


Authentication is only a MAY in the Security Considerations Section,
which raises another possible concern for me.

Since clients can get back pretty much all of the defined datatypes
(DeviceDescriptor is one example)

The client only gets back the DeviceDescriptor that it sent to the server i= n the request so that the client can match the response to the query.
<= br>
Sorry, I missed that very important point = in the query/response description somehow.
=C2=A0

and authentication is not required,
there should be a discussion on the risks of revealing this information
for both the privacy reasons Stephen and Alissa outlined as well as
possible security concerns.=C2=A0 I think this should be on a field basis i= n
terms of sensitive elements where relevant.
=C2=A0 =C2=A0

The rest of the responses are the publicly available spectrum information. = I'm not seeing sensitive data there.

<= div>Yep, for the current queries, I missed that you were only getting the r= esponse that included the DeviceDescriptor information you sent. =C2=A0Sorr= y about that!=C2=A0

I could see how you might want/need the types of information gathered
within an administrative domain or accessed by a restricted set of users, but revealing data like what is contained in deviceDescriptor (includes
model) as well as sensitive fields in other classes
(AntennaCharacteristics) seems like a risk as it could be used in
targeted attacks if there are known vulnerabilities to those devices.
The attacks could target specific regions at specific times to effect
events or to be used as part of some larger attack (could include
physical).=C2=A0 This may sound crazy, but layered attacks are very real. =C2=A0 =C2=A0

This seems like it would be a problem for sniffing unencrypted data *from* = another client, but I'm not getting how this sort of attack works by a = client owned by the attacker querying the database.
This is just the kind of thing you might be able to do with the full set of= info. =C2=A0I think just responding on the first item would be good enough= as I missed an important point.=C2=A0

Before I get back to the rest of your query, help me understand this far.

Thank you!=C2=A0


pr

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



--

Best regard= s,
Kathleen



--
-vince


--

Be= st regards,
Kathleen


--

Best regards,
Kathleen
--089e013d1c46bc0ade05012528f7-- From nobody Thu Aug 21 09:39:38 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692321A06A2 for ; Thu, 21 Aug 2014 09:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jueR6JZPEtou for ; Thu, 21 Aug 2014 09:39:34 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E6F1A0696 for ; Thu, 21 Aug 2014 09:39:34 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id im17so11053145vcb.17 for ; Thu, 21 Aug 2014 09:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7+NRH55vIK7cXtVak8nvB8unfRT8KzgLeV8ZOypghv0=; b=MoXjLjONO19RbTBAzDSOd/OEdN3TyBR4QC5zUSPxQOTzY9nza1DNgOwKaXpQNbTcav GagS+fRq8vPJOiTIp2tgBwG8jfq+e0YyhGWXYI+ujdnmyHOz9AgmNtGbg7WWdQ49MQxX LL17zH6CTvgMi3yuZjqxtEQAdf3GC5GM+LfKz0FB+Bs8lnrLPxHMQqU+W1badH1J4Tb/ ftTwfGn/aP9HGXe7kXinZN+ldmJRXgWUc5gAKIG9G51V01jq2G2s0F7jd62uXgqiBTQu T9nBXR1/9X4LtuDiUBW9Ce480E9im31zpajH5P7nhpZJ0CWFhzgk/6eFW/uFm06rdt4B Q5jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7+NRH55vIK7cXtVak8nvB8unfRT8KzgLeV8ZOypghv0=; b=TqzP3u9JuX6YHMrtv+H3cJfZMll+Lhw5xhDpktya0bai7QtYVNO/F5J9dILWvz1xh0 wulpy2jPx3AwvTgMl40cJpSlErlFj2xAG6HM7McRfN61PD3kNo5Vs6UDdBPMegcqrXxa 28/q3WWuLl1mD93n/jfZGOYW3FRppAW4pU2KcdCOpikOX+TZwSySe8WZJQ++ojeYaiMV DhjjT+UiHK1bpCBzAeFef7nBmUSuqOhA9a2o25onqn/NUucP/qYpcbBL3Mp40L80ei/n ayu4uem8whArZss3ydYG/q5mXiK5AK6pg/jrEWrN1cpFpH1QZ2GPN18MIXcuJuwyA5Sr PFsA== X-Gm-Message-State: ALoCoQm/YvN2X1E+ByW04tYK65Pie4KjJzsVb9QRXznWJPDS1ojGAGz2geZYKYNhwGEusIcFhDSt MIME-Version: 1.0 X-Received: by 10.221.21.8 with SMTP id qq8mr752574vcb.57.1408639173520; Thu, 21 Aug 2014 09:39:33 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Thu, 21 Aug 2014 09:39:33 -0700 (PDT) In-Reply-To: <53F60A78.9010406@qti.qualcomm.com> References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> <53F60A78.9010406@qti.qualcomm.com> Date: Thu, 21 Aug 2014 09:39:33 -0700 Message-ID: From: Vincent Chen To: Pete Resnick Content-Type: multipart/alternative; boundary=001a113399d88e12640501265d3a Archived-At: http://mailarchive.ietf.org/arch/msg/paws/k7-R82tSS0HWoK2dPSHhLnaN2_g Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 16:39:36 -0000 --001a113399d88e12640501265d3a Content-Type: text/plain; charset=UTF-8 On Thu, Aug 21, 2014 at 8:04 AM, Pete Resnick wrote: > On 8/21/14 2:59 AM, Vincent Chen wrote: > > = Section 4.5 = >> These two sentences seem to contradict each other: >> >> "The device identifier, capabilities, and characteristics >> communicated in the AVAIL_SPECTRUM_REQ message MUST be those of the >> Slave Device, but the location MUST be that of the Master Device." >> > > Ouch! I'll fix that. "... location MUST be that of the Slave Device." > >> > Do we have any idea how that got in there in the first place? That seems > like it was a conscious decision, and I want to make sure we're not missing > something. > Yes. In response to last call on draft 7 back on 2013-12-03, Sajeev Manikkoth suggested that we should have the ability to include the Slave location. In response, I proposed adding a masterDeviceLocation to refer to the Master's location, but I screwed up the text. > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > -- -vince --001a113399d88e12640501265d3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 21, 2014 at 8:04 AM, Pete Resnick <= ;presnick@qt= i.qualcomm.com> wrote:
=20
On 8/21/14 2:59 AM, Vincent Chen wrote:
=3D Section 4.5 =3D
These two sentences seem to contradict each other:

"The device identifier, capabilities, and characteristics
=C2=A0 =C2=A0communicated in the AVAIL_SPECTRUM_REQ message MUST be those o= f the
=C2=A0 =C2=A0Slave Device, but the location MUST be that of the Master Devi= ce."

Ouch! I'll fix that. "... location MUST be that of the Slav= e Device."=C2=A0

Do we have any idea how that got in there in the first place? That seems like it was a conscious decision, and I want to make sure we're not missing something.

Yes. In respon= se to last call on draft 7 back on 2013-12-03, Sajeev Manikkoth suggested t= hat we should have the ability to include the Slave location.
In response, I proposed adding a masterDeviceLocation to refer to the Maste= r's location, but I screwed up the text.



pr

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



--
-vince
--001a113399d88e12640501265d3a-- From nobody Thu Aug 21 10:26:08 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663761A06DD for ; Thu, 21 Aug 2014 10:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IStelBvFL4Gb for ; Thu, 21 Aug 2014 10:26:00 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77A21A06D0 for ; Thu, 21 Aug 2014 10:25:59 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id la4so11095826vcb.19 for ; Thu, 21 Aug 2014 10:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=knnoP0PjaRDVO/SfAlaUt3qSBXRqVH1Me2ia+lFXVU4=; b=l3zgzgWAdbBBCxK6trzvVU4nwc3Qspog8vmGL2FuX04LAcjOPq/VdzyJnWL75pBfyX dUqP8mkkKyv+d9PIAlCQ2UpjwFiXPgP5Z+rD3BugwUoQ+i3B+xpuM4fLMae80+9GXmn0 eo1vEjQENCBRxdaLStynMvFfIb1/fbfil5wuUc8BCbVm4srTnHjolGOKGh58O64wu7bk lQ5Mc+uVHxEIKQ+3T79r8ZdmxF3SBMlvGD9SY/ziBAQqWEY8iuW++bUvUcddaXwncC10 PGFiPN9haJbfwZKPYShsJiRUbj2mddb0gwpivQz+x3kIEswPH6rl4XLpGuQLvMS6hH3D 0rxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=knnoP0PjaRDVO/SfAlaUt3qSBXRqVH1Me2ia+lFXVU4=; b=BuCA7AysJumeU44IJUVo17d1BEmi0herbe9vOUcr2wZTJ9l69OXuD+FAzqzMNi2GtC 6cl7V6m05B9hrRBeId2NHvKZfYmVxxryP3uyYIk9T4Tq7cEej/x45is+6HkMM7SqGo3l 0RnOfinJxmHnv/epw2qXZhx/oteH5qu3ONXGuGqf/Y1yJqVUsWzNdOkV3Cu8UplB7Gin skodRdyTlleGQM/6F33aLNRRtVSAsjWwOz9//N/T8a7JDChCVSE1cXF5uY4cgX221I50 2txwJohfwZUSCQVNNP31BIP7droXUkWnJ/I3iTh0G49urc1Bhj+9EpzW0+GWksf6HwBw Z5ww== X-Gm-Message-State: ALoCoQnHI0vGVMzgKhhWGC7kx1J/3x3Vkqk6KCCj6D+gLluGjM4JIgNoPyqQ5BneAcARYr2gdjGF MIME-Version: 1.0 X-Received: by 10.221.64.142 with SMTP id xi14mr23375948vcb.31.1408641958966; Thu, 21 Aug 2014 10:25:58 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Thu, 21 Aug 2014 10:25:58 -0700 (PDT) In-Reply-To: References: <20140820203127.25270.64032.idtracker@ietfa.amsl.com> <53F50D2D.2010203@qti.qualcomm.com> Date: Thu, 21 Aug 2014 10:25:58 -0700 Message-ID: From: Vincent Chen To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=001a113312a6949be905012703a1 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/nEkkFJF_qaXY8gVgirI6qiwqQno Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , Pete Resnick , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 17:26:03 -0000 --001a113312a6949be905012703a1 Content-Type: text/plain; charset=UTF-8 Kathleen, Apologies for my poorly worded response. The first paragraph of Section 10 states: PAWS is a protocol whereby a Master Device requests a schedule of available spectrum at its location (or location of its Slave Devices) before it (they) can operate using those frequencies. The fact that it's "public information" is parenthetical in my response. Section 8 discusses extensibility. Should there just be a statement in there that no extensions should be made to return sensitive information about devices? That it should be focused on just returning available-spectrum information? Would that be sufficient? Thanks. On Thu, Aug 21, 2014 at 8:13 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Chatted a bit with Pete and he sees the point we are down to now. To be > clear, I think we are down to a comment and would just like to finish up > the discussion and then I'll update the tracker since we are close here. > > > On Thu, Aug 21, 2014 at 8:05 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> >> >> >> On Thu, Aug 21, 2014 at 4:15 AM, Vincent Chen wrote: >> >>> Thanks to Pete for responding. >>> >>> Additional comments inline. >>> >>> >>> On Wed, Aug 20, 2014 at 3:09 PM, Kathleen Moriarty < >>> kathleen.moriarty.ietf@gmail.com> wrote: >>> >>>> >>>> >>>> >>>> On Wed, Aug 20, 2014 at 5:03 PM, Pete Resnick < >>>> presnick@qti.qualcomm.com> wrote: >>>> >>>>> On 8/20/14 3:31 PM, Kathleen Moriarty wrote: >>>>> >>>>>> ------------------------------------------------------------ >>>>>> ---------- >>>>>> DISCUSS: >>>>>> ------------------------------------------------------------ >>>>>> ---------- >>>>>> [...] >>>>>> >>>>>> Can clients query any database entries or is the interface restricted >>>>>> to >>>>>> the list of supported interactions? I assume the answer is that it >>>>>> is >>>>>> limited to the set of database interactions defined, but could not >>>>>> find >>>>>> any statement saying that in this draft or the prior requirements in >>>>>> RFC6953. >>>>>> >>>>>> >>>>> >>>>> I'm not sure exactly what you mean here. Are you asking whether the >>>>> client or server ask for/send back more than the minimum data? Sure, that's >>>>> what the "*other" business is about. Or are you asking whether additional >>>>> queries/responses can be defined? I suppose they could. But I'm not sure >>>>> what you're asking, or what the concern is. Can you elaborate? >>>> >>>> >>>> There wasn't an explicit statement that you need to define new >>>> query/responses through extensions, so that coupled with the possibility of >>>> unauthenticated sessions had me worrying that more data could be exposed >>>> then intended. A statement in the security considerations section (maybe) >>>> after the MAY for authentication that helps state the limitation of the >>>> interface to this and approved extensions would help. The risk would be >>>> additional query/responses that let you get at more data than was intended >>>> (some of the privacy related information or fingerprinting possibilities >>>> would be the concern. >>>> >>> >>> The security considerations section started by saying that the Database >>> provides >>> available spectrum information, which is public information. Nothing >>> else can be retrieved >>> from the Database. >>> >> > I don't see this text, can you point it out? I may be missing it, but > would have expected it as one of the listed protection steps in section 10 > or maybe as part of 10.1. > > I really think what I am looking for should have been in the requirements > document for the protocol and any extensions. With an assumption that only > public information will be provided over the unauthenticated sessions, > limiting the scope of access to public information access through the > defined interface (which you are doing) would be good to close out with a > statement to that requirement. > > Since I think this does really belong in the prior document, but could go > here, I will consider this at the comment level and would appreciate it if > you could point out where I might be missing text that only public > information is available through the defined interface. > > Thank you! > > >>> Does Pete's point about the DeviceDescriptor being an echo of the >>> request also resolve this >>> concern? >>> >>> >>>> >>>> Earlier in the draft it sounds as if authentication is required until >>>> you get to that statement towards the end of the security considerations >>>> section. >>>> >>> >>> NOTE: Since the Database returns the same available-spectrum answer for >>> the same combination of (device type, location), regardless of what >>> requests came before or after, authentication of the client seems to add >>> little benefit. I.e., spoofing by rogue devices does not impact the answer >>> given to well-behaved devices. >>> >> >> Yes, Pete's point on DeviceDescriptor did help with some of my concerns >> and sorry that I somehow missed it on my first read of the draft. I'm not >> asking for authentication to be required, so maybe that was misunderstood. >> I didn't see anywhere a statement that extensions to this interface have >> to be defined and should consider this premise information (authentication >> is not required and the larger database does contain information that could >> be used for profiling the overall system or fingerprinting devices. >> Although, watching the other discusses, some of the requirements on fields >> are changing a bit and maybe the concerns are lowering as a result, but >> we'll have to see where that winds up. I understand that the current >> interface limits what can be retrieved. In some other protocols, I've seen >> an informational statement to ensure those writing extensions are cognizant >> of the reasons for the limitations imposed. It looks like you have done a >> pretty good job on it and I was hoping to see a statement on the >> limitations for the purpose of possible extensions in the future following >> the patterns. I don't think I saw them spelled out in the requirements RFC. >> >> Thanks, >> Kathleen >> >>> >>> >>> >>>> >>>>> >>>>> Authentication is only a MAY in the Security Considerations Section, >>>>>> which raises another possible concern for me. >>>>>> >>>>>> Since clients can get back pretty much all of the defined datatypes >>>>>> (DeviceDescriptor is one example) >>>>>> >>>>> >>>>> The client only gets back the DeviceDescriptor that it sent to the >>>>> server in the request so that the client can match the response to the >>>>> query. >>>>> >>>>> Sorry, I missed that very important point in the query/response >>>> description somehow. >>>> >>>> >>>>> >>>>> and authentication is not required, >>>>>> there should be a discussion on the risks of revealing this >>>>>> information >>>>>> for both the privacy reasons Stephen and Alissa outlined as well as >>>>>> possible security concerns. I think this should be on a field basis >>>>>> in >>>>>> terms of sensitive elements where relevant. >>>>>> >>>>>> >>>>> >>>>> The rest of the responses are the publicly available spectrum >>>>> information. I'm not seeing sensitive data there. >>>>> >>>>> Yep, for the current queries, I missed that you were only getting the >>>> response that included the DeviceDescriptor information you sent. Sorry >>>> about that! >>>> >>>>> >>>>> I could see how you might want/need the types of information gathered >>>>>> within an administrative domain or accessed by a restricted set of >>>>>> users, >>>>>> but revealing data like what is contained in deviceDescriptor >>>>>> (includes >>>>>> model) as well as sensitive fields in other classes >>>>>> (AntennaCharacteristics) seems like a risk as it could be used in >>>>>> targeted attacks if there are known vulnerabilities to those devices. >>>>>> The attacks could target specific regions at specific times to effect >>>>>> events or to be used as part of some larger attack (could include >>>>>> physical). This may sound crazy, but layered attacks are very real. >>>>>> >>>>>> >>>>> >>>>> This seems like it would be a problem for sniffing unencrypted data >>>>> *from* another client, but I'm not getting how this sort of attack works by >>>>> a client owned by the attacker querying the database. >>>>> >>>> This is just the kind of thing you might be able to do with the full >>>> set of info. I think just responding on the first item would be good >>>> enough as I missed an important point. >>>> >>>>> >>>>> Before I get back to the rest of your query, help me understand this >>>>> far. >>>> >>>> >>>> Thank you! >>>> >>>>> >>>>> >>>>> pr >>>>> >>>>> -- >>>>> Pete Resnick >>>>> Qualcomm Technologies, Inc. - +1 (858)651-4478 >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Best regards, >>>> Kathleen >>>> >>> >>> >>> >>> -- >>> -vince >>> >> >> >> >> -- >> >> Best regards, >> Kathleen >> > > > > -- > > Best regards, > Kathleen > -- -vince --001a113312a6949be905012703a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Kathleen,

Apologies for my poorly worde= d response. The first paragraph of Section 10 states:

   PAWS is a protocol whereby a Master Device requests a schedule of
   available spectrum at its location (or location of its Slave Devices)
   before it (they) can operate using those frequencies.

The fact that it's "public information" is parenthet= ical in my response.

Section 8 discusses extensibi= lity. Should there just be a statement in there that no extensions
should be made to return sensitive information about devices? That it = should be focused
on just returning available-spectrum informatio= n?

Would that be sufficient?

Thanks.



On Thu, Aug 21, 2014 at 8:13 AM= , Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com&g= t; wrote:
Chatted a bit with Pete and= he sees the point we are down to now. =C2=A0To be clear, I think we are do= wn to a comment and would just like to finish up the discussion and then I&= #39;ll update the tracker since we are close here.


On Thu, Aug 21, 2014 at = 8:05 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.co= m> wrote:



On Thu, Aug 21, 2014 at 4:15 AM= , Vincent Chen <vchen@google.com> wrote:
Thanks to Pete for respondi= ng.

Additional comments inline.


On Wed, Aug 20, 2014 at 3:09 PM, Ka= thleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:



On Wed, Aug 20, 2014 at 5:03 PM= , Pete Resnick <presnick@qti.qualcomm.com> wrote:
On 8/20/14 3:31 PM, Kathleen Moriarty wrote:=
-------------------------------------------------------------= ---------
DISCUSS:
-------------------------------------------------------------= ---------
[...]

Can clients query any database entries or is the interface restricted to the list of supported interactions?=C2=A0 =C2=A0I assume the answer is that= it is
limited to the set of database interactions defined, but could not find
any statement saying that in this draft or the prior requirements in
RFC6953.
=C2=A0 =C2=A0

I'm not sure exactly what you mean here. Are you asking whether the cli= ent or server ask for/send back more than the minimum data? Sure, that'= s what the "*other" business is about. Or are you asking whether = additional queries/responses can be defined? I suppose they could. But I= 9;m not sure what you're asking, or what the concern is. Can you elabor= ate?

There wasn't an explicit statement that you n= eed to define new query/responses through extensions, so that coupled with = the possibility of unauthenticated sessions had me worrying that more data = could be exposed then intended. =C2=A0A statement in the security considera= tions section (maybe) after the MAY for authentication that helps state the= limitation of the interface to this and approved extensions would help. = =C2=A0The risk would be additional query/responses that let you get at more= data than was intended (some of the privacy related information or fingerp= rinting possibilities would be the concern.=C2=A0

The security consi= derations section started by saying that the Database provides
av= ailable spectrum information, which is public information. Nothing else can= be retrieved
from the Database.
=C2=A0
I don't see this text= , can you point it out? =C2=A0I may be missing it, but would have expected = it as one of the listed protection steps in section 10 or maybe as part of = 10.1. =C2=A0

I really think what I am looking for should have been i= n the requirements document for the protocol and any extensions. =C2=A0With= an assumption that only public information will be provided over the unaut= henticated sessions, limiting the scope of access to public information acc= ess through the defined interface (which you are doing) would be good to cl= ose out with a statement to that requirement.

Since I think this does really belong in the prior docu= ment, but could go here, I will consider this at the comment level and woul= d appreciate it if you could point out where I might be missing text that o= nly public information is available through the defined interface.

Thank you!

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
<= div class=3D"gmail_quote">
=

Does Pete's point about = the DeviceDescriptor being an echo of the request also resolve this
concern?
=C2=A0

Earlier in the draft it sounds as if authentication is = required until you get to that statement towards the end of the security co= nsiderations section.

NOTE: Since the Database returns the same available-spectrum ans= wer for the same combination of (device type, location), regardless of what= requests came before or after, authentication of the client seems to add l= ittle benefit. I.e., spoofing by rogue devices does not impact the answer g= iven to well-behaved devices.

Yes, Pete's po= int on DeviceDescriptor did help with some of my concerns and sorry that I = somehow missed it on my first read of the draft. =C2=A0 I'm not asking = for authentication to be required, so maybe that was misunderstood. =C2=A0I= didn't see anywhere a statement that extensions to this interface have= to be defined and should consider this premise information (authentication= is not required and the larger database does contain information that coul= d be used for profiling the overall system or fingerprinting devices. =C2= =A0Although, watching the other discusses, some of the requirements on fiel= ds are changing a bit and maybe the concerns are lowering as a result, but = we'll have to see where that winds up. =C2=A0I understand that the curr= ent interface limits what can be retrieved. =C2=A0In some other protocols, = I've seen an informational statement to ensure those writing extensions= are cognizant of the reasons for the limitations imposed. =C2=A0It looks l= ike you have done a pretty good job on it and I was hoping to see a stateme= nt on the limitations for the purpose of possible extensions in the future = following the patterns. =C2=A0I don't think I saw them spelled out in t= he requirements RFC.

Thanks,
Kathleen

=C2=A0


Authentication is only a MAY in the Security Considerations Section,
which raises another possible concern for me.

Since clients can get back pretty much all of the defined datatypes
(DeviceDescriptor is one example)

The client only gets back the DeviceDescriptor that it sent to the server i= n the request so that the client can match the response to the query.
<= br>
Sorry, I missed that very important point = in the query/response description somehow.
=C2=A0

and authentication is not required,
there should be a discussion on the risks of revealing this information
for both the privacy reasons Stephen and Alissa outlined as well as
possible security concerns.=C2=A0 I think this should be on a field basis i= n
terms of sensitive elements where relevant.
=C2=A0 =C2=A0

The rest of the responses are the publicly available spectrum information. = I'm not seeing sensitive data there.

<= div>Yep, for the current queries, I missed that you were only getting the r= esponse that included the DeviceDescriptor information you sent. =C2=A0Sorr= y about that!=C2=A0

I could see how you might want/need the types of information gathered
within an administrative domain or accessed by a restricted set of users, but revealing data like what is contained in deviceDescriptor (includes
model) as well as sensitive fields in other classes
(AntennaCharacteristics) seems like a risk as it could be used in
targeted attacks if there are known vulnerabilities to those devices.
The attacks could target specific regions at specific times to effect
events or to be used as part of some larger attack (could include
physical).=C2=A0 This may sound crazy, but layered attacks are very real. =C2=A0 =C2=A0

This seems like it would be a problem for sniffing unencrypted data *from* = another client, but I'm not getting how this sort of attack works by a = client owned by the attacker querying the database.
This is just the kind of thing you might be able to do with the full set of= info. =C2=A0I think just responding on the first item would be good enough= as I missed an important point.=C2=A0

Before I get back to the rest of your query, help me understand this far.

Thank you!=C2=A0


pr

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



--

Best regard= s,
Kathleen



--
-vince


--

Best regards,
Kathleen



--

Be= st regards,
Kathleen


--
-vince --001a113312a6949be905012703a1-- From nobody Thu Aug 21 12:47:30 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8031A8A4D; Thu, 21 Aug 2014 12:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG_cebuIfRti; Thu, 21 Aug 2014 12:44:21 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74511A8A4C; Thu, 21 Aug 2014 12:44:20 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id z11so8742933lbi.27 for ; Thu, 21 Aug 2014 12:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QapssmwV95tkCCd3uPdreNNZGN7GNaTlFK0F7auUyss=; b=mxtShrOF0SYrxz+T7IDC7oIiUagj19woDCNCHH8Mj3nG4JOYGIX/CuoWeAxRYIbUnu SrhbKVzat0G/BTQ1OYAk66HDGTA4WfEBG/hv4mBvVLyR+vnWm5cyJpwP6VZef5CGZIsu c2+2ftfR/bRlE3tFve0NzmXGYC7CFNTGDTgs+3HUQuV5vAxOD5S8uZtbGuAIwKIGMZ+v WN/zrRzL0pmCFSK6UFoTJ2oEObk8j19+GHE2BmSa4MKrYfdI8dltzjlGsBl0UEHzhmes WG6Z0wqgv19xQ6vDalC24FFd4v9GzT0Lcf0lXBDh/VKiLDrJUorXtbfr0IBV+ZHE2DPj hkIg== MIME-Version: 1.0 X-Received: by 10.152.245.171 with SMTP id xp11mr487702lac.61.1408650258723; Thu, 21 Aug 2014 12:44:18 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Thu, 21 Aug 2014 12:44:18 -0700 (PDT) In-Reply-To: References: <20140820203127.25270.64032.idtracker@ietfa.amsl.com> <53F50D2D.2010203@qti.qualcomm.com> Date: Thu, 21 Aug 2014 15:44:18 -0400 Message-ID: From: Kathleen Moriarty To: Vincent Chen Content-Type: multipart/alternative; boundary=001a11345e1248ba26050128f20e Archived-At: http://mailarchive.ietf.org/arch/msg/paws/xO9WzcJP4wYcSSy6crfQN4-XXoY X-Mailman-Approved-At: Thu, 21 Aug 2014 12:47:27 -0700 Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , Pete Resnick , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:44:26 -0000 --001a11345e1248ba26050128f20e Content-Type: text/plain; charset=UTF-8 Hi Vincent, On Thu, Aug 21, 2014 at 1:25 PM, Vincent Chen wrote: > Kathleen, > > Apologies for my poorly worded response. The first paragraph of Section 10 > states: > > PAWS is a protocol whereby a Master Device requests a schedule of > available spectrum at its location (or location of its Slave Devices) > before it (they) can operate using those frequencies. > > > The fact that it's "public information" is parenthetical in my response. > OK, this isn't my area of expertise, so I didn't read it the same way in that information was limited to requests of public data. > > Section 8 discusses extensibility. Should there just be a statement in > there that no extensions > should be made to return sensitive information about devices? That it > should be focused > on just returning available-spectrum information? > > Yes, that would help, thank you. > Would that be sufficient? > > Thanks. > > > > On Thu, Aug 21, 2014 at 8:13 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Chatted a bit with Pete and he sees the point we are down to now. To be >> clear, I think we are down to a comment and would just like to finish up >> the discussion and then I'll update the tracker since we are close here. >> >> >> On Thu, Aug 21, 2014 at 8:05 AM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >>> >>> >>> >>> On Thu, Aug 21, 2014 at 4:15 AM, Vincent Chen wrote: >>> >>>> Thanks to Pete for responding. >>>> >>>> Additional comments inline. >>>> >>>> >>>> On Wed, Aug 20, 2014 at 3:09 PM, Kathleen Moriarty < >>>> kathleen.moriarty.ietf@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Aug 20, 2014 at 5:03 PM, Pete Resnick < >>>>> presnick@qti.qualcomm.com> wrote: >>>>> >>>>>> On 8/20/14 3:31 PM, Kathleen Moriarty wrote: >>>>>> >>>>>>> ------------------------------------------------------------ >>>>>>> ---------- >>>>>>> DISCUSS: >>>>>>> ------------------------------------------------------------ >>>>>>> ---------- >>>>>>> [...] >>>>>>> >>>>>>> Can clients query any database entries or is the interface >>>>>>> restricted to >>>>>>> the list of supported interactions? I assume the answer is that it >>>>>>> is >>>>>>> limited to the set of database interactions defined, but could not >>>>>>> find >>>>>>> any statement saying that in this draft or the prior requirements in >>>>>>> RFC6953. >>>>>>> >>>>>>> >>>>>> >>>>>> I'm not sure exactly what you mean here. Are you asking whether the >>>>>> client or server ask for/send back more than the minimum data? Sure, that's >>>>>> what the "*other" business is about. Or are you asking whether additional >>>>>> queries/responses can be defined? I suppose they could. But I'm not sure >>>>>> what you're asking, or what the concern is. Can you elaborate? >>>>> >>>>> >>>>> There wasn't an explicit statement that you need to define new >>>>> query/responses through extensions, so that coupled with the possibility of >>>>> unauthenticated sessions had me worrying that more data could be exposed >>>>> then intended. A statement in the security considerations section (maybe) >>>>> after the MAY for authentication that helps state the limitation of the >>>>> interface to this and approved extensions would help. The risk would be >>>>> additional query/responses that let you get at more data than was intended >>>>> (some of the privacy related information or fingerprinting possibilities >>>>> would be the concern. >>>>> >>>> >>>> The security considerations section started by saying that the Database >>>> provides >>>> available spectrum information, which is public information. Nothing >>>> else can be retrieved >>>> from the Database. >>>> >>> >> I don't see this text, can you point it out? I may be missing it, but >> would have expected it as one of the listed protection steps in section 10 >> or maybe as part of 10.1. >> >> I really think what I am looking for should have been in the requirements >> document for the protocol and any extensions. With an assumption that only >> public information will be provided over the unauthenticated sessions, >> limiting the scope of access to public information access through the >> defined interface (which you are doing) would be good to close out with a >> statement to that requirement. >> >> Since I think this does really belong in the prior document, but could go >> here, I will consider this at the comment level and would appreciate it if >> you could point out where I might be missing text that only public >> information is available through the defined interface. >> >> Thank you! >> >> >>>> Does Pete's point about the DeviceDescriptor being an echo of the >>>> request also resolve this >>>> concern? >>>> >>>> >>>>> >>>>> Earlier in the draft it sounds as if authentication is required until >>>>> you get to that statement towards the end of the security considerations >>>>> section. >>>>> >>>> >>>> NOTE: Since the Database returns the same available-spectrum answer for >>>> the same combination of (device type, location), regardless of what >>>> requests came before or after, authentication of the client seems to add >>>> little benefit. I.e., spoofing by rogue devices does not impact the answer >>>> given to well-behaved devices. >>>> >>> >>> Yes, Pete's point on DeviceDescriptor did help with some of my concerns >>> and sorry that I somehow missed it on my first read of the draft. I'm not >>> asking for authentication to be required, so maybe that was misunderstood. >>> I didn't see anywhere a statement that extensions to this interface have >>> to be defined and should consider this premise information (authentication >>> is not required and the larger database does contain information that could >>> be used for profiling the overall system or fingerprinting devices. >>> Although, watching the other discusses, some of the requirements on fields >>> are changing a bit and maybe the concerns are lowering as a result, but >>> we'll have to see where that winds up. I understand that the current >>> interface limits what can be retrieved. In some other protocols, I've seen >>> an informational statement to ensure those writing extensions are cognizant >>> of the reasons for the limitations imposed. It looks like you have done a >>> pretty good job on it and I was hoping to see a statement on the >>> limitations for the purpose of possible extensions in the future following >>> the patterns. I don't think I saw them spelled out in the requirements RFC. >>> >>> Thanks, >>> Kathleen >>> >>>> >>>> >>>> >>>>> >>>>>> >>>>>> Authentication is only a MAY in the Security Considerations Section, >>>>>>> which raises another possible concern for me. >>>>>>> >>>>>>> Since clients can get back pretty much all of the defined datatypes >>>>>>> (DeviceDescriptor is one example) >>>>>>> >>>>>> >>>>>> The client only gets back the DeviceDescriptor that it sent to the >>>>>> server in the request so that the client can match the response to the >>>>>> query. >>>>>> >>>>>> Sorry, I missed that very important point in the query/response >>>>> description somehow. >>>>> >>>>> >>>>>> >>>>>> and authentication is not required, >>>>>>> there should be a discussion on the risks of revealing this >>>>>>> information >>>>>>> for both the privacy reasons Stephen and Alissa outlined as well as >>>>>>> possible security concerns. I think this should be on a field basis >>>>>>> in >>>>>>> terms of sensitive elements where relevant. >>>>>>> >>>>>>> >>>>>> >>>>>> The rest of the responses are the publicly available spectrum >>>>>> information. I'm not seeing sensitive data there. >>>>>> >>>>>> Yep, for the current queries, I missed that you were only getting the >>>>> response that included the DeviceDescriptor information you sent. Sorry >>>>> about that! >>>>> >>>>>> >>>>>> I could see how you might want/need the types of information gathered >>>>>>> within an administrative domain or accessed by a restricted set of >>>>>>> users, >>>>>>> but revealing data like what is contained in deviceDescriptor >>>>>>> (includes >>>>>>> model) as well as sensitive fields in other classes >>>>>>> (AntennaCharacteristics) seems like a risk as it could be used in >>>>>>> targeted attacks if there are known vulnerabilities to those devices. >>>>>>> The attacks could target specific regions at specific times to effect >>>>>>> events or to be used as part of some larger attack (could include >>>>>>> physical). This may sound crazy, but layered attacks are very real. >>>>>>> >>>>>>> >>>>>> >>>>>> This seems like it would be a problem for sniffing unencrypted data >>>>>> *from* another client, but I'm not getting how this sort of attack works by >>>>>> a client owned by the attacker querying the database. >>>>>> >>>>> This is just the kind of thing you might be able to do with the full >>>>> set of info. I think just responding on the first item would be good >>>>> enough as I missed an important point. >>>>> >>>>>> >>>>>> Before I get back to the rest of your query, help me understand this >>>>>> far. >>>>> >>>>> >>>>> Thank you! >>>>> >>>>>> >>>>>> >>>>>> pr >>>>>> >>>>>> -- >>>>>> Pete Resnick >>>>>> Qualcomm Technologies, Inc. - +1 (858)651-4478 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Best regards, >>>>> Kathleen >>>>> >>>> >>>> >>>> >>>> -- >>>> -vince >>>> >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >> >> >> >> -- >> >> Best regards, >> Kathleen >> > > > > -- > -vince > -- Best regards, Kathleen --001a11345e1248ba26050128f20e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Vincent,


On Thu, Aug 21, 2014 at 1:25 PM, Vincent Chen <vchen@googl= e.com> wrote:
Kathleen,

Apologies for my poorly worded response. The first paragraph of Section 1= 0 states:

   PAWS is a protocol whereby a Master Device requests a=
 schedule of
   available spectrum at its location (or location of its Slave Devices)
   before it (they) can operate using those frequencies.

The fact that it's "public information" is parenthet= ical in my response.

OK, this isn't my area of expertise, so I didn't read it= the same way in that information was limited to requests of public data.= =C2=A0

Section 8 discusses ext= ensibility. Should there just be a statement in there that no extensions
should be made to return sensitive information about devices? That it = should be focused
on just returning available-spectrum informatio= n?

Yes, that = would help, thank you.=C2=A0
=C2=A0
=
Would that be sufficient?

Thanks.



On Thu, = Aug 21, 2014 at 8:13 AM, Kathleen Moriarty <kathleen.moriar= ty.ietf@gmail.com> wrote:
Chatted a bit with Pete and= he sees the point we are down to now. =C2=A0To be clear, I think we are do= wn to a comment and would just like to finish up the discussion and then I&= #39;ll update the tracker since we are close here.


On Thu, Aug 21, 2014 at 8:05 AM, Ka= thleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:



On Thu, Aug 21, 2014 at 4:15 AM= , Vincent Chen <vchen@google.com> wrote:
Thanks to Pete for respondi= ng.

Additional comments inline.


On Wed, Aug 20, 2014 at 3:09 PM, Ka= thleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:



On Wed, Aug 20, 2014 at 5:03 PM= , Pete Resnick <presnick@qti.qualcomm.com> wrote:
On 8/20/14 3:31 PM, Kathleen Moriarty wrote:=
-------------------------------------------------------------= ---------
DISCUSS:
-------------------------------------------------------------= ---------
[...]

Can clients query any database entries or is the interface restricted to the list of supported interactions?=C2=A0 =C2=A0I assume the answer is that= it is
limited to the set of database interactions defined, but could not find
any statement saying that in this draft or the prior requirements in
RFC6953.
=C2=A0 =C2=A0

I'm not sure exactly what you mean here. Are you asking whether the cli= ent or server ask for/send back more than the minimum data? Sure, that'= s what the "*other" business is about. Or are you asking whether = additional queries/responses can be defined? I suppose they could. But I= 9;m not sure what you're asking, or what the concern is. Can you elabor= ate?

There wasn't an explicit statement that you n= eed to define new query/responses through extensions, so that coupled with = the possibility of unauthenticated sessions had me worrying that more data = could be exposed then intended. =C2=A0A statement in the security considera= tions section (maybe) after the MAY for authentication that helps state the= limitation of the interface to this and approved extensions would help. = =C2=A0The risk would be additional query/responses that let you get at more= data than was intended (some of the privacy related information or fingerp= rinting possibilities would be the concern.=C2=A0

The security consi= derations section started by saying that the Database provides
av= ailable spectrum information, which is public information. Nothing else can= be retrieved
from the Database.
=C2=A0
I don't see this text= , can you point it out? =C2=A0I may be missing it, but would have expected = it as one of the listed protection steps in section 10 or maybe as part of = 10.1. =C2=A0

I really think what I am looking for should have been i= n the requirements document for the protocol and any extensions. =C2=A0With= an assumption that only public information will be provided over the unaut= henticated sessions, limiting the scope of access to public information acc= ess through the defined interface (which you are doing) would be good to cl= ose out with a statement to that requirement.

Since I think this does really belong in the prior docu= ment, but could go here, I will consider this at the comment level and woul= d appreciate it if you could point out where I might be missing text that o= nly public information is available through the defined interface.

Thank you!

=

Does Pete's point about = the DeviceDescriptor being an echo of the request also resolve this
concern?
=C2=A0

Earlier in the draft it sounds as if authentication is = required until you get to that statement towards the end of the security co= nsiderations section.

NOTE: Since the Database returns the same available-spectrum ans= wer for the same combination of (device type, location), regardless of what= requests came before or after, authentication of the client seems to add l= ittle benefit. I.e., spoofing by rogue devices does not impact the answer g= iven to well-behaved devices.

Yes, Pete's po= int on DeviceDescriptor did help with some of my concerns and sorry that I = somehow missed it on my first read of the draft. =C2=A0 I'm not asking = for authentication to be required, so maybe that was misunderstood. =C2=A0I= didn't see anywhere a statement that extensions to this interface have= to be defined and should consider this premise information (authentication= is not required and the larger database does contain information that coul= d be used for profiling the overall system or fingerprinting devices. =C2= =A0Although, watching the other discusses, some of the requirements on fiel= ds are changing a bit and maybe the concerns are lowering as a result, but = we'll have to see where that winds up. =C2=A0I understand that the curr= ent interface limits what can be retrieved. =C2=A0In some other protocols, = I've seen an informational statement to ensure those writing extensions= are cognizant of the reasons for the limitations imposed. =C2=A0It looks l= ike you have done a pretty good job on it and I was hoping to see a stateme= nt on the limitations for the purpose of possible extensions in the future = following the patterns. =C2=A0I don't think I saw them spelled out in t= he requirements RFC.

Thanks,
Kathleen

=C2=A0


Authentication is only a MAY in the Security Considerations Section,
which raises another possible concern for me.

Since clients can get back pretty much all of the defined datatypes
(DeviceDescriptor is one example)

The client only gets back the DeviceDescriptor that it sent to the server i= n the request so that the client can match the response to the query.
<= br>
Sorry, I missed that very important point = in the query/response description somehow.
=C2=A0

and authentication is not required,
there should be a discussion on the risks of revealing this information
for both the privacy reasons Stephen and Alissa outlined as well as
possible security concerns.=C2=A0 I think this should be on a field basis i= n
terms of sensitive elements where relevant.
=C2=A0 =C2=A0

The rest of the responses are the publicly available spectrum information. = I'm not seeing sensitive data there.

<= div>Yep, for the current queries, I missed that you were only getting the r= esponse that included the DeviceDescriptor information you sent. =C2=A0Sorr= y about that!=C2=A0

I could see how you might want/need the types of information gathered
within an administrative domain or accessed by a restricted set of users, but revealing data like what is contained in deviceDescriptor (includes
model) as well as sensitive fields in other classes
(AntennaCharacteristics) seems like a risk as it could be used in
targeted attacks if there are known vulnerabilities to those devices.
The attacks could target specific regions at specific times to effect
events or to be used as part of some larger attack (could include
physical).=C2=A0 This may sound crazy, but layered attacks are very real. =C2=A0 =C2=A0

This seems like it would be a problem for sniffing unencrypted data *from* = another client, but I'm not getting how this sort of attack works by a = client owned by the attacker querying the database.
This is just the kind of thing you might be able to do with the full set of= info. =C2=A0I think just responding on the first item would be good enough= as I missed an important point.=C2=A0

Before I get back to the rest of your query, help me understand this far.

Thank you!=C2=A0


pr

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



--

Best regard= s,
Kathleen



--
-vince



--

Best regards,
Kathleen



--

Best regards,
Kathleen



--
-vince


--

Best regards,
Kathleen
--001a11345e1248ba26050128f20e-- From nobody Thu Aug 21 12:50:13 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72401A0678; Thu, 21 Aug 2014 12:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blKjFIYErh6F; Thu, 21 Aug 2014 12:49:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D41E21A0698; Thu, 21 Aug 2014 12:49:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C3060BF0A; Thu, 21 Aug 2014 20:49:57 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YD_ik1pdAfun; Thu, 21 Aug 2014 20:49:56 +0100 (IST) Received: from [10.87.48.11] (unknown [86.41.63.24]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 66D46BEFB; Thu, 21 Aug 2014 20:49:56 +0100 (IST) Message-ID: <53F64D64.8050002@cs.tcd.ie> Date: Thu, 21 Aug 2014 20:49:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Kathleen Moriarty , Vincent Chen References: <20140820203127.25270.64032.idtracker@ietfa.amsl.com> <53F50D2D.2010203@qti.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/paws/Dsq1KogE4Wl5puHYGmWGHPOZlac Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , Pete Resnick , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:50:01 -0000 Hiya, On 21/08/14 20:44, Kathleen Moriarty wrote: > OK, this isn't my area of expertise, so I didn't read it the same way in > that information was limited to requests of public data. > Nothing really to do with IESG processing of this but I'm curious... Is the full DB information really considered public? My impression was rather that trying to extract the full DB of information via repeated queries would be frowned upon. S. From nobody Thu Aug 21 12:51:08 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C1B1A06CD; Thu, 21 Aug 2014 12:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWXodGBDk_fk; Thu, 21 Aug 2014 12:51:04 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4501D1A0698; Thu, 21 Aug 2014 12:51:04 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id mc6so8999987lab.20 for ; Thu, 21 Aug 2014 12:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BcQKVpaSNMly53Y/nlWTGyk+lOxBXlvx7xo/YcsdWLM=; b=KKW6xMvIQfHKU1ZjnN6psLPyzurXxULFWjFbx5I1tzO8JFxjH6l65fDeYrZ9i9ltNT xup1ft+Zy4rvIWz0F+mzDpxogb2LYPUEW9M1N8gq5ncvy3X6GZmAKcAAdwcxEhDpDjV9 TXlGzHqQCLwOW5hRDFRjNO76+SG2v+lCVmgd+tubWmMtZD/5pPQk8AaONi0aVw/eGt5K gA29l9xdoEukOf9vjXOoCWrQHZbCSqft17ePqBq2p0vE4NoaPsXTMc7eu/41st2mNAsO YTYvfF4kiMr5jdFIothJVVNDw4FnqmuiMKMjvZ0zN55bOFpYxZNWW05vA1hAX5K+9lbN rs3Q== MIME-Version: 1.0 X-Received: by 10.112.169.35 with SMTP id ab3mr504417lbc.41.1408650662647; Thu, 21 Aug 2014 12:51:02 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Thu, 21 Aug 2014 12:51:02 -0700 (PDT) In-Reply-To: <53F64D64.8050002@cs.tcd.ie> References: <20140820203127.25270.64032.idtracker@ietfa.amsl.com> <53F50D2D.2010203@qti.qualcomm.com> <53F64D64.8050002@cs.tcd.ie> Date: Thu, 21 Aug 2014 15:51:02 -0400 Message-ID: From: Kathleen Moriarty To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c2696a5c1d270501290a4b Archived-At: http://mailarchive.ietf.org/arch/msg/paws/YLTFYICX2VLdTf_oMW48PtJyZRE Cc: "paws-chairs@tools.ietf.org" , Pete Resnick , "paws@ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:51:06 -0000 --001a11c2696a5c1d270501290a4b Content-Type: text/plain; charset=UTF-8 On Thu, Aug 21, 2014 at 3:49 PM, Stephen Farrell wrote: > > Hiya, > > On 21/08/14 20:44, Kathleen Moriarty wrote: > > OK, this isn't my area of expertise, so I didn't read it the same way in > > that information was limited to requests of public data. > > > > Nothing really to do with IESG processing of this but I'm > curious... > > Is the full DB information really considered public? I'm glad it wasn't just me ;-) Maybe stating that explicitly would be good. My > impression was rather that trying to extract the full DB > of information via repeated queries would be frowned upon. > > S. > -- Best regards, Kathleen --001a11c2696a5c1d270501290a4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 21, 2014 at 3:49 PM, Stephen Farrell = <stephen.= farrell@cs.tcd.ie> wrote:

Hiya,

On 21/08/14 20:44, Kathleen Moriarty wrote:
> OK, this isn't my area of expertise, so I didn't read it the s= ame way in
> that information was limited to requests of public data.
>

Nothing really to do with IESG processing of this but I'm
curious...

Is the full DB information really considered public?

=
I'm glad it wasn't just me ;-) =C2=A0Maybe stating that = explicitly would be good.=C2=A0

My
impression was rather that trying to extract the full DB
of information via repeated queries would be frowned upon.

S.



--

Best regards,
Kathleen
--001a11c2696a5c1d270501290a4b-- From nobody Thu Aug 21 12:54:10 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CDB1A06D4; Thu, 21 Aug 2014 12:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9ntv3BjqRVS; Thu, 21 Aug 2014 12:54:05 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105F01A06CD; Thu, 21 Aug 2014 12:54:04 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id u10so8413685lbd.7 for ; Thu, 21 Aug 2014 12:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4nLNTC5Dc/16xFLVVjJOS6alU/Ld5WNE7wInyxi8cXM=; b=S5auaS+loIpWxzgydLNgtc+Whjk2Jr+VvM7lCH4pdN6UigZFBoXfPCw89OoQAUVmxN gcTOuJKgh3rFBXar0uTa97HndGfSxTRbGUWGTD4DdyEbmorGk4bjesE5+v+fGTFQykbe 4zon65lpQE4o1Jop9x3bDhvxuAFsNiyt0NMxKmCJJhxldQYO5fvSVLC3BhX07DC2lNoq NN67IEavgfsR+xVK5yklLopZIjDzRUh5jjyGK4oPsUhBs4EaQJHsUnlYHVE3gu8ye6zD vbUSk7ouE+4GekF0cCwInNcDJHiZFPW6TEleTxEJ99qSDIctK7nvqqZSmh1+ENMWspL+ zbOg== MIME-Version: 1.0 X-Received: by 10.112.189.97 with SMTP id gh1mr651425lbc.40.1408650843407; Thu, 21 Aug 2014 12:54:03 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Thu, 21 Aug 2014 12:54:03 -0700 (PDT) In-Reply-To: References: <20140820203127.25270.64032.idtracker@ietfa.amsl.com> <53F50D2D.2010203@qti.qualcomm.com> <53F64D64.8050002@cs.tcd.ie> Date: Thu, 21 Aug 2014 15:54:03 -0400 Message-ID: From: Kathleen Moriarty To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c36fd222495005012915ce Archived-At: http://mailarchive.ietf.org/arch/msg/paws/cBMJWvBWLvYxLL1wAfbhLyEuowA Cc: "paws-chairs@tools.ietf.org" , Pete Resnick , "paws@ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:54:07 -0000 --001a11c36fd222495005012915ce Content-Type: text/plain; charset=UTF-8 On Thu, Aug 21, 2014 at 3:51 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > > > > On Thu, Aug 21, 2014 at 3:49 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> >> Hiya, >> >> On 21/08/14 20:44, Kathleen Moriarty wrote: >> > OK, this isn't my area of expertise, so I didn't read it the same way in >> > that information was limited to requests of public data. >> > >> >> Nothing really to do with IESG processing of this but I'm >> curious... >> >> Is the full DB information really considered public? > > > I'm glad it wasn't just me ;-) Maybe stating that explicitly would be > good. > > My >> impression was rather that trying to extract the full DB >> of information via repeated queries would be frowned upon. >> > Just to be clear - As I understand it now, the database may have sensitive information, but the interface via PAWS only allows access to data that is not sensitive. If you can query it, it is public. If you have database access or other extensions are written, then it could be possible to get access to sensitive data. > >> S. >> > > > > -- > > Best regards, > Kathleen > -- Best regards, Kathleen --001a11c36fd222495005012915ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 21, 2014 at 3:51 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:



On Thu, Aug 21, 2014= at 3:49 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 21/08/14 20:44, Kathleen Moriarty wrote:
> OK, this isn't my area of expertise, so I didn't read it the s= ame way in
> that information was limited to requests of public data.
>

Nothing really to do with IESG processing of this but I'm
curious...

Is the full DB information really considered public?

=
I'm glad it wasn't just me ;-) =C2=A0Maybe stating= that explicitly would be good.=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> My
impression was rather that trying to extract the full DB
of information via repeated queries would be frowned upon.
=
Just to be clear - As I understan= d it now, the database may have sensitive information, but the interface vi= a PAWS only allows access to data that is not sensitive. =C2=A0If you can q= uery it, it is public. =C2=A0If you have database access or other extension= s are written, then it could be possible to get access to sensitive data.= =C2=A0
=

S.



--
<= br>
Best regards,
Kathleen



--

Best regards,
Kathleen
--001a11c36fd222495005012915ce-- From nobody Thu Aug 21 14:57:37 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02141A0B7A for ; Thu, 21 Aug 2014 14:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gFCENWClory for ; Thu, 21 Aug 2014 14:57:27 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED2B1A0B74 for ; Thu, 21 Aug 2014 14:57:26 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id im17so11478492vcb.31 for ; Thu, 21 Aug 2014 14:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SHkz6dA9yO1U1BfauDg5eIPyyn0+dShG4tt4GmnjM/0=; b=BYBqvHKFtnlPgzqIaOrDpV5LStiNCa2DdJjwh5r8DyZ3DS8rfdrcg2zvD5S9Gm78k7 3CfOuPgAKe16DqyVmh+UJwDqqUf5fX/JGHdyziKAePrjgcaRuvxGW6oVJBRv9FgcoTBt J/WAH7uOEJXIOBGDa6xQuRHj+yz7RjONLwH5+S2S2suQ4IILmwBlgp9+MZJqCzzqKq+U 7by6BSj23r1GbHnGH3f2r8VZHDO3R6ZDEHdhNn0K6HTCdUC1eacFPVhq0qO1TmPOgIA/ 4QvFR4LvT95b4lqjZy0ZZpRMaCITayKVOdegsYgXu+ieUAKt1xzSYn3eAnGzzbbNpuT5 IDeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SHkz6dA9yO1U1BfauDg5eIPyyn0+dShG4tt4GmnjM/0=; b=kF/lQlFU5imy4iQ2X5/DsX29sjVk4I6sO1psQRp7a9t/sOWfoarlKJXGtQAxlfKOes GBaqT04jozP+CLCYax4DdwugjWX4o1q1sZTiV/MSclxe93U0sO6olrBrG/rRWpsYUANl p/E8xcxrdjaLZ5CRHtqYfwJi/CctPqi5IKVNKwULEF96QAdmB3mGTucyPt2Jwa12Z/ho naTXsMOGGVBie0U3J2FDg2nxOCOL6HVhiU0TFsaJs7U3u+C12uFmz3tRv6mMdcqBmmSS rVOPgKt30HnOoeesLXJmQbTMN8ZMpFx7m2xoTUJn57XrFruANi+Y5a7KiF4ENiKNWoGd XIXQ== X-Gm-Message-State: ALoCoQkd9opbxuuE0k59l8e12aVQyvGap9HQ4/nJSyGZReYvf/7FtwhvbxxqHQ38cdDOMDh2kHwF MIME-Version: 1.0 X-Received: by 10.220.251.200 with SMTP id mt8mr970023vcb.24.1408658246021; Thu, 21 Aug 2014 14:57:26 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Thu, 21 Aug 2014 14:57:25 -0700 (PDT) In-Reply-To: References: <20140820203127.25270.64032.idtracker@ietfa.amsl.com> <53F50D2D.2010203@qti.qualcomm.com> <53F64D64.8050002@cs.tcd.ie> Date: Thu, 21 Aug 2014 14:57:25 -0700 Message-ID: From: Vincent Chen To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=089e0122f0985d5fb305012ace7d Archived-At: http://mailarchive.ietf.org/arch/msg/paws/GyfLTPq_TYGDxEDeT86ThmBMx18 Cc: "paws-chairs@tools.ietf.org" , Pete Resnick , "paws@ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Kathleen Moriarty's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 21:57:31 -0000 --089e0122f0985d5fb305012ace7d Content-Type: text/plain; charset=UTF-8 Stephen, Kathleen, A Spectrum Database is not a typical database; "full contents" is not well defined. In practice, available spectrum needs to be computed on each query, based on the device's location (and device type) and a host of other stored information about location and spectrum usage of "protected" entities, such as TV stations, wireless mics of theaters, stadiums, etc. The reason to use a Database is not that the data is sensitive in any way, but that the Database has been certified to be able to compute accurate answers, based on algorithms and rules defined by a regulator. There's no other data that can be accessed...it's just the results of its computations. > Just to be clear - As I understand it now, the database may have sensitive information, but the interface via PAWS only > allows access to data that is not sensitive. If you can query it, it is public. If you have database access or other extensions > are written, then it could be possible to get access to sensitive data. As mentioned elsewhere, I will add a statement to Section 8 to put some limits on extensions. -vince On Thu, Aug 21, 2014 at 12:54 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > > > > On Thu, Aug 21, 2014 at 3:51 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> >> >> >> On Thu, Aug 21, 2014 at 3:49 PM, Stephen Farrell < >> stephen.farrell@cs.tcd.ie> wrote: >> >>> >>> Hiya, >>> >>> On 21/08/14 20:44, Kathleen Moriarty wrote: >>> > OK, this isn't my area of expertise, so I didn't read it the same way >>> in >>> > that information was limited to requests of public data. >>> > >>> >>> Nothing really to do with IESG processing of this but I'm >>> curious... >>> >>> Is the full DB information really considered public? >> >> >> I'm glad it wasn't just me ;-) Maybe stating that explicitly would be >> good. >> >> My >>> impression was rather that trying to extract the full DB >>> of information via repeated queries would be frowned upon. >>> >> Just to be clear - As I understand it now, the database may have > sensitive information, but the interface via PAWS only allows access to > data that is not sensitive. If you can query it, it is public. If you > have database access or other extensions are written, then it could be > possible to get access to sensitive data. > >> >>> S. >>> >> >> >> >> -- >> >> Best regards, >> Kathleen >> > > > > -- > > Best regards, > Kathleen > -- -vince --089e0122f0985d5fb305012ace7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --bcaec51b12bdcbc37b05018f9981-- From nobody Fri Aug 29 07:41:14 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779351A0428; Fri, 29 Aug 2014 07:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJ0UVd09H5el; Fri, 29 Aug 2014 07:41:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 014501A0421; Fri, 29 Aug 2014 07:41:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140829144108.28129.36677.idtracker@ietfa.amsl.com> Date: Fri, 29 Aug 2014 07:41:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/vOE2zbllSp485FsJzoTl7hIFhsU Cc: paws@ietf.org, paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org Subject: [paws] Stephen Farrell's No Objection on draft-ietf-paws-protocol-15: (with COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 14:41:10 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-paws-protocol-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for sorting out my discuss points. I didn't fully check the location stuff is now all ok, but I expect that since others had related discuss points it'll be checked more thoroughly (and it looks ok to me too) S. --- old comments below, didn't check if they were handled or not, but feel free to keep chatting about 'em if that's useful - write-up: its a pity that coders haven't gotten together more openly and done interop, but I guess different businesses are different. - section 1, last para: I realise authorized devices is what the WG are interested in, but the protocol ought not require that, so the last sentence here is wrong - it surely should be: s/device is authorized to operate/device operates/ - Ruleset: I hope there's a NULL, meaning "no rules":-) - 4.4.1 - nothing stops a device lying about location, right? - 4.5 - the slave location vs. master location seems unclear to me. Can you clarify? - 4.5.1 - timestamp has to be UTC right? You only seem to indicate that via the "Z" in the timestamp format which I expect could be easily missed. Suggest you emphasise that. You should probably also say if truncated timestamps are ok, for example just to the minute granularity without specifying seconds. I assume that's not allowed? And lastly, please specify if the start (resp. end) of the second (or whatever) unit is when a device gains (resp. looses) spectrum. (Or add a global statement on timezones where you earlier said that identifiers are case sensitive by default.) Some of this is in 5.14, but I'm not sure if that's enough. (It could be.) - 5.2 - I don't get why you need X.520 here. - 5.5 - could a vCard value just be (the moral equivalent of) "Internet" or "I'm not telling"? - section 7: Saying the master device MUST implement server auth is confusing, since the master device is the TLS client, right? - Section 10: Under the privacy bullet you should also recognise that an authorized entity can be privacy invasive (e.g. selling contact information, sending all on to law enforcement without permission). - Section 10: Given diginotar and similar (incl. by nation states), having the master device send its identifying information in its first message means that simply saying "use TLS" is not enough. You need to say "TLS, assuming the PKI used is ok,..." or similar. From nobody Fri Aug 29 09:59:55 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E931A0685 for ; Fri, 29 Aug 2014 09:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QchaJrdkf3A9 for ; Fri, 29 Aug 2014 09:59:52 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063711A0688 for ; Fri, 29 Aug 2014 09:59:51 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id la4so2824497vcb.29 for ; Fri, 29 Aug 2014 09:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5FLpGTjfmFx+y3ACxOLBHC/KvfvkmYBVRxvzS3zsYhk=; b=G0VmZk/E7AOeU6JukJKI3OGlPwcl3j6ZfVjEj3Huxt7SvdNDoweZHU3QG3fMOf9Oi4 v150IwldIC2Y/76tVQGf85TWPZph86UCPH+xA+mttaPCN8UWIfKoRdsHRYkTSZfytzJP +LpR+/ubVze3Pb9xl/3KozvCfPIyNDURfzzm3VlG1P8hnVH1G2R16sUJF0Q8CFrDmKbX nVaL9/bQkUyeB6Hr+Y+ok1CWrMPbH7JR3QYGQr6M+LN+lWoX68lkvvnfwgjMSbk9SmwJ dm13PILeZjC82YVJCH3fy7oEAwAmyMAdNYJRtfbezh0euQDg1HMRlp0Z2zGHG4HHIAgd tkBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5FLpGTjfmFx+y3ACxOLBHC/KvfvkmYBVRxvzS3zsYhk=; b=hh82xzxgJtDMXMLWsJvQ0RSBGP+ITDprblLJdbL4P5Bbidb2VqC/voJmpF8Ilk32rO lVv5MAGQvi/7ALkwZ8c5awIRR97kpYfCLC3ClMK0cg/2nFT4DK5WMLYIIgqubVhPw+F5 cC2v+3sFEXYApEGcIlmI15sS3CJm6jrQMhzrqkW2m6cpptc91tCLeWZTjGsi8vHPU/W3 djPqcOudH2HIQv1gtJSD+aEjKydrN8GHXlLYyyq7D0AlF/OpL4JbShmQA4jO1023faAg 7IPgcpHh5QBd2EB8lSnyV6EoCqSW3BD82P4EDPQIDHAkbxG35hHeTPfWk1YCBr6I4LLN WWxQ== X-Gm-Message-State: ALoCoQkXSw3FhkdLuIojvoVMP0E4J/8cMW1cSlXxgULei/cDx9OsKoIRJS/3jdEy7pzrLUjTQhDu MIME-Version: 1.0 X-Received: by 10.52.15.36 with SMTP id u4mr884076vdc.91.1409331590975; Fri, 29 Aug 2014 09:59:50 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Fri, 29 Aug 2014 09:59:50 -0700 (PDT) In-Reply-To: <20140829144108.28129.36677.idtracker@ietfa.amsl.com> References: <20140829144108.28129.36677.idtracker@ietfa.amsl.com> Date: Fri, 29 Aug 2014 09:59:50 -0700 Message-ID: From: Vincent Chen To: Stephen Farrell Content-Type: multipart/alternative; boundary=20cf3030c505d9edba0501c7940e Archived-At: http://mailarchive.ietf.org/arch/msg/paws/K7MDgFjWsrAIhLPy8_UsnZaM5FM Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Stephen Farrell's No Objection on draft-ietf-paws-protocol-15: (with COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 16:59:54 -0000 --20cf3030c505d9edba0501c7940e Content-Type: text/plain; charset=UTF-8 Stephen, Thanks for the review. Just for the record. I'll respond to each of the comments. On Fri, Aug 29, 2014 at 7:41 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-paws-protocol-15: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > > Thanks for sorting out my discuss points. > > I didn't fully check the location stuff is now all ok, but I > expect that since others had related discuss points > it'll be checked more thoroughly (and it looks ok to > me too) > > S. > > > --- old comments below, didn't check if they were handled or > not, but feel free to keep chatting about 'em if that's useful > > - write-up: its a pity that coders haven't gotten together more > openly and done interop, but I guess different businesses are > different. > FWIW, there are various trials occurring in the UK and I believe participants have been using draft versions of PAWS successfully. > > - section 1, last para: I realise authorized devices is what > the WG are interested in, but the protocol ought not require > that, so the last sentence here is wrong - it surely should > be: s/device is authorized to operate/device operates/ > Done. > > - Ruleset: I hope there's a NULL, meaning "no rules":-) > I don't believe NULL makes sense, since spectrum is a regulated "resource". Devices must always operate according to some rules. - 4.4.1 - nothing stops a device lying about location, right? > Correct. There's a catch-all in Section 10 that we are not trying to protect against rogue devices, since a rogue device can just use spectrum without ever asking a DB. > - 4.5 - the slave location vs. master location seems unclear > to me. Can you clarify? > Done. Added clarifying paragraph to the section. > > - 4.5.1 - timestamp has to be UTC right? You only seem to > indicate that via the "Z" in the timestamp format which I > expect could be easily missed. Suggest you emphasise that. You > should probably also say if truncated timestamps are ok, for > example just to the minute granularity without specifying > seconds. I assume that's not allowed? And lastly, please > specify if the start (resp. end) of the second (or whatever) > unit is when a device gains (resp. looses) spectrum. (Or add a > global statement on timezones where you earlier said that > identifiers are case sensitive by default.) Some of this is in > 5.14, but I'm not sure if that's enough. (It could be.) > Done. Added global statement to Section 4. > > - 5.2 - I don't get why you need X.520 here. > Removed. > > - 5.5 - could a vCard value just be (the moral equivalent of) > "Internet" or "I'm not telling"? > Done. Rearranged description to make it more clear that specific requirements are defined by ruleset in IANA section. > > - section 7: Saying the master device MUST implement server > auth is confusing, since the master device is the TLS client, > right? > Done. Removed and added reference to TLS BCP for guidance. > > - Section 10: Under the privacy bullet you should also > recognise that an authorized entity can be privacy invasive > (e.g. selling contact information, sending all on to law > enforcement without permission). > Done. Added statements regarding privacy policies. > - Section 10: Given diginotar and similar (incl. by nation > states), having the master device send its identifying > information in its first message means that simply saying "use > TLS" is not enough. You need to say "TLS, assuming the PKI > used is ok,..." or similar. > > > Done. Added qualifying phrase. -- -vince --20cf3030c505d9edba0501c7940e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stephen,

Thanks for the review.

Just for the record. I'll respond to each of the comm= ents.


On= Fri, Aug 29, 2014 at 7:41 AM, Stephen Farrell <stephen.farrell@cs= .tcd.ie> wrote:
Stephen Farrell has enter= ed the following ballot position for
draft-ietf-paws-protocol-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/<= br>


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



Thanks for sorting out my discuss points.

I didn't fully check the location stuff is now all ok, but I
expect that since others had related discuss points
it'll be checked more thoroughly (and it looks ok to
me too)

S.


--- old comments below, didn't check if they were handled or
not, but feel free to keep chatting about 'em if that's useful

- write-up: its a pity that coders haven't gotten together more
openly and done interop, but I guess different businesses are
different.

FWIW, there are various tria= ls occurring in the UK and I believe
participants have been using= draft versions of PAWS successfully.
=C2=A0

- section 1, last para: I realise authorized devices is what
the WG are interested in, but the protocol ought not require
that, so the last sentence here is wrong - it surely should
be: s/device is authorized to operate/device operates/

Done.
=C2=A0

- Ruleset: I hope there's a NULL, meaning "no rules":-)

I don't believe NULL makes sense, since = spectrum is a regulated "resource".
Devices must always= operate according to some rules.

- 4.4.1 - nothing stops a device lying about location, right?

Correct. There's a catch-all in Section 10 that = we are not trying to protect against
rogue devices, since a rogue= device can just use spectrum without ever asking a DB.


- 4.5 - the slave location vs. master location seems unclear
to me. Can you clarify?

Done. Added cla= rifying paragraph to the section.
=C2=A0

- 4.5.1 - timestamp has to be UTC right? You only seem to
indicate that via the "Z" in the timestamp format which I
expect could be easily missed. Suggest you emphasise that. You
should probably also say if truncated timestamps are ok, for
example just to the minute granularity without specifying
seconds.=C2=A0 I assume that's not allowed? And lastly, please
specify if the start (resp. end) of the second (or whatever)
unit is when a device gains (resp. looses) spectrum. (Or add a
global statement on timezones where you earlier said that
identifiers are case sensitive by default.) Some of this is in
5.14, but I'm not sure if that's enough. (It could be.)

Done. Added global statement to Section 4.
=C2=A0

- 5.2 - I don't get why you need X.520 here.

<= /div>
Removed.
=C2=A0

- 5.5 - could a vCard value just be (the moral equivalent of)
"Internet" or "I'm not telling"?

Done. Rearranged description to make it more clear that s= pecific requirements
are defined by ruleset in IANA section.
=C2=A0

- section 7: Saying the master device MUST implement server
auth is confusing, since the master device is the TLS client,
right?

Done. Removed and added referenc= e to TLS BCP for guidance.
=C2=A0

- Section 10: Under the privacy bullet you should also
recognise that an authorized entity can be privacy invasive
(e.g. selling contact information, sending all on to law
enforcement without permission).

Done. = Added statements regarding privacy policies.


- Section 10: Given diginotar and similar (incl. by nation
states), having the master device send its identifying
information in its first message means that simply saying "use
TLS" is not enough. You need to say "TLS, assuming the PKI
used is ok,..." or similar.


Done. Added qualifying phrase.=C2=A0

<= br clear=3D"all">

--
-vince --20cf3030c505d9edba0501c7940e--
Stephen, Kathleen,

A Spectrum Database = is not a typical database; "full contents" is not well defined.

In practice, available spectrum needs to be compute= d on each query, based on the device's
location (and device type) and a host of other stored information abou= t location and spectrum usage
of "protected" entities, = such as TV stations, wireless mics of theaters, stadiums, etc.

The reason to use a Database is not that the data is sensiti= ve in any way, but that the Database has
been certified to be= able to compute accurate answers, based on algorithms and rules defined
by a regulator.

There's no other data tha= t can be accessed...it's just the results of its computations.

> Just to be clear - As I understand it now, the database may have sen= sitive information, but the interface via PAWS only
> allow= s access to data that is not sensitive. =C2=A0If you can query it, it is pu= blic. =C2=A0If you have database access or other extensions=C2=A0
> ar= e written, then it could be possible to get access to sensitive data.=C2=A0=

=
As mentioned elsewhere, I will add a statement to Section= 8 to put some limits on extensions.

-vince


On Thu,= Aug 21, 2014 at 12:54 PM, Kathleen Moriarty <kathleen.mor= iarty.ietf@gmail.com> wrote:



On Thu, Aug 2= 1, 2014 at 3:51 PM, Kathleen Moriarty <kathleen.moriarty.ie= tf@gmail.com> wrote:



On Thu, Aug 21, 2014 at 3:49 PM= , Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:=

Hiya,

On 21/08/14 20:44, Kathleen Moriarty wrote:
> OK, this isn't my area of expertise, so I didn't read it the s= ame way in
> that information was limited to requests of public data.
>

Nothing really to do with IESG processing of this but I'm
curious...

Is the full DB information really considered public?

=
I'm glad it wasn't just me ;-) =C2=A0Maybe stating= that explicitly would be good.=C2=A0

My
impression was rather that trying to extract the full DB
of information via repeated queries would be frowned upon.
=
Just to be clear - As= I understand it now, the database may have sensitive information, but the = interface via PAWS only allows access to data that is not sensitive. =C2=A0= If you can query it, it is public. =C2=A0If you have database access or oth= er extensions are written, then it could be possible to get access to sensi= tive data.=C2=A0
=

S.


--

Best regard= s,
Kathleen


--

Best reg= ards,
Kathleen



--
-vince
--089e0122f0985d5fb305012ace7d-- From nobody Thu Aug 21 16:32:06 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C295A1A6F62; Thu, 21 Aug 2014 16:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oKnlMK8NsFd; Thu, 21 Aug 2014 16:32:03 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 128EC1A6EF8; Thu, 21 Aug 2014 16:32:02 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id 79so8181247ykr.8 for ; Thu, 21 Aug 2014 16:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y9P0F/hm5X9eZ7sD2rQ6vkUh5lr0WCrvAgPK+SmiSds=; b=SoWRntxkIU4XMePRPtun/U6S2xTOl8zV/pXIV9RbYTpQJOgFRVEqhaItBwiMQEJPg4 ux+vz9HSbo1WqFwqUjmUHZMbU12HzWThkF/nroEtVBdrudj6Z011Pi3caTy/zHF6zK56 0V7VxtemiToE2CbAUFO6hZ3EEj8mgYy8pQFLc6cCBcw/utgaIyPe7occaNSY9OG5zojb 04LIVs9hKI2DDMf/0/Etfw3ABXyHr7nAPIFMxxX6OVh8BYMz4qWwzQntRImfXGdT00Fd U1OPBlJDr3fRHlTSxc74pLuFzByvwaQ9Re+ld5PItDtILrG8pB7CnAgEGxjDOwYC02Pz TTEA== MIME-Version: 1.0 X-Received: by 10.236.65.133 with SMTP id f5mr2330065yhd.66.1408663922368; Thu, 21 Aug 2014 16:32:02 -0700 (PDT) Received: by 10.170.161.214 with HTTP; Thu, 21 Aug 2014 16:32:02 -0700 (PDT) In-Reply-To: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 16:32:02 -0700 Message-ID: From: Gabor Bajko To: Alissa Cooper Content-Type: multipart/alternative; boundary=001a11c3d980b3761105012c20c2 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/3KE0VPR1xT7JqDlzppu201xoUlg Cc: "paws@ietf.org" , paws-chairs@tools.ietf.org, The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 23:32:05 -0000 --001a11c3d980b3761105012c20c2 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 20, 2014 at 9:52 AM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-paws-protocol-14: Discuss > > When responding, please keep the subject line intact and reply to all > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm glad this work is being done in the IETF, thanks for all your > effort. > > A couple of my points below have overlaps with some of Stephen's points. > > = Shepherd write-up = > "Yes, there were 2 IPR disclosures filed that reference this document. > They were discussed in the WG, and nobody came forward to say that they'd > like to change anything in the document because of the disclosures." > > But there are 3 IPR disclosures in the tracker, not 2. Were all three > discussed in the WG? > > This 3rd IPR disclosure seems to have surfaced 2 months after the shepherd write-up, that is why it is not mentioned in the write-up. I think the best we can do now is to consult the WG about this disclosure in parallel with the iesg evaluations. Gabor --001a11c3d980b3761105012c20c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Aug 20, 2014 at 9:52 AM, Alissa Cooper &l= t;alissa@cooperw.in<= /a>> wrote:
Alissa Cooper has entered the following ball= ot position for
draft-ietf-paws-protocol-14: Discuss

When responding, please keep the subject line intact and reply to all
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm glad this work is being done in the IETF, thanks for all your
effort.

A couple of my points below have overlaps with some of Stephen's points= .

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

This =C2=A03rd IPR disclosure seems to have surfaced = 2 months after the shepherd write-up, that is why it is not mentioned in th= e write-up.
I think the best we can do now is to consult the WG a= bout this disclosure in parallel with the iesg evaluations.
Gabor
--001a11c3d980b3761105012c20c2-- From nobody Thu Aug 21 17:30:47 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699F51A8750 for ; Thu, 21 Aug 2014 17:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHHOHl3kc3zC for ; Thu, 21 Aug 2014 17:30:43 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29DA1A8758 for ; Thu, 21 Aug 2014 17:30:40 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id hy10so11643391vcb.32 for ; Thu, 21 Aug 2014 17:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=twrZmDFZUXvDiFvBQ/zAkgED5Z7UflBeleM0xe2EHYc=; b=e6lxhRMTvDoqKR5YJBH281joQT85plZ24pBKxcBFr8XlVu1rI7mc4pv2KUSIJq8tke NJnm6lfdRTzcluO3/IwczqaFU/Pb17MWbYIwFqJQyJjV5lnGqHa0Z7jOgSzMutgqipPj SE6gCs0mD9+ooXZhH1K39xoWzYv5415hneAnK27RdF449D31LfRx9mc6yy2eSyTazzxW U7oAoXRPpd/uEokQ10llpt0+V6ujcDQ6/pK+nyRxpLadI5xSZ3AtAj2SVTZ3hPRB85Ui ctuAPWYng7kEul8N52DAyIFgpSqfm26XeGJKPzWum9zbtt1TZyIpFQ4+wTBCnx9gBiua DWfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=twrZmDFZUXvDiFvBQ/zAkgED5Z7UflBeleM0xe2EHYc=; b=S7kwMbmxYkwCIYsPO4ljTiqMzb9u06zUWOWDd435kchyOWKgBfQOK/n/XnU/vOJ9i9 MEMv/ZQOAgNLNhwNdD4HX+3qckw/Lq2S8LiuVFo3JxVNSrwZN485jTwcUaz9MHo4KTqZ iBcagIkIotmYQu213+qNLzKlL9NIUAZdpRrSK2gstDajVR0v+yaDTGQFzg2w9OU8oi4C EeSC6Ai9sulSvjZs09PZPq8Sm5G34gT74nEzTQo7Ke6yvpSIaEgIjfrAH37mJUtkzt99 NTiDEjczQeJhpBvzNtBk+82z0wwMZQL8zN72+m25Wj/2Pn1FeuvfHchAl10tGVxtfnKA VlKA== X-Gm-Message-State: ALoCoQkrFhWClp2rZ/r8w+mKPPeKfBoZVJ5VsvXk6tGMlQwTBW8cSWUuJesZnbBgGCImYVyrx/N0 MIME-Version: 1.0 X-Received: by 10.220.44.80 with SMTP id z16mr1447553vce.7.1408667439877; Thu, 21 Aug 2014 17:30:39 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Thu, 21 Aug 2014 17:30:39 -0700 (PDT) In-Reply-To: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 17:30:39 -0700 Message-ID: From: Vincent Chen To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7b34313c5c700d05012cf2c7 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/RpRG1ID6Qp0Vog8MZnnBEj-qeRk Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 00:30:46 -0000 --047d7b34313c5c700d05012cf2c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ted, Thanks for the review. On Thu, Aug 21, 2014 at 6:30 AM, Ted Lemon wrote: > Ted Lemon has entered the following ballot position for > draft-ietf-paws-protocol-14: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is a cool document=E2=80=94I'm glad the IETF is working on this. P= lease > don't take the following comments as anything other than an attempt to > address what I think are some relatively minor issues with the document, > hopefully easily addressed. > > 4.1 says "Some regulatory domains may have specific rules regarding how > long the spectrum data remains valid in these cases." It might be worth > adding that in such cases the initialization procedure is required. > This is addressed to some extent in section 4.3, but I'm not sure it's > completely addressed. The potential problem I see is that a device > might be used in a regulatory regime where this is required, but might > have pre-configured values for some other regulatory regime. If these > values are not valid in the regime that applies for its current location, > it might have a too-long refresh interval configured, fail to detect that > this is the case, and as a result accidentally break the law. Can a > scenario like this occur in practice? > It should not occur in practice for well-behaved devices. When it is preconfigured, there must be a preconfigured value for each ruleset. Of course, a device may choose to use preconfigured values for only a subse= t of the rulesets it supports. Note that, in practice, a device needs to be certified for each "ruleset" b= y whatever process is defined by each applicable regulatory body, so that any preconfigured values will be certified to be compliant. > > Section 5.2 says that the manufacturer ID and model ID are optional, but > may be required by some rulesets. Section 4.3.1 does not say what error > is returned when a deviceDesc that does not contain one or both of these > parameters is sent to the server, but the matching ruleset requires > either parameter. I suspect the answer is straightforward, but I think > it needs to be stated explicitly in 4.3.1. E.g., if the optional but > required parameters are accepted in the initialization but rejected in > the registration, it would be good to say so explicitly. > OK. In these cases, the Database should return the MISSING error, with additional data specifying the missing fields. > > In 4.4.2, I think that if none of the rulesets are accepted, the intent > is that the database should return a REGISTRATION_RESP with the error > element, and will not return a rulesetInfos list. However, the > specification does not make an exception for this case when it says "A > RulesetInfo list MUST be included" and "The list MUST contain at least > one entry". I can't think of another valid interpretation, but you've > stated a MUST, so you need to say that it doesn't apply in the case of > the error. > Ah, right. There is language from INIT_RESP that needs to be repeated here. If the Database does not support the device or any of the rulesets specified in the DeviceDescriptor, it MUST instead return an error with the UNSUPPORTED (Table 1) code in the error response. > In 4.5: > > If some > locations within a batch request are outside the regulatory > domain supported by the Database, the Database MAY return an OK > response with available spectrum for only the valid locations; > otherwise, if all locations within a batch request are outside > the regulatory domain, the Database MUST respond with an > OUTSIDE_COVERAGE error. > > What should the database do if it doesn't follow the MAY? Should it > return an OUTSIDE_COVERAGE error? It seems to me that this MAY is going > to require some unclear heuristics on the side of the master device. > Why isn't this a MUST? I think if this were a MUST, it would be clear > how implementations should behave; by making it a MAY, there's a big gap > that I think will lead to interoperability problems as different > implementors make different choices about how to treat this situation. > If it does not follow MAY, the assumption is that it would return OUTSIDE_COVERAGE error. I take your point about it being harder to use for the device. I don't think there would be objections to changing this to a MUST. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 3 describes spectrum-usage messages as purely informational. > Section 4.5 says that the database can require that such messages be > sent. Which is it: is it sometimes required, or always purely > informational? Or does "purely informational" just mean that the > protocol provides no mechanism for tracking such notifications? It would > be helpful if this were clearer. > "purely informational" means that the it's just notifying the Database what spectrum it intends to use and is not a request to the Database to get permission to use that spectrum. Some regulators require this notification. I'll try to clarify the text. > In 4.1, the database URI change spec seems incomplete. Is there a time > when a database starts announcing its URI change after which it need no > longer provide service on the old URI? I see Alissa asked a similar > question, so I imagine you could address both questions together. > Yes, specifying a time is reasonable. > > In 4.1 and 5.17, the meaning described for UNSUPPORTED appears to be > somewhat fluid. I think you intend for it to mean one specific thing, > which might imply one of several other things. But you don't say the > one thing that it means: instead you mention possible implications. It > would be helpful to try to make this more explicit. > OK. UNSUPPORTED means that the Database does not support the device (based on it type, model, etc.) or any rulesets indicated by the Device. I'll update both. > I think Stephen noticed this same problem, but to be clear, it appears > that section 4.5 says that when the master is sending a request on behalf > of a slave, it sends its own location. But section 4.5.1 says that the > master sends the slave's location. It appears that there are two > parameters, one being the master location, which is required, and the > other being the slave location, which is optional. However, this is > never really stated explicitly; it might be helpful if it were. > Yes. I'll try to clean that up. > > I have to confess that the use of "master" and "slave" throughout this > document makes me quite uncomfortable in reading it. It would really be > preferable to use terms that have less painful history associated with > them, like "core" and "leaf" or "coordinator" and "supplicant." I > realize this is a matter of taste, and I do not at all mean to suggest > that there's anything wrong with the use of these terms, which are > certainly common in the computing industry. This is just a comment, and > whether you address it is entirely up to you. > This results from the terminology established in RFC6953. > > In 4.6.1, it would help to have text that explains what it means to > validate a device. It's certainly not required for interoperability, > but might be helpful for implementors of database servers. > This is explained in the first paragraph of 4.6, I think. A Slave Device needs a Master Device to ask the Database on its behalf for available spectrum. Depending on the ruleset, the Master Device also must validate with the Database that the Slave Device is permitted to operate. ... > In 5.3, it's a little puzzling that antenna direction, radiation pattern, > gain and polarization aren't defined, because they seem like properties > that should have universal applicability, even if they are not required > in all cases. Is this being left as future work, or is there some more > subtle reason why these haven't been defined explicitly? > This is for future extension, rather than defining a whole set of things that won't get used. Note that for mobile devices, direction/pattern/polarizatio= n changes all the time and would be "crazy" to define rules based on these characteristics. > > In 5.11, power is expressed in dbm, which leads me to wonder if this is > the product of the antenna gain and the input power to the output > amplifier, or whether it's just the input power to the amplifier, or > whether it's being left intentionally ambiguous. > Great question. I believe this was left intentionally ambiguous, since each regulator may choose to define the power in a different way. Typically, it's the radiated power at the antenna, over some bandwidth, averaged over some period of time (defined by the regulator). Perhaps I should add the "Typically" statement to Section 5.11 that describes Spectrum. > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > --=20 -vince --047d7b34313c5c700d05012cf2c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ted,

Thanks for the review.=C2=A0
=


On Thu, Aug 2= 1, 2014 at 6:30 AM, Ted Lemon <ted.lemon@nominum.com> wr= ote:
Ted Lemon has entered the following ballot position for draft-ietf-paws-protocol-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/<= br>


----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is a cool document=E2=80=94I'm glad the IETF is working on this.= =C2=A0 =C2=A0Please
don't take the following comments as anything other than an attempt to<= br> address what I think are some relatively minor issues with the document, hopefully easily addressed.

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

I= t should not occur in practice for well-behaved devices.

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

Note= that, in practice, a device needs to be certified for each "ruleset&q= uot; by
whatever process is defined by each applicable regulatory body, so tha= t
any preconfigured values will be certified to be complian= t.

=C2=A0

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

OK. In these cases, the Database should return the MISSIN= G error, with
additional data specifying the missing fields.
=C2=A0

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

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

= =C2=A0 =C2=A0 =C2=A0 =C2=A0If the Database does not support the device or a= ny of the rulesets
=C2=A0 =C2=A0 =C2=A0 specified in the DeviceDescriptor, it MUST instea= d return an error
=C2=A0 =C2=A0 =C2=A0 with the UNSUPPORTED (Tabl= e 1) code in the error response.


In 4.5:

=C2=A0 =C2=A0 =C2=A0 =C2=A0If some
=C2=A0 =C2=A0 =C2=A0 =C2=A0locations within a batch request are outside the= regulatory
=C2=A0 =C2=A0 =C2=A0 =C2=A0domain supported by the Database, the Database M= AY return an OK
=C2=A0 =C2=A0 =C2=A0 =C2=A0response with available spectrum for only the va= lid locations;
=C2=A0 =C2=A0 =C2=A0 =C2=A0otherwise, if all locations within a batch reque= st are outside
=C2=A0 =C2=A0 =C2=A0 =C2=A0the regulatory domain, the Database MUST respond= with an
=C2=A0 =C2=A0 =C2=A0 =C2=A0OUTSIDE_COVERAGE error.

What should the database do if it doesn't follow the MAY?=C2=A0 =C2=A0S= hould it
return an OUTSIDE_COVERAGE error?=C2=A0 =C2=A0It seems to me that this MAY = is going
to require some unclear heuristics on the side of the master device.
Why isn't this a MUST?=C2=A0 =C2=A0I think if this were a MUST, it woul= d be clear
how implementations should behave; by making it a MAY, there's a big ga= p
that I think will lead to interoperability problems as different
implementors make different choices about how to treat this situation.
<= /blockquote>

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

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

=C2=A0


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

Section 3 describes spectrum-usage messages as purely informational.
Section 4.5 says that the database can require that such messages be
sent.=C2=A0 =C2=A0Which is it: is it sometimes required, or always purely informational?=C2=A0 =C2=A0Or does "purely informational" just me= an that the
protocol provides no mechanism for tracking such notifications?=C2=A0 It wo= uld
be helpful if this were clearer.

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

I'll try to clarify the text.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
In 4.1, the database URI change spec seems incomplete.=C2=A0 =C2=A0Is there= a time
when a database starts announcing its URI change after which it need no
longer provide service on the old URI?=C2=A0 =C2=A0I see Alissa asked a sim= ilar
question, so I imagine you could address both questions together.

Yes, specifying a time is reasonable.
= =C2=A0

In 4.1 and 5.17, the meaning described for UNSUPPORTED appears to be
somewhat fluid.=C2=A0 =C2=A0I think you intend for it to mean one specific = thing,
which might imply one of several other things.=C2=A0 =C2=A0But you don'= t say the
one thing that it means: instead you mention possible implications.=C2=A0 = =C2=A0It
would be helpful to try to make this more explicit.
OK. UNSUPPORTED means that
the Database does not sup= port the device (based on it type, model, etc.) or=C2=A0
any rule= sets indicated by the Device. I'll update both.


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

Yes. I'll try to clean that up.
=C2= =A0

I have to confess that the use of "master" and "slave" = throughout this
document makes me quite uncomfortable in reading it.=C2=A0 =C2=A0It would r= eally be
preferable to use terms that have less painful history associated with
them, like "core" and "leaf" or "coordinator"= and "supplicant."=C2=A0 =C2=A0I
realize this is a matter of taste, and I do not at all mean to suggest
that there's anything wrong with the use of these terms, which are
certainly common in the computing industry.=C2=A0 =C2=A0This is just a comm= ent, and
whether you address it is entirely up to you.

This results from the terminology established in RFC6953.
= =C2=A0=C2=A0

In 4.6.1, it would help to have text that explains what it means to
validate a device.=C2=A0 =C2=A0It's certainly not required for interope= rability,
but might be helpful for implementors of database servers.
=

This is explained in the first paragraph of 4.6, I thin= k.

=C2=A0 =C2=A0A Slave Device needs a Master Devi= ce to ask the Database on its
=C2=A0 =C2=A0behalf for available spectrum. =C2=A0Depending on the rul= eset, the Master
=C2=A0 =C2=A0Device also must validate with the = Database that the Slave Device is
=C2=A0 =C2=A0permitted to opera= te. ...


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

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

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

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

Perhaps I should = add the "Typically" statement to Section 5.11 that describes Spec= trum.=C2=A0
=C2=A0


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



--
-vince
--047d7b34313c5c700d05012cf2c7-- From nobody Thu Aug 21 18:06:28 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DE61A8754; Thu, 21 Aug 2014 18:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpYMsLeyYpVY; Thu, 21 Aug 2014 18:06:18 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8C41A8750; Thu, 21 Aug 2014 18:06:17 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9B2411B8657; Thu, 21 Aug 2014 18:06:17 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 18D6453E070; Thu, 21 Aug 2014 18:06:12 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 21 Aug 2014 18:06:12 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Thu, 21 Aug 2014 21:06:09 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> To: Vincent Chen X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/K9jQYCZVNc6-QhAEPPfByES7kXA Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 01:06:21 -0000 On Aug 21, 2014, at 8:30 PM, Vincent Chen wrote: >> 4.1 says "Some regulatory domains may have specific rules regarding = how >> long the spectrum data remains valid in these cases." It might be = worth >> adding that in such cases the initialization procedure is required. >> This is addressed to some extent in section 4.3, but I'm not sure = it's >> completely addressed. The potential problem I see is that a device >> might be used in a regulatory regime where this is required, but = might >> have pre-configured values for some other regulatory regime. If = these >> values are not valid in the regime that applies for its current = location, >> it might have a too-long refresh interval configured, fail to detect = that >> this is the case, and as a result accidentally break the law. Can a >> scenario like this occur in practice? >=20 > It should not occur in practice for well-behaved devices. >=20 > When it is preconfigured, there must be a preconfigured value for each = ruleset. > Of course, a device may choose to use preconfigured values for only a = subset > of the rulesets it supports. >=20 > Note that, in practice, a device needs to be certified for each = "ruleset" by > whatever process is defined by each applicable regulatory body, so = that > any preconfigured values will be certified to be compliant. If this is how it works, shouldn't the document say so? Or was that in = the requirements document? I admit it's been a while since I read it. = :) > In 4.4.2, I think that if none of the rulesets are accepted, the = intent > is that the database should return a REGISTRATION_RESP with the error > element, and will not return a rulesetInfos list. However, the > specification does not make an exception for this case when it says "A > RulesetInfo list MUST be included" and "The list MUST contain at = least > one entry". I can't think of another valid interpretation, but = you've > stated a MUST, so you need to say that it doesn't apply in the case of > the error. >=20 > Ah, right. There is language from INIT_RESP that needs to be repeated = here. >=20 > If the Database does not support the device or any of the = rulesets > specified in the DeviceDescriptor, it MUST instead return an = error > with the UNSUPPORTED (Table 1) code in the error response. That doesn't fix it, though=97you need to fix the other MUST to say = "unless there's an error" or words to that effect. > In 4.5: >=20 > If some > locations within a batch request are outside the regulatory > domain supported by the Database, the Database MAY return an OK > response with available spectrum for only the valid locations; > otherwise, if all locations within a batch request are outside > the regulatory domain, the Database MUST respond with an > OUTSIDE_COVERAGE error. >=20 > What should the database do if it doesn't follow the MAY? Should it > return an OUTSIDE_COVERAGE error? It seems to me that this MAY is = going > to require some unclear heuristics on the side of the master device. > Why isn't this a MUST? I think if this were a MUST, it would be = clear > how implementations should behave; by making it a MAY, there's a big = gap > that I think will lead to interoperability problems as different > implementors make different choices about how to treat this situation. >=20 > If it does not follow MAY, the assumption is that it would return = OUTSIDE_COVERAGE error. > I take your point about it being harder to use for the device. >=20 > I don't think there would be objections to changing this to a MUST. That would certainly satisfy my concern! :) > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Section 3 describes spectrum-usage messages as purely informational. > Section 4.5 says that the database can require that such messages be > sent. Which is it: is it sometimes required, or always purely > informational? Or does "purely informational" just mean that the > protocol provides no mechanism for tracking such notifications? It = would > be helpful if this were clearer. >=20 > "purely informational" means that the it's just notifying the Database = what > spectrum it intends to use and is not a request to the Database to get = permission > to use that spectrum. Some regulators require this notification. >=20 > I'll try to clarify the text. Ah, that explains it. Thanks. Adding some text pretty much like what = you just wrote would address this comment nicely. > I have to confess that the use of "master" and "slave" throughout this > document makes me quite uncomfortable in reading it. It would really = be > preferable to use terms that have less painful history associated with > them, like "core" and "leaf" or "coordinator" and "supplicant." I > realize this is a matter of taste, and I do not at all mean to suggest > that there's anything wrong with the use of these terms, which are > certainly common in the computing industry. This is just a comment, = and > whether you address it is entirely up to you. >=20 > This results from the terminology established in RFC6953. I guess I should have complained sooner... :} > In 4.6.1, it would help to have text that explains what it means to > validate a device. It's certainly not required for interoperability, > but might be helpful for implementors of database servers. >=20 > This is explained in the first paragraph of 4.6, I think. >=20 > A Slave Device needs a Master Device to ask the Database on its > behalf for available spectrum. Depending on the ruleset, the = Master > Device also must validate with the Database that the Slave Device = is > permitted to operate. ... Ah, okay. The problem is that "validate the device" isn't obviously = connected to "validate with the database that the ..." I see the = connection now, but it would help to make it clearer. =20 > In 5.3, it's a little puzzling that antenna direction, radiation = pattern, > gain and polarization aren't defined, because they seem like = properties > that should have universal applicability, even if they are not = required > in all cases. Is this being left as future work, or is there some = more > subtle reason why these haven't been defined explicitly? >=20 > This is for future extension, rather than defining a whole set of = things that > won't get used. Note that for mobile devices, = direction/pattern/polarization > changes all the time and would be "crazy" to define rules based on = these > characteristics.=20 Right, just checking. > In 5.11, power is expressed in dbm, which leads me to wonder if this = is > the product of the antenna gain and the input power to the output > amplifier, or whether it's just the input power to the amplifier, or > whether it's being left intentionally ambiguous. >=20 > Great question. >=20 > I believe this was left intentionally ambiguous, since each regulator = may choose to define > the power in a different way. Typically, it's the radiated power at = the > antenna, over some bandwidth, averaged over some period of time = (defined by the regulator). >=20 > Perhaps I should add the "Typically" statement to Section 5.11 that = describes Spectrum.=20 The problem with this is that if the meaning of the unit is different = depending on the regulatory regime, it might make life really difficult = for the maker of a device that has to operate in different regimes. I = suppose makers of devices like this are used to this problem, so maybe = it's not really a problem in practice, but it would certainly be nice to = talk a bit about this in the document. Thanks for the quick response! From nobody Fri Aug 22 00:04:19 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F271A00ED for ; Fri, 22 Aug 2014 00:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zqr7l-zyvZow for ; Fri, 22 Aug 2014 00:04:00 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8DA1A00EC for ; Fri, 22 Aug 2014 00:03:59 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id le20so11985550vcb.14 for ; Fri, 22 Aug 2014 00:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SCRY1LEK3YgsQ5JTVPnyttKzbxvyU6TIxnLEMCiPmfc=; b=bmL8Qf7FwUQiQ7p06tetYA74gjy73Q3wX3O+csvRiWDz28T8MQhDt+3YNAZcKHrcFb Q0B2Ke8jqQ+uw5D+3t6j+wpOue8kFC0XW+jgUAG3Q9Lqe14sE1SihaPyMiBABT3UNBOR WtAMPqQnV4VlOeevzU3TUpvcTrqucZ3AJshyNSm3we4IV2zTlCDaW+tnG7NgQscpCq22 t4rPZ7ALVN64Tay0lpilwjvBj0Gg0Qd5tZhH94ZtAI8Jc6ja3agUs9C4ZBVk7awLB96R XfQkg16s7Tpu52GCk54GmrA5M0gEWh9Yi4hH2chWp5a+e2p1SPr2BhTgftJKINqelXiy yfTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SCRY1LEK3YgsQ5JTVPnyttKzbxvyU6TIxnLEMCiPmfc=; b=imSdAlSsgvh8eF2AeHwqwSqgy6DU6wZQGunbJPIREXse8EIGh+59h2kAphV4iWw1xo 3cI3azEigSyCbOpfZEgieVkdBT9F4EtiG2SkcZM8dcRGFK5/LB18dCd9kMPckwshSASQ 0o/zdiHrdrMKYYczz/dWxE26AwWpZW9yeuNR3PNU+c2RAgC4LKXsuCxJ1o1T9RorEfsJ OtEQd3HoVlTjPtf/Q/RJVJajyicvdalYgNq6QKN8bPl4AParjHAYrHPtGpijIGB8e3uK 4DhVLbW5kFfdFFqeGwAwN+IQAfD+Rlxb8RjizpFoVixA3sspC1Y4GNBNQC4QA3WlzwBB hWNw== X-Gm-Message-State: ALoCoQlvL3hvzbdd5jf787xWMGAoK3nESErgkXFun5SxaD8aaX81JzRrppA9aJpb1Ll4w/1Cb2UH MIME-Version: 1.0 X-Received: by 10.52.69.172 with SMTP id f12mr469131vdu.9.1408691038412; Fri, 22 Aug 2014 00:03:58 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Fri, 22 Aug 2014 00:03:58 -0700 (PDT) In-Reply-To: <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> Date: Fri, 22 Aug 2014 00:03:58 -0700 Message-ID: From: Vincent Chen To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf307cffd6f1887b05013270f8 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/m_y67iyHXOFwsggSXKHi_I_sLg0 Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 07:04:04 -0000 --20cf307cffd6f1887b05013270f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 21, 2014 at 6:06 PM, Ted Lemon wrote: > On Aug 21, 2014, at 8:30 PM, Vincent Chen wrote: > >> 4.1 says "Some regulatory domains may have specific rules regarding ho= w > >> long the spectrum data remains valid in these cases." It might be > worth > >> adding that in such cases the initialization procedure is required. > >> This is addressed to some extent in section 4.3, but I'm not sure it's > >> completely addressed. The potential problem I see is that a device > >> might be used in a regulatory regime where this is required, but might > >> have pre-configured values for some other regulatory regime. If thes= e > >> values are not valid in the regime that applies for its current > location, > >> it might have a too-long refresh interval configured, fail to detect > that > >> this is the case, and as a result accidentally break the law. Can a > >> scenario like this occur in practice? > > > > It should not occur in practice for well-behaved devices. > > > > When it is preconfigured, there must be a preconfigured value for each > ruleset. > > Of course, a device may choose to use preconfigured values for only a > subset > > of the rulesets it supports. > > > > Note that, in practice, a device needs to be certified for each > "ruleset" by > > whatever process is defined by each applicable regulatory body, so that > > any preconfigured values will be certified to be compliant. > > If this is how it works, shouldn't the document say so? Or was that in > the requirements document? I admit it's been a while since I read it. := ) > I'll clarify the text some. Note, however, that INIT_RESP return these values as part of a RulesetInfo structure, so that it is implied that preconfiguration also must be on a per-ruleset basis. > > > In 4.4.2, I think that if none of the rulesets are accepted, the intent > > is that the database should return a REGISTRATION_RESP with the error > > element, and will not return a rulesetInfos list. However, the > > specification does not make an exception for this case when it says "A > > RulesetInfo list MUST be included" and "The list MUST contain at least > > one entry". I can't think of another valid interpretation, but you've > > stated a MUST, so you need to say that it doesn't apply in the case of > > the error. > > > > Ah, right. There is language from INIT_RESP that needs to be repeated > here. > > > > If the Database does not support the device or any of the rulese= ts > > specified in the DeviceDescriptor, it MUST instead return an erro= r > > with the UNSUPPORTED (Table 1) code in the error response. > > That doesn't fix it, though=E2=80=94you need to fix the other MUST to say= "unless > there's an error" or words to that effect. > Actually, REGISTRATION_RESP is returned only when there is not error, so if it is returned, it must have one or more entries. The "it MUST instead return an error" should suffice to clarify this? > > > In 4.5: > > > > If some > > locations within a batch request are outside the regulatory > > domain supported by the Database, the Database MAY return an OK > > response with available spectrum for only the valid locations; > > otherwise, if all locations within a batch request are outside > > the regulatory domain, the Database MUST respond with an > > OUTSIDE_COVERAGE error. > > > > What should the database do if it doesn't follow the MAY? Should it > > return an OUTSIDE_COVERAGE error? It seems to me that this MAY is goi= ng > > to require some unclear heuristics on the side of the master device. > > Why isn't this a MUST? I think if this were a MUST, it would be clear > > how implementations should behave; by making it a MAY, there's a big ga= p > > that I think will lead to interoperability problems as different > > implementors make different choices about how to treat this situation. > > > > If it does not follow MAY, the assumption is that it would return > OUTSIDE_COVERAGE error. > > I take your point about it being harder to use for the device. > > > > I don't think there would be objections to changing this to a MUST. > > That would certainly satisfy my concern! :) > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 3 describes spectrum-usage messages as purely informational. > > Section 4.5 says that the database can require that such messages be > > sent. Which is it: is it sometimes required, or always purely > > informational? Or does "purely informational" just mean that the > > protocol provides no mechanism for tracking such notifications? It wou= ld > > be helpful if this were clearer. > > > > "purely informational" means that the it's just notifying the Database > what > > spectrum it intends to use and is not a request to the Database to get > permission > > to use that spectrum. Some regulators require this notification. > > > > I'll try to clarify the text. > > Ah, that explains it. Thanks. Adding some text pretty much like what > you just wrote would address this comment nicely. > Will do. > > > I have to confess that the use of "master" and "slave" throughout this > > document makes me quite uncomfortable in reading it. It would really = be > > preferable to use terms that have less painful history associated with > > them, like "core" and "leaf" or "coordinator" and "supplicant." I > > realize this is a matter of taste, and I do not at all mean to suggest > > that there's anything wrong with the use of these terms, which are > > certainly common in the computing industry. This is just a comment, a= nd > > whether you address it is entirely up to you. > > > > This results from the terminology established in RFC6953. > > I guess I should have complained sooner... :} > > > In 4.6.1, it would help to have text that explains what it means to > > validate a device. It's certainly not required for interoperability, > > but might be helpful for implementors of database servers. > > > > This is explained in the first paragraph of 4.6, I think. > > > > A Slave Device needs a Master Device to ask the Database on its > > behalf for available spectrum. Depending on the ruleset, the Master > > Device also must validate with the Database that the Slave Device is > > permitted to operate. ... > > Ah, okay. The problem is that "validate the device" isn't obviously > connected to "validate with the database that the ..." I see the > connection now, but it would help to make it clearer. > Will do. > > > In 5.3, it's a little puzzling that antenna direction, radiation patter= n, > > gain and polarization aren't defined, because they seem like properties > > that should have universal applicability, even if they are not required > > in all cases. Is this being left as future work, or is there some mor= e > > subtle reason why these haven't been defined explicitly? > > > > This is for future extension, rather than defining a whole set of thing= s > that > > won't get used. Note that for mobile devices, > direction/pattern/polarization > > changes all the time and would be "crazy" to define rules based on thes= e > > characteristics. > > Right, just checking. > > > In 5.11, power is expressed in dbm, which leads me to wonder if this is > > the product of the antenna gain and the input power to the output > > amplifier, or whether it's just the input power to the amplifier, or > > whether it's being left intentionally ambiguous. > > > > Great question. > > > > I believe this was left intentionally ambiguous, since each regulator > may choose to define > > the power in a different way. Typically, it's the radiated power at the > > antenna, over some bandwidth, averaged over some period of time (define= d > by the regulator). > > > > Perhaps I should add the "Typically" statement to Section 5.11 that > describes Spectrum. > > The problem with this is that if the meaning of the unit is different > depending on the regulatory regime, it might make life really difficult f= or > the maker of a device that has to operate in different regimes. I suppo= se > makers of devices like this are used to this problem, so maybe it's not > really a problem in practice, but it would certainly be nice to talk a bi= t > about this in the document. > I'll add it to the doc. > > Thanks for the quick response! > > --=20 -vince --20cf307cffd6f1887b05013270f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 21, 2014 at 6:06 PM, Ted Lemon <Ted.Lemon@nominum.= com> wrote:
On Aug 21, 2014, at 8:30 PM,= Vincent Chen <vchen@google.com&= gt; wrote:
>> 4.1 says "Some regulatory domains may have specific rules reg= arding how
>> long the spectrum data remains valid in these cases."=C2=A0 = =C2=A0It might be worth
>> adding that in such cases the initialization procedure is required= .
>> This is addressed to some extent in section 4.3, but I'm not s= ure it's
>> completely addressed.=C2=A0 =C2=A0The potential problem I see is t= hat a device
>> might be used in a regulatory regime where this is required, but m= ight
>> have pre-configured values for some other regulatory regime.=C2=A0= =C2=A0If these
>> values are not valid in the regime that applies for its current lo= cation,
>> it might have a too-long refresh interval configured, fail to dete= ct that
>> this is the case, and as a result accidentally break the law.=C2= =A0 =C2=A0Can a
>> scenario like this occur in practice?
>
> It should not occur in practice for well-behaved devices.
>
> When it is preconfigured, there must be a preconfigured value for each= ruleset.
> Of course, a device may choose to use preconfigured values for only a = subset
> of the rulesets it supports.
>
> Note that, in practice, a device needs to be certified for each "= ruleset" by
> whatever process is defined by each applicable regulatory body, so tha= t
> any preconfigured values will be certified to be compliant.

If this is how it works, shouldn't the document say so?=C2=A0 =C2= =A0Or was that in the requirements document?=C2=A0 =C2=A0I admit it's b= een a while since I read it. :)

I'l= l clarify the text some. Note, however, that INIT_RESP return these values<= /div>
as part of a RulesetInfo structure, so that it is implied that preconf= iguration also
must be on a per-ruleset basis.
=C2=A0

> In 4.4.2, I think that if none of the rulesets are accepted, the inten= t
> is that the database should return a REGISTRATION_RESP with the error<= br> > element, and will not return a rulesetInfos list.=C2=A0 =C2=A0However,= the
> specification does not make an exception for this case when it says &q= uot;A
> RulesetInfo list MUST be included" and=C2=A0 "The list MUST = contain at least
> one entry".=C2=A0 =C2=A0I can't think of another valid interp= retation, but you've
> stated a MUST, so you need to say that it doesn't apply in the cas= e of
> the error.
>
> Ah, right. There is language from INIT_RESP that needs to be repeated = here.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 If the Database does not support the device= or any of the rulesets
>=C2=A0 =C2=A0 =C2=A0 =C2=A0specified in the DeviceDescriptor, it MUST i= nstead return an error
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with the UNSUPPORTED (Table 1) code in the e= rror response.

That doesn't fix it, though=E2=80=94you need to fix the other MUS= T to say "unless there's an error" or words to that effect.

Actually, REGISTRATION_RESP is returned = only when there is not error,
so if it is returned, it must have one or more entries.

=
The "it MUST instead return an error" should suffice t= o clarify this?
=C2=A0

> In 4.5:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 If some
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 locations within a batch request are outsid= e the regulatory
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 domain supported by the Database, the Datab= ase MAY return an OK
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 response with available spectrum for only t= he valid locations;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 otherwise, if all locations within a batch = request are outside
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the regulatory domain, the Database MUST re= spond with an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 OUTSIDE_COVERAGE error.
>
> What should the database do if it doesn't follow the MAY?=C2=A0 = =C2=A0Should it
> return an OUTSIDE_COVERAGE error?=C2=A0 =C2=A0It seems to me that this= MAY is going
> to require some unclear heuristics on the side of the master device. > Why isn't this a MUST?=C2=A0 =C2=A0I think if this were a MUST, it= would be clear
> how implementations should behave; by making it a MAY, there's a b= ig gap
> that I think will lead to interoperability problems as different
> implementors make different choices about how to treat this situation.=
>
> If it does not follow MAY, the assumption is that it would return OUTS= IDE_COVERAGE error.
> I take your point about it being harder to use for the device.
>
> I don't think there would be objections to changing this to a MUST= .

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

> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Section 3 describes spectrum-usage messages as purely informational. > Section 4.5 says that the database can require that such messages be > sent.=C2=A0 =C2=A0Which is it: is it sometimes required, or always pur= ely
> informational?=C2=A0 =C2=A0Or does "purely informational" ju= st mean that the
> protocol provides no mechanism for tracking such notifications?=C2=A0 = It would
> be helpful if this were clearer.
>
> "purely informational" means that the it's just notifyin= g the Database what
> spectrum it intends to use and is not a request to the Database to get= permission
> to use that spectrum. Some regulators require this notification.
>
> I'll try to clarify the text.

Ah, that explains it.=C2=A0 =C2=A0Thanks.=C2=A0 =C2=A0Adding some tex= t pretty much like what you just wrote would address this comment nicely.

Will do.
=C2=A0

> I have to confess that the use of "master" and "slave&q= uot; throughout this
> document makes me quite uncomfortable in reading it.=C2=A0 =C2=A0It wo= uld really be
> preferable to use terms that have less painful history associated with=
> them, like "core" and "leaf" or "coordinator&= quot; and "supplicant."=C2=A0 =C2=A0I
> realize this is a matter of taste, and I do not at all mean to suggest=
> that there's anything wrong with the use of these terms, which are=
> certainly common in the computing industry.=C2=A0 =C2=A0This is just a= comment, and
> whether you address it is entirely up to you.
>
> This results from the terminology established in RFC6953.

I guess I should have complained sooner... :}

> In 4.6.1, it would help to have text that explains what it means to > validate a device.=C2=A0 =C2=A0It's certainly not required for int= eroperability,
> but might be helpful for implementors of database servers.
>
> This is explained in the first paragraph of 4.6, I think.
>
>=C2=A0 =C2=A0 A Slave Device needs a Master Device to ask the Database = on its
>=C2=A0 =C2=A0 behalf for available spectrum.=C2=A0 Depending on the rul= eset, the Master
>=C2=A0 =C2=A0 Device also must validate with the Database that the Slav= e Device is
>=C2=A0 =C2=A0 permitted to operate. ...

Ah, okay.=C2=A0 =C2=A0The problem is that "validate the device&q= uot; isn't obviously connected to "validate with the database that= the ..."=C2=A0 =C2=A0I see the connection now, but it would help to m= ake it clearer.

Will do.
=C2=A0

> In 5.3, it's a little puzzling that antenna direction, radiation p= attern,
> gain and polarization aren't defined, because they seem like prope= rties
> that should have universal applicability, even if they are not require= d
> in all cases.=C2=A0 =C2=A0Is this being left as future work, or is the= re some more
> subtle reason why these haven't been defined explicitly?
>
> This is for future extension, rather than defining a whole set of thin= gs that
> won't get used. Note that for mobile devices, direction/pattern/po= larization
> changes all the time and would be "crazy" to define rules ba= sed on these
> characteristics.

Right, just checking.

> In 5.11, power is expressed in dbm, which leads me to wonder if this i= s
> the product of the antenna gain and the input power to the output
> amplifier, or whether it's just the input power to the amplifier, = or
> whether it's being left intentionally ambiguous.
>
> Great question.
>
> I believe this was left intentionally ambiguous, since each regulator = may choose to define
> the power in a different way. Typically, it's the radiated power a= t the
> antenna, over some bandwidth, averaged over some period of time (defin= ed by the regulator).
>
> Perhaps I should add the "Typically" statement to Section 5.= 11 that describes Spectrum.

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

I'll add it to the doc.
=C2= =A0

Thanks for the quick response!




--
-vince
--20cf307cffd6f1887b05013270f8-- From nobody Fri Aug 22 06:20:47 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD361A037B; Fri, 22 Aug 2014 06:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXzZcgaUA4Wf; Fri, 22 Aug 2014 06:20:39 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81EC71A026E; Fri, 22 Aug 2014 06:20:39 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4B2E61B86EC; Fri, 22 Aug 2014 06:20:39 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2A87853E070; Fri, 22 Aug 2014 06:20:39 -0700 (PDT) Received: from vpna-167.vpn.nominum.com (64.89.227.167) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 22 Aug 2014 06:20:38 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Fri, 22 Aug 2014 09:20:26 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <30C11DC7-3D85-4B80-84F8-5EEB637ABD2F@nominum.com> References: <20140821133025.17118.4987.idtracker@ietfa.amsl.com> <8E8E5E78-4755-4889-8B8A-B804D30155C9@nominum.com> To: Vincent Chen X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [64.89.227.167] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/3JbH-YXp7aFIpJLQkMh5bHQZIr8 Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Ted Lemon's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 13:20:41 -0000 [Resent because I forgot to Cc everyone.] On Aug 22, 2014, at 3:03 AM, Vincent Chen wrote: >> It should not occur in practice for well-behaved devices. >>=20 >> When it is preconfigured, there must be a preconfigured value for = each ruleset. >> Of course, a device may choose to use preconfigured values for only a = subset >> of the rulesets it supports. >>=20 >> Note that, in practice, a device needs to be certified for each = "ruleset" by >> whatever process is defined by each applicable regulatory body, so = that >> any preconfigured values will be certified to be compliant. >=20 > If this is how it works, shouldn't the document say so? Or was that = in the requirements document? I admit it's been a while since I read = it. :) >=20 > I'll clarify the text some. Note, however, that INIT_RESP return these = values > as part of a RulesetInfo structure, so that it is implied that = preconfiguration also > must be on a per-ruleset basis. To be clear, what I was suggesting ought to be documented is that the = information has to be preconfigured and certified by the regulatory = authority. If this is already mentioned in the requirements document, = there's no need to mention it here, although a reference to the previous = document might be helpful for neophytes like me. I don't really know = what the mental context of a reader of this document would be, so please = forgive me if I'm being ridiculous here. >> In 4.4.2, I think that if none of the rulesets are accepted, the = intent >> is that the database should return a REGISTRATION_RESP with the error >> element, and will not return a rulesetInfos list. However, the >> specification does not make an exception for this case when it says = "A >> RulesetInfo list MUST be included" and "The list MUST contain at = least >> one entry". I can't think of another valid interpretation, but = you've >> stated a MUST, so you need to say that it doesn't apply in the case = of >> the error. >>=20 >> Ah, right. There is language from INIT_RESP that needs to be repeated = here. >>=20 >> If the Database does not support the device or any of the = rulesets >> specified in the DeviceDescriptor, it MUST instead return an = error >> with the UNSUPPORTED (Table 1) code in the error response. >=20 > That doesn't fix it, though=97you need to fix the other MUST to say = "unless there's an error" or words to that effect. >=20 > Actually, REGISTRATION_RESP is returned only when there is not error, > so if it is returned, it must have one or more entries. >=20 > The "it MUST instead return an error" should suffice to clarify this? The problem I have with this text actually stems from the first = paragraph of the section: The registration response message acknowledges successful registration by including a RulesetInfo message for each ruleset in which the registration is accepted. If the Database does not accept the registration for any of the rulesets it supports, the Database MUST return the NOT_REGISTERED error (See Error Codes (Section 5.17)). In reviewing this just now, I realized that I may have completely = misinterpreted the second sentence. It probably means either: If the database does not accept the registration for any single ruleset it supports, the database MUST return the NOT_REGISTERED error. Or: If none of the rulesets being registered are accepted by the database, the database MUST return the NOT_REGISTERED error. Right now, your use of "any" could be interpreted either way. And then, what I was asking you to change in this DISCUSS item was this: rulesetInfos: A RulesetInfo (Section 5.6) list MUST be included in the response. Each entry corresponds to a ruleset for which the registration was accepted. The list MUST contain at least one entry. [If an error is being returned, this list MUST be omitted.] The text in brackets is what I am proposing that you should add. = Otherwise you are giving the implementor conflicting instructions--a = MUST is a MUST, and has to be followed, but of course it can't be = followed if no rulesets match. I'm just asking you to make that = explicit so that nobody gets confused. Anyway, it sounds like we're converging. Let me know if what I'm = saying still doesn't make sense.= From nobody Fri Aug 22 13:28:44 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1D61A0660 for ; Fri, 22 Aug 2014 13:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUgOamLUNQGZ for ; Fri, 22 Aug 2014 13:28:41 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3271A6F32 for ; Fri, 22 Aug 2014 13:28:41 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id hq11so12917122vcb.16 for ; Fri, 22 Aug 2014 13:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EvoFGGnLy2m3CkQvQOqx1nwfLdwaJb+RF3lHzchupGQ=; b=SQPxMMR0z5GJb2YbgL/Q2mPklYv2srkSdAzQ6YEt1JhQM2BSIzoLqO/R9vP826QEoZ dDOAjKC1vytuYcaPBIpAuPanTwJ1J/qNV55q4SYp5UEzmOV5mx6kfAkhF4eW/n9Dy5rc cDTriHmIQTaYeOLkWlzS3og8ZPCxnlBs65fANIyIk0l3jOlpoPyWCXtbok7+K8+KST1e ++A9mQD7f5mY+InKvsGROIcjaGVVsw3yBYtg2ZHx0gJrdZ+yfMnDJz0x81Z0LuCNp8pK f3n4DZoJ65v/XoADvQR+GMXpgQRMYsfmLrLvMPjj3p7WoGX9GV2bOgfzVAc6GWrzE616 0r8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EvoFGGnLy2m3CkQvQOqx1nwfLdwaJb+RF3lHzchupGQ=; b=b/1yukmL+jSOupj7kyUvk/nv2shma5AVH9235ENwQHN+XpFiorLchScGK7rr9hNboY PvRI1dSqXuZYgLgMc5YBaht4kKYQ2IW1uL6klvNw1mw50e7sQYOXS3PJwXfTmhQtWEs9 fHoCu+1h7D4XLvC/U29x8dJ2ln1YFR4V/+jaoB4OSz6Y5IU8MXRCVWgo/lzZ4GZW2WvL /MW0k36hjuS2VecwYIX1KnHwjxJ2vUBuUFl5dZlLaTJq9ZP1hSNIYuoynvlOPv1M7qIq 5A4o1YCQjyTPyBLQrY1fGVlB7/JKelDWg+IrGwVpkWwDJkMN5MhGmsc+Aq/pUQC8RSt4 mhDQ== X-Gm-Message-State: ALoCoQmWGlbj3WDikkVGxO8mtPLlj52JACbW/j1Z5qLBOoLFwRh24OMdSNTZ4qFNMz5wQvkSy9DP MIME-Version: 1.0 X-Received: by 10.220.172.8 with SMTP id j8mr2085039vcz.32.1408739320486; Fri, 22 Aug 2014 13:28:40 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Fri, 22 Aug 2014 13:28:40 -0700 (PDT) In-Reply-To: <53F61768.7030007@qti.qualcomm.com> References: <20140820165236.31862.86067.idtracker@ietfa.amsl.com> <53F61768.7030007@qti.qualcomm.com> Date: Fri, 22 Aug 2014 13:28:40 -0700 Message-ID: From: Vincent Chen To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11c3678cc7724d05013daea5 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/fFQk-TrhJ29h0nSa5v9MfqGBOXk Cc: "paws@ietf.org" , "paws-chairs@tools.ietf.org" , The IESG , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 20:28:43 -0000 --001a11c3678cc7724d05013daea5 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 21, 2014 at 8:59 AM, Pete Resnick wrote: > On 8/21/14 2:59 AM, Vincent Chen wrote: > > = Section 5.2 = >> I'd like to discuss why the device serial number needs to be included in >> the device descriptor, rather than some (perhaps persistent) randomly >> generated device identifier that is used only in the context of this >> protocol (which would better protect the privacy of the user of the >> device, since the whitespaces database administrator wouldn't be able to >> correlate the device's spectrum requests with other activities linked to >> the serial number). It's not really clear why serial number is collected >> since both this document and RFC 6953 note the protocol does not defend >> against abuse or mis-use of spectrum. >> > > The regulator want to have the ability to black list ranges of serial > numbers, if it > determines that a series was defective. The Databases must use the serial > number > to determine it can return available spectrum. > > > But that makes this a "required by ruleset but not by protocol" issue, > right? > I think this comes back to the question you asked during the drafting of RFC 6953: >> Are there any potential implementers of this protocol (or potential regulatory bodies) that *don't* care about [serial number], manufacturer or model or etc.? There were no solid answers to that question. I suppose the most flexible is to make it optional at the protocol layer and required by ruleset, as you suggest. > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > -- -vince --001a11c3678cc7724d05013daea5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 21, 2014 at 8:59 AM, Pete Resnick <= ;presnick@qt= i.qualcomm.com> wrote:
=20
On 8/21/14 2:59 AM, Vincent Chen wrote:
=3D Section 5.2 =3D
I'd like to discuss why the device serial number needs to be included i= n
the device descriptor, rather than some (perhaps persistent) randomly
generated device identifier that is used only in the context of this
protocol (which would better protect the privacy of the user of the
device, since the whitespaces database administrator wouldn't be able t= o
correlate the device's spectrum requests with other activities linked t= o
the serial number). It's not really clear why serial number is collecte= d
since both this document and RFC 6953 note the protocol does not defend
against abuse or mis-use of spectrum.

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

But that makes this a "required by ruleset but not by protocol" i= ssue, right?

I think this comes back to the= question you asked during the drafting of RFC 6953:

>>=C2=A0Are there any potential implementers of this protocol = (or potential regulatory bodies) that *don't* care about [serial number= ], manufacturer or model or etc.?

There were no solid answers to that question. I suppose= the most flexible is to make it optional at the
protocol layer a= nd required by ruleset, as you suggest.



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



--
-vince
--001a11c3678cc7724d05013daea5-- From nobody Tue Aug 26 00:59:12 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FF81A0AF2; Tue, 26 Aug 2014 00:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7mOOyWgsEbe; Tue, 26 Aug 2014 00:59:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBF31A0AF0; Tue, 26 Aug 2014 00:59:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140826075901.18942.26722.idtracker@ietfa.amsl.com> Date: Tue, 26 Aug 2014 00:59:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/-1mU_Bkw4CazgF7ojFjQ3O2B4cU Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-protocol-15.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 07:59:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol to Access WS database Working Group of the IETF. Title : Protocol to Access White-Space (PAWS) Databases Authors : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-15.txt Pages : 92 Date : 2014-08-26 Abstract: Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "White Space." Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to managing spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space (PAWS) Databases". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-protocol-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 26 00:59:14 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1B61A0AF0 for ; Tue, 26 Aug 2014 00:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxrA1TMFuBP7; Tue, 26 Aug 2014 00:59:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 057B21A0AF7; Tue, 26 Aug 2014 00:59:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org, paws@ietf.org, presnick@qti.qualcomm.com, ted.lemon@nominum.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, alissa@cooperw.in X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140826075902.18942.88866.idtracker@ietfa.amsl.com> Date: Tue, 26 Aug 2014 00:59:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/apPtStrHJSPv-OeDEyW1cRpANRo Subject: [paws] New Version Notification - draft-ietf-paws-protocol-15.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 07:59:08 -0000 A new version (-15) has been submitted for draft-ietf-paws-protocol: http://www.ietf.org/internet-drafts/draft-ietf-paws-protocol-15.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Aug 26 01:07:31 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5CF1A0AFD for ; Tue, 26 Aug 2014 01:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RFX51lvCR4r for ; Tue, 26 Aug 2014 01:07:26 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0152C1A0AF7 for ; Tue, 26 Aug 2014 01:07:25 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf12so16273245vcb.40 for ; Tue, 26 Aug 2014 01:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vdUol98W+RKH1snFgazoTdoO2dhA4wJ5ZsM0qydCJxE=; b=XnaBNJZs+W+3gYLWjqzSbQ/Sb7BjOe21FMGXDl87KjrS7K9rSAFgvhhqIn5OxmiTpC nXTwWzh8IvikDK+6meyXL+l2losjDFcjreprlMcIMdjs8rphnm0/qnSK3IPKbdYUlIs8 zpqO6gk7Fzhtm+mvK87PRAyeZFFejSejfg0u5YXdkRkEYHh5CWwJC6egXlNSFqc3m13N dxuZ9c6nKpcqvWhAngdltPfBobuuvYaykZHvn1tJnK670jQcSKSUlcz+Kl149EkVNgrC Pk35Kho17w0JiplszF/UL1JOSz98O0FiMHNQUMFSBMBwH8U6S1zCJUlpM1iCYygSYp0D W+mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vdUol98W+RKH1snFgazoTdoO2dhA4wJ5ZsM0qydCJxE=; b=IkBtKeOws7wVJsIY6z1JjtZy+Ja18efufNSZVRAaRpfLrBCPColrRvWd01KDbpQkum 8f0vBsb9acMSARk7wx5KTS7mymmOghVnN1xbVL/dzFkVS2jje2F6s6pKQ0kU74OaOw72 UVW5Qj4VvyjhXbyurNu39so9IfyMRBRbsGy1NKXaVqCXLdxrfOg9OFnqkHIfOGDOZlcg KKVgBU86By77GXZ4TpdqU5M4AsX6CdWw1UjTeTICIBqPHHFQJ5GvhwKEZNTEBXINCtIo LOplGZDVErPNcbIquGCtv3Q3poXf9B+gWQMap9RFPGUx+JyObty1J4gWMiqJ4KWCZVFP 6PxQ== X-Gm-Message-State: ALoCoQm/e3iWNMHnnFrsPND08W76y8qIfS3oGmAVLnvb984EqPb43IhQUcrMiPIssi4jhRicZxzP MIME-Version: 1.0 X-Received: by 10.220.190.134 with SMTP id di6mr9783119vcb.43.1409040445064; Tue, 26 Aug 2014 01:07:25 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Tue, 26 Aug 2014 01:07:24 -0700 (PDT) In-Reply-To: <20140826075902.18942.88866.idtracker@ietfa.amsl.com> References: <20140826075902.18942.88866.idtracker@ietfa.amsl.com> Date: Tue, 26 Aug 2014 01:07:24 -0700 Message-ID: From: Vincent Chen To: "paws@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1c11c33f4ec050183cb57 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/4TxrtzDL8nkS6C_iPyrSlaCeSXo Cc: "paws-chairs@tools.ietf.org" , Pete Resnick , Kathleen Moriarty , Ted Lemon , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] New Version Notification - draft-ietf-paws-protocol-15.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 08:07:29 -0000 --001a11c1c11c33f4ec050183cb57 Content-Type: text/plain; charset=UTF-8 All, I've taken a stab at addressing all the DISCUSS points and comments. Hopefully this moves us closer. Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-15 Summary of updates: o Clarified why spectrum-notify is "informational" o Clarified that device registration is typically only required for fixed devices o Global statement about timestamp format and must be UTC o Global statement about MISSING error returned, whether it's required by PAWS or ruleset o Clarified UNSUPPORTED error o Mandate that Database-change must be included in all responses a minimum of 2 weeks before change o Clarified that preconfigured values are ruleset specific (INIT_RESP) o Added reference to FCC ruleset for registration of Fixed Devices o Make deviceOwner and serialNumber optional at PAWS level and required on a per-ruleset basis o Update description for "location" to be where device intends to operate, rather than "current location" o For REGISTRATION_RESP, add clarification that when it is returned, it will have at least one RulesetInfo. Otherwise, it's an UNSUPPORTED error. o Clarified that, when a Master Device asks for spectrum on behalf of a Slave Device, there are 2 locations in the message and changed masterDeviceLocation to be required o Indicate that power levels are typically EIRP (as opposed to conducted power to the antenna) o Added description for a "schedule" o Add intro to DEVICE_VALID_REQ o TLS: Follow best practices to improve security and interop. Reference draft-ietf-uta-tls-bcp o TLS: Use OCSP for better performance; RFC6960 o TLS: When using client auth, Database determines acceptable root CAs o Extensibility: Add statement that no extensions that return device information will not be accepted o Clarify IANA instructions for the Ruleset ID Registry o Security: Acknowledge that unauthorized access to device registration, other sensitive device info is a risk, and indicate that privacy policies must be published and implement to control access. Thanks! -vince On Tue, Aug 26, 2014 at 12:59 AM, wrote: > > A new version (-15) has been submitted for draft-ietf-paws-protocol: > http://www.ietf.org/internet-drafts/draft-ietf-paws-protocol-15.txt > > Sub state has been changed to AD Followup from Revised ID Needed > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-15 > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > IETF Secretariat. > > -- -vince --001a11c1c11c33f4ec050183cb57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

I've taken a stab at addressin= g all the DISCUSS points and comments.
Hopefully this moves us cl= oser.



Summary of updates:
=C2= =A0 =C2=A0o =C2=A0Clarified why spectrum-notify is "informational"= ;

=C2=A0 =C2=A0o =C2=A0Clarified that device regis= tration is typically only required for
=C2=A0 =C2=A0 =C2=A0 fixed devices

=C2=A0 =C2= =A0o =C2=A0Global statement about timestamp format and must be UTC

=C2=A0 =C2=A0o =C2=A0Global statement about MISSING error = returned, whether it's
=C2=A0 =C2=A0 =C2=A0 required by PAWS = or ruleset

=C2=A0 =C2=A0o =C2=A0Clarified UNSUPPORTED error
<= div>
=C2=A0 =C2=A0o =C2=A0Mandate that Database-change must b= e included in all responses a
=C2=A0 =C2=A0 =C2=A0 minimum of 2 w= eeks before change

=C2=A0 =C2=A0o =C2=A0Clarified that preconfigured values are ruleset specif= ic
=C2=A0 =C2=A0 =C2=A0 (INIT_RESP)

=C2= =A0 =C2=A0o =C2=A0Added reference to FCC ruleset for registration of Fixed = Devices

=C2=A0 =C2=A0o =C2=A0Make deviceOwner and = serialNumber optional at PAWS level and
=C2=A0 =C2=A0 =C2=A0 required on a per-ruleset basis

=C2=A0 =C2=A0o =C2=A0Update description for "location" to= be where device intends to
=C2=A0 =C2=A0 =C2=A0 operate, rather = than "current location"

=C2=A0 =C2=A0o =C2=A0For REGISTRATION_RESP, add clarificatio= n that when it is returned,
=C2=A0 =C2=A0 =C2=A0 it will have at = least one RulesetInfo. =C2=A0Otherwise, it's an
=C2=A0 =C2=A0= =C2=A0 UNSUPPORTED error.

=C2=A0 =C2=A0o =C2=A0Clarified that, when a Master Device asks for spe= ctrum on behalf
=C2=A0 =C2=A0 =C2=A0 of a Slave Device, there are= 2 locations in the message and
=C2=A0 =C2=A0 =C2=A0 changed mast= erDeviceLocation to be required

=C2=A0 =C2=A0o =C2=A0Indicate that power levels are typicall= y EIRP (as opposed to
=C2=A0 =C2=A0 =C2=A0 conducted power to the= antenna)

=C2=A0 =C2=A0o =C2=A0Added description f= or a "schedule"

=C2=A0 =C2=A0o =C2=A0Add intro to DEVICE_VALID_REQ

=C2=A0 =C2=A0o =C2=A0TLS: Follow best practices to improve security a= nd interop.
=C2=A0 =C2=A0 =C2=A0 Reference draft-ietf-uta-tls-bcp=

=C2=A0 =C2=A0o =C2=A0TLS: Use OCSP for better per= formance; RFC6960

=C2=A0 =C2=A0o =C2=A0TLS: When using client auth, Datab= ase determines acceptable root
=C2=A0 =C2=A0 =C2=A0 CAs

=C2=A0 =C2=A0o =C2=A0Extensibility: Add statement that no e= xtensions that return device
=C2=A0 =C2=A0 =C2=A0 information wil= l not be accepted

=C2=A0 =C2=A0o =C2=A0Clarify IANA instructions for the = Ruleset ID Registry

=C2=A0 =C2=A0o =C2=A0Security:= Acknowledge that unauthorized access to device
=C2=A0 =C2=A0 =C2= =A0 registration, other sensitive device info is a risk, and indicate
=C2=A0 =C2=A0 =C2=A0 that privacy policies must be published and imple= ment to control
=C2=A0 =C2=A0 =C2=A0 access.

=
Thanks!

-vince


On Tue, Aug 26, 2014 at 12:59 AM, <internet-drafts@ietf.org>= ; wrote:

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

Sub state has been changed to AD Followup from Revised ID Needed


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

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

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

IETF Secretariat.




--
-vince
--001a11c1c11c33f4ec050183cb57-- From nobody Tue Aug 26 13:58:24 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9347B1A87EB for ; Tue, 26 Aug 2014 13:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4T39fGuDjVX for ; Tue, 26 Aug 2014 13:58:20 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175DC1A87DF for ; Tue, 26 Aug 2014 13:58:18 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id v6so2058006lbi.10 for ; Tue, 26 Aug 2014 13:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UgORPWpbf0KTRc44l0RFAruErnEzO2kEGriLfFCvk7I=; b=0ffTiDh4/4FVvXD6FilSzJ8ZVZDXsyxd5cNoFC4mDhmcyPjGrL/Z1EZwhMCV1xUGr0 uV0cZkoRIzC1eLdGcyPQ+MbtS0kzMiuaqkqZU7Rl88oD+38JsR4vn2iJHhzcFsP7S8l+ /LSZdrScGOYbbdy4HPq0udpcsF96xXcWj365hLzKg1M4xdrfCTl0ywRHCI9e2TFZUWG8 bcqKgtiHG8VbcyQwXYjg4d5JSW/Os2+hjNIcTbBvXoiIsWVbX9rWPp4cfhZ9ysBB/fuG eDfBRx6ArRvAqheUDsRj92EK5swLTAKP6px6jtgcVPx8kj31arKWcm9ZsQjhIgRT8Rcx NlXg== MIME-Version: 1.0 X-Received: by 10.112.28.8 with SMTP id x8mr4431724lbg.104.1409086697378; Tue, 26 Aug 2014 13:58:17 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Tue, 26 Aug 2014 13:58:17 -0700 (PDT) In-Reply-To: References: <20140826075902.18942.88866.idtracker@ietfa.amsl.com> Date: Tue, 26 Aug 2014 16:58:17 -0400 Message-ID: From: Kathleen Moriarty To: Vincent Chen Content-Type: multipart/alternative; boundary=001a113404280e1b4805018e90d1 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/mc_0CxZpF5uWftjD3VQSSazaKjQ Cc: "paws-chairs@tools.ietf.org" , Pete Resnick , "paws@ietf.org" , Ted Lemon , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] New Version Notification - draft-ietf-paws-protocol-15.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:58:22 -0000 --001a113404280e1b4805018e90d1 Content-Type: text/plain; charset=UTF-8 Thank you for the updates, my discuss will be cleared in a minute. I have a comment below to assist with one of the other points from Stephen. On Tue, Aug 26, 2014 at 4:07 AM, Vincent Chen wrote: > All, > > I've taken a stab at addressing all the DISCUSS points and comments. > Hopefully this moves us closer. > > Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-15 > > > Summary of updates: > o Clarified why spectrum-notify is "informational" > > o Clarified that device registration is typically only required for > fixed devices > > o Global statement about timestamp format and must be UTC > > o Global statement about MISSING error returned, whether it's > required by PAWS or ruleset > > o Clarified UNSUPPORTED error > > o Mandate that Database-change must be included in all responses a > minimum of 2 weeks before change > > o Clarified that preconfigured values are ruleset specific > (INIT_RESP) > > o Added reference to FCC ruleset for registration of Fixed Devices > > o Make deviceOwner and serialNumber optional at PAWS level and > required on a per-ruleset basis > > o Update description for "location" to be where device intends to > operate, rather than "current location" > > o For REGISTRATION_RESP, add clarification that when it is returned, > it will have at least one RulesetInfo. Otherwise, it's an > UNSUPPORTED error. > > o Clarified that, when a Master Device asks for spectrum on behalf > of a Slave Device, there are 2 locations in the message and > changed masterDeviceLocation to be required > > o Indicate that power levels are typically EIRP (as opposed to > conducted power to the antenna) > > o Added description for a "schedule" > > o Add intro to DEVICE_VALID_REQ > > o TLS: Follow best practices to improve security and interop. > Reference draft-ietf-uta-tls-bcp > > o TLS: Use OCSP for better performance; RFC6960 > OCSP Stapling improves performance over just OCSP, but not for leaving out OCSP all together. Security is improved as well. If you keep the sentence in about OCSP, I think you need all 3 references: RFC6066, RFC6961, and RFC6960. If you just wanted to follow the guidance in draft-ietf-uta-tls-bcp, they already covered this. > > o TLS: When using client auth, Database determines acceptable root > CAs > > o Extensibility: Add statement that no extensions that return device > information will not be accepted > > o Clarify IANA instructions for the Ruleset ID Registry > > o Security: Acknowledge that unauthorized access to device > registration, other sensitive device info is a risk, and indicate > that privacy policies must be published and implement to control > access. > > Thanks! > > -vince > > > On Tue, Aug 26, 2014 at 12:59 AM, wrote: > >> >> A new version (-15) has been submitted for draft-ietf-paws-protocol: >> http://www.ietf.org/internet-drafts/draft-ietf-paws-protocol-15.txt >> >> Sub state has been changed to AD Followup from Revised ID Needed >> >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ >> >> Diff from previous version: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-15 >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> IETF Secretariat. >> >> > > > -- > -vince > -- Best regards, Kathleen --001a113404280e1b4805018e90d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for the updates, my discuss will be cleared in a= minute. =C2=A0I have a comment below to assist with one of the other point= s from Stephen.


On Tue, Aug 26, 2014 at 4:07 AM, Vincent Chen <<= a href=3D"mailto:vchen@google.com" target=3D"_blank">vchen@google.com&g= t; wrote:
All,

I&#= 39;ve taken a stab at addressing all the DISCUSS points and comments.
=
Hopefully this moves us closer.

Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-15


Summary of updates:
=C2= =A0 =C2=A0o =C2=A0Clarified why spectrum-notify is "informational"= ;

=C2=A0 =C2=A0o =C2=A0Clarified that device regis= tration is typically only required for
=C2=A0 =C2=A0 =C2=A0 fixed devices

=C2=A0 =C2= =A0o =C2=A0Global statement about timestamp format and must be UTC

=C2=A0 =C2=A0o =C2=A0Global statement about MISSING error = returned, whether it's
=C2=A0 =C2=A0 =C2=A0 required by PAWS = or ruleset

=C2=A0 =C2=A0o =C2=A0Clarified UNSUPPORTED error
<= div>
=C2=A0 =C2=A0o =C2=A0Mandate that Database-change must b= e included in all responses a
=C2=A0 =C2=A0 =C2=A0 minimum of 2 w= eeks before change

=C2=A0 =C2=A0o =C2=A0Clarified that preconfigured values are ruleset specif= ic
=C2=A0 =C2=A0 =C2=A0 (INIT_RESP)

=C2= =A0 =C2=A0o =C2=A0Added reference to FCC ruleset for registration of Fixed = Devices

=C2=A0 =C2=A0o =C2=A0Make deviceOwner and = serialNumber optional at PAWS level and
=C2=A0 =C2=A0 =C2=A0 required on a per-ruleset basis

=C2=A0 =C2=A0o =C2=A0Update description for "location" to= be where device intends to
=C2=A0 =C2=A0 =C2=A0 operate, rather = than "current location"

=C2=A0 =C2=A0o =C2=A0For REGISTRATION_RESP, add clarificatio= n that when it is returned,
=C2=A0 =C2=A0 =C2=A0 it will have at = least one RulesetInfo. =C2=A0Otherwise, it's an
=C2=A0 =C2=A0= =C2=A0 UNSUPPORTED error.

=C2=A0 =C2=A0o =C2=A0Clarified that, when a Master Device asks for spe= ctrum on behalf
=C2=A0 =C2=A0 =C2=A0 of a Slave Device, there are= 2 locations in the message and
=C2=A0 =C2=A0 =C2=A0 changed mast= erDeviceLocation to be required

=C2=A0 =C2=A0o =C2=A0Indicate that power levels are typicall= y EIRP (as opposed to
=C2=A0 =C2=A0 =C2=A0 conducted power to the= antenna)

=C2=A0 =C2=A0o =C2=A0Added description f= or a "schedule"

=C2=A0 =C2=A0o =C2=A0Add intro to DEVICE_VALID_REQ

=C2=A0 =C2=A0o =C2=A0TLS: Follow best practices to improve security a= nd interop.
=C2=A0 =C2=A0 =C2=A0 Reference draft-ietf-uta-tls-bcp=

=C2=A0 =C2=A0o =C2=A0TLS: Use OCSP for better per= formance; RFC6960
OCSP Stapling improves performance over just = OCSP, but not for leaving out OCSP all together. =C2=A0Security is improved= as well.=C2=A0
If you keep the sentence in about OCSP, I think y= ou need all 3 references: RFC6066, RFC6961, and RFC6960. =C2=A0If you just = wanted to follow the guidance in draft-ietf-uta-tls-bcp, they already cover= ed this.=C2=A0

=C2=A0 =C2=A0o =C2=A0TLS: When using client auth, Datab= ase determines acceptable root
=C2=A0 =C2=A0 =C2=A0 CAs

=C2=A0 =C2=A0o =C2=A0Extensibility: Add statement that no e= xtensions that return device
=C2=A0 =C2=A0 =C2=A0 information wil= l not be accepted

=C2=A0 =C2=A0o =C2=A0Clarify IANA instructions for the = Ruleset ID Registry

=C2=A0 =C2=A0o =C2=A0Security:= Acknowledge that unauthorized access to device
=C2=A0 =C2=A0 =C2= =A0 registration, other sensitive device info is a risk, and indicate
=C2=A0 =C2=A0 =C2=A0 that privacy policies must be published and imple= ment to control
=C2=A0 =C2=A0 =C2=A0 access.

=
Thanks!

-vince


On Tue, Aug 26, 2014 at 12:59 AM, <internet-drafts@ietf.org>= ; wrote:

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

Sub state has been changed to AD Followup from Revised ID Needed


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

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

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

IETF Secretariat.




--
-vince



--

Best regards,
Kathleen
--001a113404280e1b4805018e90d1-- From nobody Tue Aug 26 13:59:14 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390C71A888D; Tue, 26 Aug 2014 13:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wo7RWiIdyV6P; Tue, 26 Aug 2014 13:59:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A351E1A888A; Tue, 26 Aug 2014 13:59:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140826205901.19810.94373.idtracker@ietfa.amsl.com> Date: Tue, 26 Aug 2014 13:59:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/O8VMtHwVAHRw7kTPpDNoVvdZWOA Cc: paws@ietf.org, paws-chairs@tools.ietf.org, draft-ietf-paws-protocol@tools.ietf.org Subject: [paws] Kathleen Moriarty's No Objection on draft-ietf-paws-protocol-15: (with COMMENT) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:59:06 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-paws-protocol-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the updates! From nobody Tue Aug 26 15:12:55 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF76A1A020B for ; Tue, 26 Aug 2014 15:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5D-YzYs77V4 for ; Tue, 26 Aug 2014 15:12:36 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68FE41A0205 for ; Tue, 26 Aug 2014 15:12:36 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 20so2830241yks.31 for ; Tue, 26 Aug 2014 15:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L9qBNeBYEx6QlKvnZ739hyDzmAFibP9EseLwhePFsyY=; b=VqIJs2Dzn56MTLfU1uX19cDjWIy5SrMc0VWDLyLFmYMngH3oWSJ5/44VqeUmyADPkT aULtnWeUO4wavIpp+lb+/K2ed8CKW9bnzrAKS6+x9CdaZlmvUFJ3emFqfWmlOt/OAPwn 2BDwtY9ksV0sMIRv52MWEAgFe0J0blcUMId4+b/jWSic1xPEA2udtxWZUkH+06L7/YRp gPjyci+50CzDjwe5x+fmpVL4Z5r00Q5PoSWyNO1vSvrquuFq5Rt5D9zQLA+fY8ybk7mL NJJxO2GMhDk3CL3ZYKVYdMatiwUhSZETDSYZxogd+9cI/+3r8VIjs6ms3Hxqc8Vuz06k irVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=L9qBNeBYEx6QlKvnZ739hyDzmAFibP9EseLwhePFsyY=; b=cImuzykOtDDRUm928JS9PizNtRdFIVLkw+Ft2F1RRxEymnFUsZ3SH8+ucaJi3yvmX7 H5XnkSUOE5pMLPnKrQOCBnjMoA3tN4GW5Qw0lfNNTAq5n+k6dlP44v/GlJNGrxPmlSSp F4aHu2YB9vpOrMs3WEmQ6CmpDtxkat/iOwrrETL4jdtRJBIHqrTvAaKfdIsL6WnceF3B bnmAMAjAA9mFgIlLvWL/8yYyS6cvV8njdq7IzHrMp9WWp5CbC1Xebr17fgJorAfWtODF HIYrynCp5vifdLsOcCp56OfHi4MQqGIFJbhUFAIdBvvcSRuEzy3EfpdkcqqDgEtpf9kF 3O3w== X-Gm-Message-State: ALoCoQlBMJ72mBSUOG1VhIccV/LNsX/LZAvUuQeOE2sKFQklydQ9j2GY4vnhhfTRNcJaVJO72+7J MIME-Version: 1.0 X-Received: by 10.52.136.196 with SMTP id qc4mr11868144vdb.22.1409091155763; Tue, 26 Aug 2014 15:12:35 -0700 (PDT) Received: by 10.52.177.226 with HTTP; Tue, 26 Aug 2014 15:12:35 -0700 (PDT) In-Reply-To: References: <20140826075902.18942.88866.idtracker@ietfa.amsl.com> Date: Tue, 26 Aug 2014 15:12:35 -0700 Message-ID: From: Vincent Chen To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=bcaec51b12bdcbc37b05018f9981 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/lAMIG3hQ34BNGSlAmAUtH2frQM0 Cc: "paws-chairs@tools.ietf.org" , Pete Resnick , "paws@ietf.org" , Ted Lemon , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] New Version Notification - draft-ietf-paws-protocol-15.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 22:12:39 -0000 --bcaec51b12bdcbc37b05018f9981 Content-Type: text/plain; charset=UTF-8 Thanks Kathleen, On Tue, Aug 26, 2014 at 1:58 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Thank you for the updates, my discuss will be cleared in a minute. I have > a comment below to assist with one of the other points from Stephen. > > > On Tue, Aug 26, 2014 at 4:07 AM, Vincent Chen wrote: > >> All, >> >> I've taken a stab at addressing all the DISCUSS points and comments. >> Hopefully this moves us closer. >> >> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-15 >> >> >> Summary of updates: >> o Clarified why spectrum-notify is "informational" >> >> o Clarified that device registration is typically only required for >> fixed devices >> >> o Global statement about timestamp format and must be UTC >> >> o Global statement about MISSING error returned, whether it's >> required by PAWS or ruleset >> >> o Clarified UNSUPPORTED error >> >> o Mandate that Database-change must be included in all responses a >> minimum of 2 weeks before change >> >> o Clarified that preconfigured values are ruleset specific >> (INIT_RESP) >> >> o Added reference to FCC ruleset for registration of Fixed Devices >> >> o Make deviceOwner and serialNumber optional at PAWS level and >> required on a per-ruleset basis >> >> o Update description for "location" to be where device intends to >> operate, rather than "current location" >> >> o For REGISTRATION_RESP, add clarification that when it is returned, >> it will have at least one RulesetInfo. Otherwise, it's an >> UNSUPPORTED error. >> >> o Clarified that, when a Master Device asks for spectrum on behalf >> of a Slave Device, there are 2 locations in the message and >> changed masterDeviceLocation to be required >> >> o Indicate that power levels are typically EIRP (as opposed to >> conducted power to the antenna) >> >> o Added description for a "schedule" >> >> o Add intro to DEVICE_VALID_REQ >> >> o TLS: Follow best practices to improve security and interop. >> Reference draft-ietf-uta-tls-bcp >> >> o TLS: Use OCSP for better performance; RFC6960 >> > OCSP Stapling improves performance over just OCSP, but not for leaving out > OCSP all together. Security is improved as well. > If you keep the sentence in about OCSP, I think you need all 3 references: > RFC6066, RFC6961, and RFC6960. If you just wanted to follow the guidance > in draft-ietf-uta-tls-bcp, they already covered this. > I see. By referencing draft-ietf-uta-tls-bcp, I don't have to list OCSP explicitly. I like that :) > >> o TLS: When using client auth, Database determines acceptable root >> CAs >> >> o Extensibility: Add statement that no extensions that return device >> information will not be accepted >> >> o Clarify IANA instructions for the Ruleset ID Registry >> >> o Security: Acknowledge that unauthorized access to device >> registration, other sensitive device info is a risk, and indicate >> that privacy policies must be published and implement to control >> access. >> >> Thanks! >> >> -vince >> >> >> On Tue, Aug 26, 2014 at 12:59 AM, wrote: >> >>> >>> A new version (-15) has been submitted for draft-ietf-paws-protocol: >>> http://www.ietf.org/internet-drafts/draft-ietf-paws-protocol-15.txt >>> >>> Sub state has been changed to AD Followup from Revised ID Needed >>> >>> >>> The IETF datatracker page for this Internet-Draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ >>> >>> Diff from previous version: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-15 >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> IETF Secretariat. >>> >>> >> >> >> -- >> -vince >> > > > > -- > > Best regards, > Kathleen > -- -vince --bcaec51b12bdcbc37b05018f9981 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Kathleen,


On Tue, Aug 26, 2014 at 1:58 PM, Kathleen Moriarty = <kathleen.moriarty.ietf@gmail.com> wrote:
Thank you for the updates, = my discuss will be cleared in a minute. =C2=A0I have a comment below to ass= ist with one of the other points from Stephen.


On Tue, Aug 26, 2014 at 4:07 AM, Vincent Chen &= lt;vchen@google.com> wrote:
All,

I&#= 39;ve taken a stab at addressing all the DISCUSS points and comments.
=
Hopefully this moves us closer.

Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-15


Summary of updates:
=C2= =A0 =C2=A0o =C2=A0Clarified why spectrum-notify is "informational"= ;

=C2=A0 =C2=A0o =C2=A0Clarified that device regis= tration is typically only required for
=C2=A0 =C2=A0 =C2=A0 fixed devices

=C2=A0 =C2= =A0o =C2=A0Global statement about timestamp format and must be UTC

=C2=A0 =C2=A0o =C2=A0Global statement about MISSING error = returned, whether it's
=C2=A0 =C2=A0 =C2=A0 required by PAWS = or ruleset

=C2=A0 =C2=A0o =C2=A0Clarified UNSUPPORTED error
<= div>
=C2=A0 =C2=A0o =C2=A0Mandate that Database-change must b= e included in all responses a
=C2=A0 =C2=A0 =C2=A0 minimum of 2 w= eeks before change

=C2=A0 =C2=A0o =C2=A0Clarified that preconfigured values are ruleset specif= ic
=C2=A0 =C2=A0 =C2=A0 (INIT_RESP)

=C2= =A0 =C2=A0o =C2=A0Added reference to FCC ruleset for registration of Fixed = Devices

=C2=A0 =C2=A0o =C2=A0Make deviceOwner and = serialNumber optional at PAWS level and
=C2=A0 =C2=A0 =C2=A0 required on a per-ruleset basis

=C2=A0 =C2=A0o =C2=A0Update description for "location" to= be where device intends to
=C2=A0 =C2=A0 =C2=A0 operate, rather = than "current location"

=C2=A0 =C2=A0o =C2=A0For REGISTRATION_RESP, add clarificatio= n that when it is returned,
=C2=A0 =C2=A0 =C2=A0 it will have at = least one RulesetInfo. =C2=A0Otherwise, it's an
=C2=A0 =C2=A0= =C2=A0 UNSUPPORTED error.

=C2=A0 =C2=A0o =C2=A0Clarified that, when a Master Device asks for spe= ctrum on behalf
=C2=A0 =C2=A0 =C2=A0 of a Slave Device, there are= 2 locations in the message and
=C2=A0 =C2=A0 =C2=A0 changed mast= erDeviceLocation to be required

=C2=A0 =C2=A0o =C2=A0Indicate that power levels are typicall= y EIRP (as opposed to
=C2=A0 =C2=A0 =C2=A0 conducted power to the= antenna)

=C2=A0 =C2=A0o =C2=A0Added description f= or a "schedule"

=C2=A0 =C2=A0o =C2=A0Add intro to DEVICE_VALID_REQ

=C2=A0 =C2=A0o =C2=A0TLS: Follow best practices to improve security a= nd interop.
=C2=A0 =C2=A0 =C2=A0 Reference draft-ietf-uta-tls-bcp=

=C2=A0 =C2=A0o =C2=A0TLS: Use OCSP for better per= formance; RFC6960
OCSP Stapling improves performanc= e over just OCSP, but not for leaving out OCSP all together. =C2=A0Security= is improved as well.=C2=A0
If you keep the sentence in about OCS= P, I think you need all 3 references: RFC6066, RFC6961, and RFC6960. =C2=A0= If you just wanted to follow the guidance in draft-ietf-uta-tls-bcp, they a= lready covered this.=C2=A0

I see. By referencing dr= aft-ietf-uta-tls-bcp, I don't have to list OCSP explicitly. I like that= :)
=C2=A0

=C2=A0 =C2=A0o =C2=A0TLS: When using client auth, Datab= ase determines acceptable root
=C2=A0 =C2=A0 =C2=A0 CAs

=C2=A0 =C2=A0o =C2=A0Extensibility: Add statement that no e= xtensions that return device
=C2=A0 =C2=A0 =C2=A0 information wil= l not be accepted

=C2=A0 =C2=A0o =C2=A0Clarify IANA instructions for the = Ruleset ID Registry

=C2=A0 =C2=A0o =C2=A0Security:= Acknowledge that unauthorized access to device
=C2=A0 =C2=A0 =C2= =A0 registration, other sensitive device info is a risk, and indicate
=C2=A0 =C2=A0 =C2=A0 that privacy policies must be published and imple= ment to control
=C2=A0 =C2=A0 =C2=A0 access.

=
Thanks!

-vince


On Tue, Aug 26, 2014 at 12:59 AM, <internet-drafts@ietf.org>= ; wrote:

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

Sub state has been changed to AD Followup from Revised ID Needed


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

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

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

IETF Secretariat.




<= font color=3D"#888888">--
-vince


--

Best reg= ards,
Kathleen



--
-vince