[paws] Fwd: Re: [IANA #775577] 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 A1D711A8032 for <paws@ietfa.amsl.com>; 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 <paws@ietfa.amsl.com>; 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 <paws@ietf.org>; 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 <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="------------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: <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:13 -0000
--- Begin Message ---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' > > <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