--- Begin Message ---
Thanks for the review.
On Thu, Aug 14, 2014 at 10:27 AM, Pearl Liang via RT <
[email protected]> 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, [email protected] 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
> > [email protected] mailing lists by 2014-08-20. Exceptionally, comments may
> be
> > sent to [email protected] 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 ---
