From nobody Sun Jun 22 13:11: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 C1DE51A02FA for ; Sun, 22 Jun 2014 13:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 gCXJAmup3ZdD for ; Sun, 22 Jun 2014 13:11:01 -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 A30AE1A02B2 for ; Sun, 22 Jun 2014 13:11:01 -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=1403467861; x=1435003861; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=oM3ud3WeJZ1gNrltmS1UIZd3bNwXOhV1yijeI8moYUs=; b=dBPa2wzslPW9pAZlenLnFoNKwNuXG6XPKs8wlyFnAPncKbHn+X42RlAT h9Jz0iFOtWmxQmGFZelSwu1/0erDct6u5x0N4XyKwV0phaZPirqlFOMHd hOZO+svmj/RT/KHOZ1Uen9BaEu5P/qB8knJqDbdiYTQDw3X7eJcLZgjl9 Q=; X-IronPort-AV: E=McAfee;i="5600,1067,7477"; a="44718997" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 22 Jun 2014 13:11:01 -0700 X-IronPort-AV: E=Sophos;i="5.01,525,1400050800"; d="scan'208";a="699872146" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 22 Jun 2014 13:11:01 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 22 Jun 2014 13:11:00 -0700 Message-ID: <53A73852.4060002@qti.qualcomm.com> Date: Sun, 22 Jun 2014 13:10:58 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <20140425004136.20484.45101.idtracker@ietfa.amsl.com> In-Reply-To: <20140425004136.20484.45101.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/Q2Q6vwZ6sYg-aDcpDyWrjUjB22w Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-12.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: Sun, 22 Jun 2014 20:11:05 -0000 I've sat on this document for far too long. I've sent in the request for the Last Call, but there are still some outstanding issues. I think these can be handled during Last Call: 3.1 NOTE: Regulatory rules contain many device-only requirements that govern device behavior, independent of any database rules. These requirements may be complex and involve device behavior that are not easily parameterized. The ruleset-id parameter provides a mechanism for the Database to inform the Master Device of the applicable ruleset without having to express device-side behavior within the protocol. The ruleset identifier is a string value that contains the name of the regulatory body that established the rules and version information, such as "FccTvBandWhiteSpace-2010". No change got made to this paragraph between -11 and -12, even though it still refers to "regulatory rules". Might I suggest: NOTE: Some regulatory domains specify sets of requirements for device behavior that may be complex and not easily parameterized. The ruleset-id parameter provides a mechanism for the Database to inform the Master Device of an applicable ruleset, and for devices with out-of-band knowledge of the particular regulatory domain requirements to satisfy those requirements, without having to specify the device-side behavior within the protocol. Ruleset identifiers will normally contain the name of the regulatory body that established the rules and version information, such as "FccTvBandWhiteSpace-2010". 5.2: Are the formats of serialNumber, manufacturerId, modelId defined anywhere? Are they UTF-8? If I'm writing an implementation, how do I know what these are? 5.8 "It MAY contain UTF-8". That's not interoperable. It either "MUST contain UTF-8" or be completely opaque and therefore strike commentary on the format. 5.16/5.17 "MAY be in any language and contain UTF-8 characters". First, separate out "MAY be in any language" from the format. But as for the format, again, that's not interoperable. In this case, I think "MUST be UTF-8" is the only real choice. 8.1: s/they MUST be registered/they are registered s/64 characters/64 octets The octets/characters thing doesn't make a difference here, but consistency is always a fine thing. 8.3: s/MAY be defined/can be defined 9: Insert at the top: "[RFC Editor/IANA: Please replace "[[ this document ]]" with the RFC number of this document as indicated below, and remove this note prior to publication.]" s/responsible IESG area director should/the IESG shall That's automatic, but you can say it as above. s/30 days/2 weeks Let's make it a normal Last Call length. I think that will make the logistics work a bit better. Also, add on to the end of that paragraph: "Specific criteria that the Designated Expert should use in assessing registrations are given below in the description of each registry." 9.1: s/regulatory rules/regulatory domain 9.1.1: OLD Ruleset name: The name of the ruleset. It is a string value that contains the name of the regulatory body that established the rules and version information. The length of the string MUST NOT exceed 64 US-ASCII characters. NEW Ruleset identifier: The name of the ruleset. See [[ this document ]], Section 8.1 for the format requirements of this identifier. s/New parameters MUST be/New parameters are 9.1.2: OLD as of this writing, it is the only regulatory domain that has finalized rules. There is no intent to restrict the protocol to FCC rules. NEW as of this writing, they are the only regulatory domains that have finalized rules. There is no intent to restrict the protocol to FCC or ETSI rules. 9.1.2.1/9.1.2.2: s/REQUIRED/required and s/OPTIONAL/optional 9.1.1.1: In the DeviceOwner definition, I suggest changing "MUST contain" to "is mandated to contain" (3 times), to make it clear that this is a regulatory requirement, not a protocol requirement. 9.1.2.2: s/MUST NOT exceed 64 octets/See [[ this document ]], Section 5.2 s/MUST respond/is mandated to respond s/MUST set this/is mandated to set this 9.2.2.1: ...MUST NOT exceed 32 US-ASCII characters... If that's a protocol requirement, it belongs in section 5.2. It doesn't belong here. 9.2.2.5 The string value MUST NOT exceed 64 octets in length. Is that an ETSI requirement? Then rewrite as "The ETSI standard specifies that the string value be a maximum of 64 octets in length." Otherwise, strike the sentence. -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sun Jun 22 17:02: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 AE74A1A063A for ; Sun, 22 Jun 2014 17:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 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, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.651, 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 PbdHaI63-QEC for ; Sun, 22 Jun 2014 17:02:42 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6EC81B2796 for ; Sun, 22 Jun 2014 17:02:42 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id hn18so2338078igb.11 for ; Sun, 22 Jun 2014 17:02:42 -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=DjR0/gwDNEwZiRxGIlzWiyUhYgLECcuBLFFCQT4Dmyc=; b=bZ8bmjxukzqW9BYg2JzBlUI09xk8HW4WGk2ZdEzjzv9UUiccXwun16IiHmPhPza73Q JICiM1sY372lR1YT6mWJ5xPALoPpNGLFCranMCu3agSKFJimf0I+nbUpESL2+ztWDs0/ 6Gt5JLgvGYocDg0T0DX1LylIoL6hFbdiooex0RXM6aInPvmoLoUnCpLWnREsX+u1caS7 U5r4fKQhi+jH7W+MrW4ujqw+dBgPk1PbTR/p4OIRlTKl7Qm8WeB4nNDHD/2TBeE56fBt 0xQEQPLs5zpHUmC1LpB6evyK9Do46sCJiKq2LoByO6jyV6pEUNCYTBYjXTLNQJF5Rgm4 Ee3Q== 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=DjR0/gwDNEwZiRxGIlzWiyUhYgLECcuBLFFCQT4Dmyc=; b=Ay8wt1xy0UlFUVuL4rG/6CFdxi3iMERSL4VypT1SEUmdlDf61F6nIwSCCLmF+VU5bo QfhHvT3S3AcMwNDIoXp1L1z2/VgIhTePNkObCTEk1MPuRO1mulu7dasBqRU03n/8IoBG jcV+P5QvQq6fRZxSBc75C7puW4HRGmzlvumFHnE7PBMKuKHGyV9i2B4Ad97lGPmD+SpL PgJkeHlfHH5oOW0j6Au1idixOqJ4EtQFRox2qJmQMg9hWoUH6AC82w3mPrN2O++9hh76 xHYy7xsuR0rMVt8j0Lt0vQrdH3YDB2Lysqkn+GqFueduFlKa3xfTlk4FkdixG5IMDarR jBzQ== X-Gm-Message-State: ALoCoQlGnFc9DFPfn5lIKLunsumTmGYV94bNJHN8U12q1ToE2F4npba1YkurIDRzWYyogVsVDZNR MIME-Version: 1.0 X-Received: by 10.50.4.102 with SMTP id j6mr22160029igj.42.1403481761925; Sun, 22 Jun 2014 17:02:41 -0700 (PDT) Received: by 10.182.3.74 with HTTP; Sun, 22 Jun 2014 17:02:41 -0700 (PDT) In-Reply-To: <53A73852.4060002@qti.qualcomm.com> References: <20140425004136.20484.45101.idtracker@ietfa.amsl.com> <53A73852.4060002@qti.qualcomm.com> Date: Mon, 23 Jun 2014 08:02:41 +0800 Message-ID: From: Vincent Chen To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11c31f6ede859704fc758f15 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/q1FdweA7HfIr3ImKWyTB0q18tSk Cc: "paws@ietf.org" Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-12.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 00:02:45 -0000 --001a11c31f6ede859704fc758f15 Content-Type: text/plain; charset=UTF-8 Pete, Again, thanks for the comments. I am out of town this week, so hope to get the edits in next week. -vince On Mon, Jun 23, 2014 at 4:10 AM, Pete Resnick wrote: > I've sat on this document for far too long. I've sent in the request for > the Last Call, but there are still some outstanding issues. I think these > can be handled during Last Call: > > 3.1 > > NOTE: Regulatory rules contain many device-only requirements that > govern device behavior, independent of any database rules. These > requirements may be complex and involve device behavior that are not > easily parameterized. The ruleset-id parameter provides a mechanism > for the Database to inform the Master Device of the applicable > ruleset without having to express device-side behavior within the > protocol. The ruleset identifier is a string value that contains the > name of the regulatory body that established the rules and version > information, such as "FccTvBandWhiteSpace-2010". > > No change got made to this paragraph between -11 and -12, even though it > still refers to "regulatory rules". Might I suggest: > > NOTE: Some regulatory domains specify sets of requirements for device > behavior that may be complex and not easily parameterized. The > ruleset-id parameter provides a mechanism for the Database to inform > the Master Device of an applicable ruleset, and for devices with > out-of-band knowledge of the particular regulatory domain > requirements to satisfy those requirements, without having to specify > the device-side behavior within the protocol. Ruleset identifiers > will normally contain the name of the regulatory body that > established the rules and version information, such as > "FccTvBandWhiteSpace-2010". > > 5.2: Are the formats of serialNumber, manufacturerId, modelId defined > anywhere? Are they UTF-8? If I'm writing an implementation, how do I know > what these are? > > 5.8 "It MAY contain UTF-8". That's not interoperable. It either "MUST > contain UTF-8" or be completely opaque and therefore strike commentary on > the format. > > 5.16/5.17 "MAY be in any language and contain UTF-8 characters". First, > separate out "MAY be in any language" from the format. But as for the > format, again, that's not interoperable. In this case, I think "MUST be > UTF-8" is the only real choice. > > 8.1: > > s/they MUST be registered/they are registered > s/64 characters/64 octets > > The octets/characters thing doesn't make a difference here, but > consistency is always a fine thing. > > 8.3: s/MAY be defined/can be defined > > 9: > > Insert at the top: "[RFC Editor/IANA: Please replace "[[ this document ]]" > with the RFC number of this document as indicated below, and remove this > note prior to publication.]" > > s/responsible IESG area director should/the IESG shall > > That's automatic, but you can say it as above. > > s/30 days/2 weeks > > Let's make it a normal Last Call length. I think that will make the > logistics work a bit better. > > Also, add on to the end of that paragraph: "Specific criteria that the > Designated Expert should use in assessing registrations are given below in > the description of each registry." > > > 9.1: s/regulatory rules/regulatory domain > > 9.1.1: > > OLD > Ruleset name: The name of the ruleset. It is a string value that > contains the name of the regulatory body that established the > rules and version information. The length of the string MUST NOT > exceed 64 US-ASCII characters. > NEW > Ruleset identifier: The name of the ruleset. See [[ this document ]], > Section 8.1 for the format requirements of this identifier. > > s/New parameters MUST be/New parameters are > > 9.1.2: > > OLD > as of this writing, it is the only regulatory > domain that has finalized rules. There is no intent to restrict the > protocol to FCC rules. > NEW > as of this writing, they are the only regulatory > domains that have finalized rules. There is no intent to restrict the > protocol to FCC or ETSI rules. > > 9.1.2.1/9.1.2.2: s/REQUIRED/required and s/OPTIONAL/optional > > 9.1.1.1: In the DeviceOwner definition, I suggest changing "MUST contain" > to "is mandated to contain" (3 times), to make it clear that this is a > regulatory requirement, not a protocol requirement. > > 9.1.2.2: > > s/MUST NOT exceed 64 octets/See [[ this document ]], Section 5.2 > s/MUST respond/is mandated to respond > s/MUST set this/is mandated to set this > > 9.2.2.1: > > ...MUST NOT exceed 32 US-ASCII characters... > > If that's a protocol requirement, it belongs in section 5.2. It doesn't > belong here. > > 9.2.2.5 > > The string value MUST NOT exceed 64 octets in length. > > Is that an ETSI requirement? Then rewrite as "The ETSI standard specifies > that the string value be a maximum of 64 octets in length." Otherwise, > strike the sentence. > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > -- -vince --001a11c31f6ede859704fc758f15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pete,

Again, thanks for the comments.

I am out of town this week, so hope to get the edit= s in next week.

-vince


On Mon, Jun 23, 2014 at 4:10 AM, Pete Re= snick <presnick@qti.qualcomm.com> wrote:
I've sat on this document for far too long. I've sent in the reques= t for the Last Call, but there are still some outstanding issues. I think t= hese can be handled during Last Call:

3.1

=C2=A0 =C2=A0NOTE: Regulatory rules contain many device-only requirements t= hat
=C2=A0 =C2=A0govern device behavior, independent of any database rules. =C2= =A0These
=C2=A0 =C2=A0requirements may be complex and involve device behavior that a= re not
=C2=A0 =C2=A0easily parameterized. =C2=A0The ruleset-id parameter provides = a mechanism
=C2=A0 =C2=A0for the Database to inform the Master Device of the applicable=
=C2=A0 =C2=A0ruleset without having to express device-side behavior within = the
=C2=A0 =C2=A0protocol. =C2=A0The ruleset identifier is a string value that = contains the
=C2=A0 =C2=A0name of the regulatory body that established the rules and ver= sion
=C2=A0 =C2=A0information, such as "FccTvBandWhiteSpace-2010".

No change got made to this paragraph between -11 and -12, even though it st= ill refers to "regulatory rules". Might I suggest:

=C2=A0 =C2=A0NOTE: Some regulatory domains specify sets of requirements for= device
=C2=A0 =C2=A0behavior that may be complex and not easily parameterized. The=
=C2=A0 =C2=A0ruleset-id parameter provides a mechanism for the Database to = inform
=C2=A0 =C2=A0the Master Device of an applicable ruleset, and for devices wi= th
=C2=A0 =C2=A0out-of-band knowledge of the particular regulatory domain
=C2=A0 =C2=A0requirements to satisfy those requirements, without having to = specify
=C2=A0 =C2=A0the device-side behavior within the protocol. Ruleset identifi= ers
=C2=A0 =C2=A0will normally contain the name of the regulatory body that
=C2=A0 =C2=A0established the rules and version information, such as
=C2=A0 =C2=A0"FccTvBandWhiteSpace-2010".

5.2: Are the formats of serialNumber, manufacturerId, modelId defined anywh= ere? Are they UTF-8? If I'm writing an implementation, how do I know wh= at these are?

5.8 "It MAY contain UTF-8". That's not interoperable. It eith= er "MUST contain UTF-8" or be completely opaque and therefore str= ike commentary on the format.

5.16/5.17 "MAY be in any language and contain UTF-8 characters". = First, separate out "MAY be in any language" from the format. But= as for the format, again, that's not interoperable. In this case, I th= ink "MUST be UTF-8" is the only real choice.

8.1:

=C2=A0 =C2=A0s/they MUST be registered/they are registered
=C2=A0 =C2=A0s/64 characters/64 octets

The octets/characters thing doesn't make a difference here, but consist= ency is always a fine thing.

8.3: s/MAY be defined/can be defined

9:

Insert at the top: "[RFC Editor/IANA: Please replace "[[ this doc= ument ]]" with the RFC number of this document as indicated below, and= remove this note prior to publication.]"

=C2=A0 =C2=A0s/responsible IESG area director should/the IESG shall

That's automatic, but you can say it as above.

=C2=A0 =C2=A0s/30 days/2 weeks

Let's make it a normal Last Call length. I think that will make the log= istics work a bit better.

Also, add on to the end of that paragraph: "Specific criteria that the= Designated Expert should use in assessing registrations are given below in= the description of each registry."


9.1: s/regulatory rules/regulatory domain

9.1.1:

OLD
=C2=A0 =C2=A0Ruleset name: =C2=A0The name of the ruleset. =C2=A0It is a str= ing value that
=C2=A0 =C2=A0 =C2=A0 contains the name of the regulatory body that establis= hed the
=C2=A0 =C2=A0 =C2=A0 rules and version information. =C2=A0The length of the= string MUST NOT
=C2=A0 =C2=A0 =C2=A0 exceed 64 US-ASCII characters.
NEW
=C2=A0 =C2=A0 Ruleset identifier: The name of the ruleset. See [[ this docu= ment ]],
=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 8.1 for the format requirements of this = identifier.

s/New parameters MUST be/New parameters are

9.1.2:

OLD
=C2=A0 =C2=A0as of this writing, it is the only regulatory
=C2=A0 =C2=A0domain that has finalized rules. =C2=A0There is no intent to r= estrict the
=C2=A0 =C2=A0protocol to FCC rules.
NEW
=C2=A0 =C2=A0as of this writing, they are the only regulatory
=C2=A0 =C2=A0domains that have finalized rules. =C2=A0There is no intent to= restrict the
=C2=A0 =C2=A0protocol to FCC or ETSI rules.

9.1.2.1/9.1.2.2: s= /REQUIRED/required and s/OPTIONAL/optional

9.1.1.1: In the DeviceOwne= r definition, I suggest changing "MUST contain" to "is manda= ted to contain" (3 times), to make it clear that this is a regulatory = requirement, not a protocol requirement.

9.1.2.2:

=C2=A0 =C2=A0s/MUST NOT exceed 64 octets/See [[ this document ]], Section 5= .2
=C2=A0 =C2=A0s/MUST respond/is mandated to respond
=C2=A0 =C2=A0s/MUST set this/is mandated to set this

9.2.2.1:

=C2=A0 =C2=A0...MUST NOT exceed 32 US-ASCII characters...

If that's a protocol requirement, it belongs in section 5.2. It doesn&#= 39;t belong here.

9.2.2.5

=C2=A0 =C2=A0The string value MUST NOT exceed 64 octets in length.

Is that an ETSI requirement? Then rewrite as "The ETSI standard specif= ies that the string value be a maximum of 64 octets in length." Otherw= ise, strike the sentence.
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478




-- -vince
--001a11c31f6ede859704fc758f15-- From nobody Mon Jun 23 06:17: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 88DB61B2AB2; Mon, 23 Jun 2014 06:17:52 -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 2lOiQK5qEcmc; Mon, 23 Jun 2014 06:17:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E68821B27A9; Mon, 23 Jun 2014 06:17:50 -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.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140623131750.15457.65678.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 06:17:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/HUCeh0FLQfmBakbZ7QJDsB0GhpI Cc: paws@ietf.org Subject: [paws] 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: Mon, 23 Jun 2014 13:17:52 -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 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-07-07. 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 manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space (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/