[paws] Fwd: Re: [IANA #777162] Re: Second Last Call: <draft-ietf-paws-protocol-14.txt> (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard
Pete Resnick <presnick@qti.qualcomm.com> Wed, 20 August 2014 01:56 UTC
Return-Path: <presnick@qti.qualcomm.com>
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 <paws@ietfa.amsl.com>; 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 <paws@ietfa.amsl.com>; 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 <paws@ietf.org>; 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 <presnick@qti.qualcomm.com>
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" <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: <draft-ietf-paws-protocol-14.txt> (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\)" <paws.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/paws>, <mailto:paws-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/paws/>
List-Post: <mailto:paws@ietf.org>
List-Help: <mailto:paws-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/paws>, <mailto:paws-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 01:56:45 -0000
--- Begin Message ---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 <iana-issues@iana.org> 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' > > > > <draft-ietf-paws-protocol-14.txt> 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--- End Message ---
- [paws] Second Last Call: <draft-ietf-paws-protoco… The IESG
- [paws] Genart LC review draft-ietf-paws-protocol-… Robert Sparks
- [paws] Fwd: [IANA #775577] Second Last Call: <dra… Pete Resnick
- [paws] Fwd: Re: [IANA #775577] Second Last Call: … Pete Resnick
- [paws] Fwd: [IANA #777162] Re: Second Last Call: … Pete Resnick
- [paws] Fwd: Re: [IANA #777162] Re: Second Last Ca… Pete Resnick
- Re: [paws] [Gen-art] Genart LC review draft-ietf-… Jari Arkko