Subject: [paws] Fwd: [IANA #775577] Second Last Call: <draft-ietf-paws-protocol-14.txt> (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard

From: Pete Resnick <[email-masked]>
Date: Tue, 19 Aug 2014 20:55:47 -0500

Subject: [IANA #775577] Second Last Call: <draft-ietf-paws-protocol-14.txt> (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard
From: Pearl Liang via RT <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Thu, 14 Aug 2014 17:27:28 +0000
List-Id: <iesg.ietf.org>

(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 

2) We understand that "Specification document(s)" is the column for Reference.

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-masked] 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-masked] mailing lists by 2014-08-20. Exceptionally, comments may be
> sent to [email-masked] 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/
> 
> 
>

---

From: Pete Resnick <[email-masked]>
Date: Tue, 19 Aug 2014 20:55:57 -0500

Subject: Re: [IANA #775577] Second Last Call: <draft-ietf-paws-protocol-14.txt> (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard
From: Vincent Chen <[email-masked]>
To: <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Fri, 15 Aug 2014 11:27:56 -0700
List-Id: <iesg.ietf.org>

Thanks for the review.

On Thu, Aug 14, 2014 at 10:27 AM, Pearl Liang via RT <
[email-masked]> wrote:

> 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 understands that this document proposes the creation of a PAWS
> protocol registry which will initially consist of three subregistries:
>
> 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.
>
> 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.

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

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.
>
>
> 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
> ]
>
> 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
> ]
>
> 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
> ]
>
> 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
> ]
>
> 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
>
> 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
>

-- 
-vince

---

From: Pete Resnick <[email-masked]>
Date: Tue, 19 Aug 2014 20:56:21 -0500

Subject: [IANA #777162] Re: Second Last Call: <draft-ietf-paws-protocol-14.txt> (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard
From: Pearl Liang via RT <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Tue, 19 Aug 2014 16:55:26 +0000
List-Id: <iesg.ietf.org>

Dear authors,

Please see inline comments/questions marked with [pl].

On Fri Aug 15 18:28:18 2014, [email-masked] wrote:
> > IANA understands that, upon approval of this document there are
> three
> > actions which IANA must complete.
> >
> > New entires in this registry are done through Specification Required
> as
> > defined in RFC 5226.
> >
> |
> |
> > |                   |        |             | Device Type
> |
> > |                   |        |             | of
> |
> > |                   |        |             | the FCC rules.
> |
> >  +-----------+-------
> +-----------------------------------------------+
> > | Name      |       |
> |
> > |           |       | "org".
> |
> > |                         |       |             | device's
> |
> > |                         |       |             | manufacturer's
> |
> > |                         |       |             | identifier. See
> |
> > |                         |       |             | [ RFC-to-be ]
> |
> > |                         |       |             | Section 5.2.
> |
> > |                         |       |             | device's model
> |
> > |                         |       |             | identifier. See
> |
> > |                         |       |             | [ RFC-to-be ]
> |
> > |                         |       |             | Section 5.2.
> |
> > |                         |       |             | device's ETSI
> |
> > |                         |       |             | device type
> |
> > |                         |       |             | (Section
> |
> > |                         |       |             | 9.2.2.3).
> |
> > |                         |       |             | class (Section
> |
> > |                         |       |             | 9.2.2.4).
> |
> > |                         |       |             | device's ETSI
> |
> > |                         |       |             | technology ID
> |
> > |                         |       |             | (Section
> |
> > |                         |       |             | 9.2.2.5).
> |
> > |                         |       |             | device's ETSI
> |
> > |                         |       |             | device category
> |
> > |                         |       |             | (Section
> |
> > |                         |       |             | 9.2.2.6).
> |
> |
> > |             |        |             | Slave Device.
> |
> |
> > |             |        |             | Slave Device.
> |
> > DeviceDescriptor for AVAIL_SPECTRUM_RESP and
> AVAIL_SPECTRUM_BATCH_RESP
> > messages
> > |                                |         | ent      |
> |
> > |                                |         |          | is required
> |
> > |                                |         |          | to set this
> |
> > |                                |         |          | to true to
> |
> > |                                |         |          | indicate
> that |
> > |                                |         |          | the device
> |
> > |                                |         |          | must report
> |
> > |                                |         |          | spectrum
> |
> > |                                |         |          | usage.
> |
> > |                                |         |          | constraint
> on |
> > |                                |         |          | total
> allowed |
> > |                                |         |          | bandwidth.
> |
> > |                                |         |          | constraint
> on |
> > |                                |         |          | total
> allowed |
> > |                                |         |          | contiguous
> |
> > |                                |         |          | bandwidth.
> |
> > |                                |         |          | simultaneous
> |
> > |                                |         |          | channel
> |
> > |                                |         |          | operation
> |
> > |                                |         |          | (Section
> |
> > |                                |         |          | 9.2.2.7). If
> |
> > |                                |         |          | it is not
> |
> > |                                |         |          | provided,
> the |
> > |                                |         |          | default
> value |
> > |                                |         |          | is "0".
> |
> > |                   |       |             | changes.
> |
> > 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
> > 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":
> >
> +-----------------+-----------------+----------------
> +---------------------+-----------------+
> |                 |                 |                |organization
> using
> |                 |                 |                |the "fn"
> property.
> |                 |                 |                |the entry also
> is
> |                 |                 |                |contain the
> "kind"

[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

[pl] Should the same registration procedure apply to all new created Additional Parameter Requirements sub-registries, if you choose to use that?

> > New entires in this registry are done through Specification Required
> as
> > defined in RFC 5226.
> >
> > New entries in this registry are done through Specification Required
> as
> > defined in RFC 5226.
> >
> > ------ ----------------
> ---------------------------------------------
> > 32767 to 1            Unassigned
> > 0      (reserved)
> > -100   (reserved)
> > > [email-masked] mailing lists by 2014-08-20. Exceptionally, comments
> may
> > be

---

From: Pete Resnick <[email-masked]>
Date: Tue, 19 Aug 2014 20:56:32 -0500

Subject: Re: [IANA #777162] Re: Second Last Call: <draft-ietf-paws-protocol-14.txt> (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard
From: Vincent Chen <[email-masked]>
To: <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Tue, 19 Aug 2014 12:16:25 -0700
List-Id: <iesg.ietf.org>

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
)

-vince

On Tue, Aug 19, 2014 at 9:55 AM, Pearl Liang via RT <[email-masked]>
wrote:

> [pl] Should the same registration procedure apply to all new created
> Additional Parameter Requirements sub-registries, if you choose to use that?
>
> >
> > >

-- 
-vince