--- 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 <[email protected]>
wrote:
> Dear authors,
>
> Please see inline comments/questions marked with [pl].
>
> On Fri Aug 15 18:28:18 2014, [email protected] wrote:
> > 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
> >
> >
>
> [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, [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 ---
