Protocol to Access White-Space (PAWS) Databases
draft-ietf-paws-protocol-20

[Ballot comment]
Thanks for all your work to address my DISCUSS!

= Shepherd write-up=
"An in-depth review by a JSON expert might be useful."

Did that happen?

= Section 1 =
"It opens the door for innovations in spectrum
  management that can incorporate a variety of parameters, including
  user location and time.  In the future, it also can include other
  parameters, such as user priority, time, signal type and power,
  spectrum supply and demand, payment or micro-auction bidding, and
  more."

Time seems to be listed both as a current parameter and a future one, which is confusing.

= Section 4.4 =
"FCC rules, for example, require that a 'Fixed Device'
  register its owner and operator contact information, its device
  identifier, its location, and its antenna height."
 
It would be nice to have a citation for the rules referenced here.

= Section 5.1 =
Feel free to ignore this if it's completely misguided, but does altitude really not matter? Are we sure this protocol won't be re-used for devices on airplanes trying to find available spectrum? (I note that in RFC 6953, requirement D.1 specifies that the data model must support "the height and its uncertainty" -- I have no idea what "the height" means or if it is related to altitude.)

= Section 10 =
I agree with Stephen that the database operator should be considered as a potential adversary from the standpoint of potentially being able to create a fine-grained database that tracks the locations and spectrum use patterns of individual devices. That data could certainly be abused.

[Ballot comment]
All the points in the discuss and comment have been addressed.  I am leaving them here for reference.

Section 3 describes spectrum-usage messages as purely informational.  Section 4.5 says that the database can require that such messages be sent.  Which is it: is it sometimes required, or always purely informational?  Or does "purely informational" just mean that the protocol provides no mechanism for tracking such notifications?  It would be helpful if this were clearer.

In 4.1, the database URI change spec seems incomplete.  Is there a time when a database starts announcing its URI change after which it need no longer provide service on the old URI?  I see Alissa asked a similar question, so I imagine you could address both questions together.

In 4.1 and 5.17, the meaning described for UNSUPPORTED appears to be somewhat fluid.  I think you intend for it to mean one specific thing, which might imply one of several other things.  But you don't say the one thing that it means: instead you mention possible implications.  It would be helpful to try to make this more explicit.

I think Stephen noticed this same problem, but to be clear, it appears that section 4.5 says that when the master is sending a request on behalf of a slave, it sends its own location.  But section 4.5.1 says that the master sends the slave's location.  It appears that there are two parameters, one being the master location, which is required, and the other being the slave location, which is optional.  However, this is never really stated explicitly; it might be helpful if it were.

I have to confess that the use of "master" and "slave" throughout this document makes me quite uncomfortable in reading it.  It would really be preferable to use terms that have less painful history associated with them, like "core" and "leaf" or "coordinator" and "supplicant."  I realize this is a matter of taste, and I do not at all mean to suggest that there's anything wrong with the use of these terms, which are certainly common in the computing industry.  This is just a comment, and whether you address it is entirely up to you.

In 4.6.1, it would help to have text that explains what it means to validate a device.  It's certainly not required for interoperability, but might be helpful for implementors of database servers.

In 5.3, it's a little puzzling that antenna direction, radiation pattern, gain and polarization aren't defined, because they seem like properties that should have universal applicability, even if they are not required in all cases.  Is this being left as future work, or is there some more subtle reason why these haven't been defined explicitly?

In 5.11, power is expressed in dbm, which leads me to wonder if this is the product of the antenna gain and the input power to the output amplifier, or whether it's just the input power to the amplifier, or whether it's being left intentionally ambiguous.

Former DISCUSS points:

This is a cool document—I'm glad the IETF is working on this.  Please don't take the following comments as anything other than an attempt to address what I think are some relatively minor issues with the document, hopefully easily addressed.

4.1 says "Some regulatory domains may have specific rules regarding how long the spectrum data remains valid in these cases."  It might be worth adding that in such cases the initialization procedure is required.  This is addressed to some extent in section 4.3, but I'm not sure it's completely addressed.  The potential problem I see is that a device might be used in a regulatory regime where this is required, but might have pre-configured values for some other regulatory regime.  If these values are not valid in the regime that applies for its current location, it might have a too-long refresh interval configured, fail to detect that this is the case, and as a result accidentally break the law.  Can a scenario like this occur in practice?

Section 5.2 says that the manufacturer ID and model ID are optional, but may be required by some rulesets.  Section 4.3.1 does not say what error is returned when a deviceDesc that does not contain one or both of these parameters is sent to the server, but the matching ruleset requires either parameter.  I suspect the answer is straightforward, but I think it needs to be stated explicitly in 4.3.1.  E.g., if the optional but required parameters are accepted in the initialization but rejected in the registration, it would be good to say so explicitly.

In 4.4.2, I think that if none of the rulesets are accepted, the intent is that the database should return a REGISTRATION_RESP with the error element, and will not return a rulesetInfos list.  However, the specification does not make an exception for this case when it says "A RulesetInfo list MUST be included" and  "The list MUST contain at least one entry".  I can't think of another valid interpretation, but you've stated a MUST, so you need to say that it doesn't apply in the case of the error.

In 4.5:

      If some
      locations within a batch request are outside the regulatory
      domain supported by the Database, the Database MAY return an OK
      response with available spectrum for only the valid locations;
      otherwise, if all locations within a batch request are outside
      the regulatory domain, the Database MUST respond with an
      OUTSIDE_COVERAGE error.

What should the database do if it doesn't follow the MAY?  Should it return an OUTSIDE_COVERAGE error?  It seems to me that this MAY is going to require some unclear heuristics on the side of the master device.  Why isn't this a MUST?  I think if this were a MUST, it would be clear how implementations should behave; by making it a MAY, there's a big gap that I think will lead to interoperability problems as different implementors make different choices about how to treat this situation.

[Ballot comment]


Thanks for sorting out my discuss points.

I didn't fully check the location stuff is now all ok, but I
expect that since others had related discuss points
it'll be checked more thoroughly (and it looks ok to
me too)

S.


--- old comments below, didn't check if they were handled or
not, but feel free to keep chatting about 'em if that's useful

- write-up: its a pity that coders haven't gotten together more
openly and done interop, but I guess different businesses are
different.

- section 1, last para: I realise authorized devices is what
the WG are interested in, but the protocol ought not require
that, so the last sentence here is wrong - it surely should
be: s/device is authorized to operate/device operates/

- Ruleset: I hope there's a NULL, meaning "no rules":-)

- 4.4.1 - nothing stops a device lying about location, right?

- 4.5 - the slave location vs. master location seems unclear
to me. Can you clarify?

- 4.5.1 - timestamp has to be UTC right? You only seem to
indicate that via the "Z" in the timestamp format which I
expect could be easily missed. Suggest you emphasise that. You
should probably also say if truncated timestamps are ok, for
example just to the minute granularity without specifying
seconds.  I assume that's not allowed? And lastly, please
specify if the start (resp. end) of the second (or whatever)
unit is when a device gains (resp. looses) spectrum. (Or add a
global statement on timezones where you earlier said that
identifiers are case sensitive by default.) Some of this is in
5.14, but I'm not sure if that's enough. (It could be.)

- 5.2 - I don't get why you need X.520 here.

- 5.5 - could a vCard value just be (the moral equivalent of)
"Internet" or "I'm not telling"?

- section 7: Saying the master device MUST implement server
auth is confusing, since the master device is the TLS client,
right?

- Section 10: Under the privacy bullet you should also
recognise that an authorized entity can be privacy invasive
(e.g. selling contact information, sending all on to law
enforcement without permission).

- Section 10: Given diginotar and similar (incl. by nation
states), having the master device send its identifying
information in its first message means that simply saying "use
TLS" is not enough. You need to say "TLS, assuming the PKI
used is ok,..." or similar.

[Ballot discuss]
This is a cool document—I'm glad the IETF is working on this.  Please don't take the following comments as anything other than an attempt to address what I think are some relatively minor issues with the document, hopefully easily addressed.

4.1 says "Some regulatory domains may have specific rules regarding how long the spectrum data remains valid in these cases."  It might be worth adding that in such cases the initialization procedure is required.  This is addressed to some extent in section 4.3, but I'm not sure it's completely addressed.  The potential problem I see is that a device might be used in a regulatory regime where this is required, but might have pre-configured values for some other regulatory regime.  If these values are not valid in the regime that applies for its current location, it might have a too-long refresh interval configured, fail to detect that this is the case, and as a result accidentally break the law.  Can a scenario like this occur in practice?

Section 5.2 says that the manufacturer ID and model ID are optional, but may be required by some rulesets.  Section 4.3.1 does not say what error is returned when a deviceDesc that does not contain one or both of these parameters is sent to the server, but the matching ruleset requires either parameter.  I suspect the answer is straightforward, but I think it needs to be stated explicitly in 4.3.1.  E.g., if the optional but required parameters are accepted in the initialization but rejected in the registration, it would be good to say so explicitly.

In 4.4.2, I think that if none of the rulesets are accepted, the intent is that the database should return a REGISTRATION_RESP with the error element, and will not return a rulesetInfos list.  However, the specification does not make an exception for this case when it says "A RulesetInfo list MUST be included" and  "The list MUST contain at least one entry".  I can't think of another valid interpretation, but you've stated a MUST, so you need to say that it doesn't apply in the case of the error.

In 4.5:

      If some
      locations within a batch request are outside the regulatory
      domain supported by the Database, the Database MAY return an OK
      response with available spectrum for only the valid locations;
      otherwise, if all locations within a batch request are outside
      the regulatory domain, the Database MUST respond with an
      OUTSIDE_COVERAGE error.

What should the database do if it doesn't follow the MAY?  Should it return an OUTSIDE_COVERAGE error?  It seems to me that this MAY is going to require some unclear heuristics on the side of the master device.  Why isn't this a MUST?  I think if this were a MUST, it would be clear how implementations should behave; by making it a MAY, there's a big gap that I think will lead to interoperability problems as different implementors make different choices about how to treat this situation.

[Ballot comment]
Section 3 describes spectrum-usage messages as purely informational.  Section 4.5 says that the database can require that such messages be sent.  Which is it: is it sometimes required, or always purely informational?  Or does "purely informational" just mean that the protocol provides no mechanism for tracking such notifications?  It would be helpful if this were clearer.

In 4.1, the database URI change spec seems incomplete.  Is there a time when a database starts announcing its URI change after which it need no longer provide service on the old URI?  I see Alissa asked a similar question, so I imagine you could address both questions together.

In 4.1 and 5.17, the meaning described for UNSUPPORTED appears to be somewhat fluid.  I think you intend for it to mean one specific thing, which might imply one of several other things.  But you don't say the one thing that it means: instead you mention possible implications.  It would be helpful to try to make this more explicit.

I think Stephen noticed this same problem, but to be clear, it appears that section 4.5 says that when the master is sending a request on behalf of a slave, it sends its own location.  But section 4.5.1 says that the master sends the slave's location.  It appears that there are two parameters, one being the master location, which is required, and the other being the slave location, which is optional.  However, this is never really stated explicitly; it might be helpful if it were.

I have to confess that the use of "master" and "slave" throughout this document makes me quite uncomfortable in reading it.  It would really be preferable to use terms that have less painful history associated with them, like "core" and "leaf" or "coordinator" and "supplicant."  I realize this is a matter of taste, and I do not at all mean to suggest that there's anything wrong with the use of these terms, which are certainly common in the computing industry.  This is just a comment, and whether you address it is entirely up to you.

In 4.6.1, it would help to have text that explains what it means to validate a device.  It's certainly not required for interoperability, but might be helpful for implementors of database servers.

In 5.3, it's a little puzzling that antenna direction, radiation pattern, gain and polarization aren't defined, because they seem like properties that should have universal applicability, even if they are not required in all cases.  Is this being left as future work, or is there some more subtle reason why these haven't been defined explicitly?

In 5.11, power is expressed in dbm, which leads me to wonder if this is the product of the antenna gain and the input power to the output amplifier, or whether it's just the input power to the amplifier, or whether it's being left intentionally ambiguous.

[Ballot comment]
I support Alissa's discuss - clarifying what is in the location, privacy around why point is required, and other privacy concerns.

Also - I note the 3 IPR claims for a, sorry, not particularly innovate (to my eyes) protocol - where the terms are RAND with reciprocity and RAND with possible royalty.  Those look like they'd kill any open source implementation?

[Ballot discuss]
Thanks for doing this work, the draft looks good and my discuss should be easy enough to address as I am just looking for some clarifying information that may be helpful if I didn't miss the answer somewhere else.

Can clients query any database entries or is the interface restricted to the list of supported interactions?  I assume the answer is that it is limited to the set of database interactions defined, but could not find any statement saying that in this draft or the prior requirements in RFC6953.

Authentication is only a MAY in the Security Considerations Section, which raises another possible concern for me. 

Since clients can get back pretty much all of the defined datatypes (DeviceDescriptor is one example) and authentication is not required, there should be a discussion on the risks of revealing this information for both the privacy reasons Stephen and Alissa outlined as well as possible security concerns.  I think this should be on a field basis in terms of sensitive elements where relevant.

I could see how you might want/need the types of information gathered within an administrative domain or accessed by a restricted set of users, but revealing data like what is contained in deviceDescriptor (includes model) as well as sensitive fields in other classes (AntennaCharacteristics) seems like a risk as it could be used in targeted attacks if there are known vulnerabilities to those devices.  The attacks could target specific regions at specific times to effect events or to be used as part of some larger attack (could include physical).  This may sound crazy, but layered attacks are very real. 

Is there anything that prevents a client from fingerprinting?

Perhaps recommendations at the field level would help implementors understand these risks (privacy & security) and then they may be more motivated to enable authenticated and encrypted access.  This wouldn't be necessary for all fields, just the ones that could be used in attacks or reveal privacy related information.  Implementers may take the optional field use more seriously or create options in application interfaces so that users are then aware of the risks with these fields and make different choices.  Ideally, there would be a limited set of data returned based on role information so that devices or other clients only get what they need as opposed to what is available.  I didn't see any mention of restrictions on who could access what (role based access), is that possible?  I'm not sure if the primary & secondary users allow for this?

Thanks in advance.

[Ballot comment]
"""
  [RFC Editor: In the Author's Addresses section, please list
  "iconectiv" as "iconectiv (formerly Telcordia Interconnection
  Solutions).  One occurrence."]
"""
Just make the edit yourself?


The document uses the terms "primary user" and "secondary user".  It would be helpful to define them.

"... the Master Device may verify with the Database that the Slave Device is valid"
How is "valid" being used here?

It seems a little constraining to describe this as a protocol between the Master Device and the database.  Might this protocol also be used between a Slave Device and a Master Device?

Section 5.1 seems to imply that a Geolocation object MUST NOT include both "point" and "region" components.  Is that case?  If so, that seems unfortunate; since region support is optional, it seems like it would be helpful for a client to be able to include a point as a fall-back.

[Ballot comment]
Stephen asked a geolocation question about RFC 6953 as it was being
processed to try to establish whether the location information supplied
for a query needed to be the location of the querrier or the location
about which the querry is being made. Going back to the text in 1.2 of
6953, it is pretty clear that the intent is to issue a queery that
relates to the whitespace at a location.

Given this, I agree with Stephen that including location info in the
INIT_REQ and REGISTRATION_REQ seems unnecessary. It seems to be being
used as some form of authorisation check, and I don't see how that is
safe or valid. But also I don't see what stops the sender from lying.
Surely the important thing is about where the whitespace is available,
not from where the requester operates?

But even in 4.5.1 there is some confusion...

  location:  The GeoLocation (Section 5.1) for the device requesting
      available spectrum.  The location SHOULD be the current location
      of the device, but more precisely, the location of the radiation
      center of the device's antenna.  When the request is made by the
      Master Device on its own behalf, the location is that of the
      Master Device and it is REQUIRED.  When the request is made by the
      Master Device on behalf of a Slave Device, the location is that of
      the Slave Device and it is OPTIONAL (see also
      masterDeviceLocation).  The location may be an anticipated
      position of the device to support mobile devices, but its use
      depends on the ruleset.  If the location specifies a region,
      rather than a point, the Database MAY return an error with the
      UNIMPLEMENTED (Table 1) code, if it does not implement query by
      region.

I don't see why you have SHOULD given the subsequent lowercase may.
Surely you need "the location it the location about which the enquiry
is being made."

Reading all this and going back to 6953 I am not sure I understand the
difference between having permission to operate on a frequency at a
location (which seems to be granted by registration) and discovering
which frequencies are available (which seems to be determined by
AVAIL_SPECTRUM_RESP).

Clearly I am missing something in my read through. If you think it is
already covered, that's fine. But if not, perhaps you could add some
text to explain things.

[Ballot discuss]
I'm glad this work is being done in the IETF, thanks for all your effort.

A couple of my points below have overlaps with some of Stephen's points.

= Shepherd write-up =
"Yes, there were 2 IPR disclosures filed that reference this document.
They were discussed in the WG, and nobody came forward to say that they'd like to change anything in the document because of the disclosures."

But there are 3 IPR disclosures in the tracker, not 2. Were all three discussed in the WG?

= Section 4.1 =
"A Database MAY change its URI, but before it changes its URI, it MUST
  indicate so by including the URI of one or more alternate databases
  using DbUpdateSpec (Section 5.7) in its responses to devices."

The behavior here seems ambiguous. Does the database need to send responses containing the updated URI to all devices it has ever communicated with, or all registered devices, before it can actually change the URI? Does the database even maintain such lists? If not, how many such responses does it need to send out before changing its URI, or how long does it need to wait? Just saying that sending the new URI needs to happen "before" the URI changes does not seem specific enough for devices to know whether the URI has changed, or for databases to know when they can disable an old URI or stop sending the DbUpdateSpec indication.

= Section 4.5 =
These two sentences seem to contradict each other:

"The device identifier, capabilities, and characteristics
  communicated in the AVAIL_SPECTRUM_REQ message MUST be those of the
  Slave Device, but the location MUST be that of the Master Device."

"When the request is made by the
      Master Device on behalf of a Slave Device, the location is that of
      the Slave Device and it is OPTIONAL (see also
      masterDeviceLocation)."

Perhaps this can be solved by making the reference to "the location" in the first sentence more specific -- the masterDeviceLocation -- but I'm not really sure from reading the text.

Then later in the section, I started getting even more confused by this:

"When the request is made by the
      Master Device on behalf of a Slave Device, the location is that of
      the Slave Device and it is OPTIONAL (see also
      masterDeviceLocation).
      ...
masterDeviceLocation:  When the request is made by the Master Device
      on behalf of a Slave Device, the Master Device MAY provide its own
      GeoLocation (Section 5.1)."

Does this mean it's acceptable for a Master device acting on behalf of a Slave device to send neither the Slave device location (in the location parameter) nor the Master device location (in the masterDeviceLocation parameter)? I believe that the current text allows this. If so, why is location required in the registration step (and in batch available spectrum requests) but not in the available spectrum step? Seems like it should be the other way around -- that a device could register without specifying its location, but not request available spectrum without it.

If the above interpretation was not intended, something needs to be fixed in one part or the other of the above text to indicate that either the Master device location or the Slave device location (or both) must be present in the request.

The same issue arises in Section 4.5.5.

= Section 5.1 =
I'd like to discuss why the single point location format needs to be supported here. Is it really the case that a portion of whitespace spectrum will ever be available only at a single point, as opposed to a region? If not, it seems like sending a point (and, moreover, allowing region to be unsupported but not point) divulges more precise information about the requesting device than is ever actually necessary to fulfill the goals of this protocol. Do regulators require a single point? Why?

= Section 5.2 =
I'd like to discuss why the device serial number needs to be included in the device descriptor, rather than some (perhaps persistent) randomly generated device identifier that is used only in the context of this protocol (which would better protect the privacy of the user of the device, since the whitespaces database administrator wouldn't be able to correlate the device's spectrum requests with other activities linked to the serial number). It's not really clear why serial number is collected since both this document and RFC 6953 note the protocol does not defend against abuse or mis-use of spectrum.

I'm asking the above two questions in light of requirement P.7 from RFC 6953, "The PAWS protocol SHOULD support privacy-sensitive handling of device-provided data where such protection is feasible, allowed, and desired."

A separate interesting question that does not seem to be addressed anywhere in the draft is whether a device can be fingerprinted by the database operator by virtue of the collection of elements it sends (rulesetIds, manufacturer, model, antenna characteristics, device capabilities, etc.) even if it doesn't send a serial number or device owner information that uniquely identify it. That seems worth discussion in Section 10.

[Ballot comment]
= Shepherd write-up=
"An in-depth review by a JSON expert might be useful."

Did that happen?

= Section 1 =
"It opens the door for innovations in spectrum
  management that can incorporate a variety of parameters, including
  user location and time.  In the future, it also can include other
  parameters, such as user priority, time, signal type and power,
  spectrum supply and demand, payment or micro-auction bidding, and
  more."

Time seems to be listed both as a current parameter and a future one, which is confusing.

= Section 4.4 =
"FCC rules, for example, require that a 'Fixed Device'
  register its owner and operator contact information, its device
  identifier, its location, and its antenna height."
 
It would be nice to have a citation for the rules referenced here.

= Section 5.1 =
Feel free to ignore this if it's completely misguided, but does altitude really not matter? Are we sure this protocol won't be re-used for devices on airplanes trying to find available spectrum? (I note that in RFC 6953, requirement D.1 specifies that the data model must support "the height and its uncertainty" -- I have no idea what "the height" means or if it is related to altitude.)

= Section 10 =
I agree with Stephen that the database operator should be considered as a potential adversary from the standpoint of potentially being able to create a fine-grained database that tracks the locations and spectrum use patterns of individual devices. That data could certainly be abused.

[Ballot discuss]

Hi, I've a few things to discuss, but I think only the first
is possibly tricky...

(1) 4.4.1 - why are location and deviceOwner required? The FCC
may require those but why does the protocol? I don't see that
those are needed for interop. Isn't that latter the right
criterion for inclusion as a required field? I could see a
reason for the location-from-which-I-want-to-use-WS but that's
not what is described I think. The discuss here is both
relating to the privacy issues with requiring exposure of
identifying information but also relating to the criteria used
to determine required vs. optional and how those map to
interop vs. to current known sets of regulatory rules.  (Same
for 5.2 serialNumber, though there a dynamic/random choice may
be needed instead.)

(2) 4.4.1 - is the location here the location of the device or
the location from which spectrum is to be used? I think you
need to disambiguate those. I continue to think there should
be a way to ask for spectrum in London, tomorrow; even whilst
still in Dublin, today. 4.5.1 seems to imply this may be
allowed sometimes, but I'm not clear if that works - how would
the "tomorrow" value be sent?

(3) Section 7: I think it'd be a good idea to either reference
the UTA TLS BCP for ciphersuites etc or else (if you'd rather
not have a dependency to another WG's I-D, which I'd
understand) to specify some here. The MTIs from 5246 are
looking pretty jaded right now. You may also want to mandate
use of OCSP or even stapling - there are a few more TLS things
you can do that help interop and to speed things up. I'm not
trying to insist you do/document all of those things, but
would like to chat about it for a bit.

(4) Section 7: You are assuming some kind of PKI is used to
authenticate DBs. Now that might work with the current Web
PKI, except that then any public Web PKI CA can fake any DB
but are regulator's ok with that? Secondly, TLS requires that
the DB nominate the acceptable CAs for client auth, so there's
a bit of specification missing here which is maybe that a DB's
description needs to include information about its acceptable
trust anchors. I don't think you necessarily need to fix all
of that in this document, but what is the plan here? (And
maybe some of it ought be fixed here, not sure.)

[Ballot comment]

- write-up: its a pity that coders haven't gotten together more
openly and done interop, but I guess different businesses are
different.

- section 1, last para: I realise authorized devices is what
the WG are interested in, but the protocol ought not require
that, so the last sentence here is wrong - it surely should
be: s/device is authorized to operate/device operates/

- Ruleset: I hope there's a NULL, meaning "no rules":-)

- 4.4.1 - nothing stops a device lying about location, right?

- 4.5 - the slave location vs. master location seems unclear
to me. Can you clarify?

- 4.5.1 - timestamp has to be UTC right? You only seem to
indicate that via the "Z" in the timestamp format which I
expect could be easily missed. Suggest you emphasise that. You
should probably also say if truncated timestamps are ok, for
example just to the minute granularity without specifying
seconds.  I assume that's not allowed? And lastly, please
specify if the start (resp. end) of the second (or whatever)
unit is when a device gains (resp. looses) spectrum. (Or add a
global statement on timezones where you earlier said that
identifiers are case sensitive by default.) Some of this is in
5.14, but I'm not sure if that's enough. (It could be.)

- 5.2 - I don't get why you need X.520 here.

- 5.5 - could a vCard value just be (the moral equivalent of)
"Internet" or "I'm not telling"?

- section 7: Saying the master device MUST implement server
auth is confusing, since the master device is the TLS client,
right?

- Section 10: Under the privacy bullet you should also
recognise that an authorized entity can be privacy invasive
(e.g. selling contact information, sending all on to law
enforcement without permission).

- Section 10: Given diginotar and similar (incl. by nation
states), having the master device send its identifying
information in its first message means that simply saying "use
TLS" is not enough. You need to say "TLS, assuming the PKI
used is ok,..." or similar.

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.

[Ballot comment]
Vince handled all my comments during last call, and I'm happy with this version.  Thanks, especially, for all the work that went into re-doing Section 6.

Note added 'This document had a second Last Call. There are unlikely to be more Last Call comments, so feel free to review before Last Call completes.'

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Second Last Call:  (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard


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'
  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/

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-paws-protocol-12.  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 [ RFFC-to-be ].

In the new PAWS registry there will be three subregistries 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 Expert Review as defined in RFC 5226.

There are two initial entries in this new registry as follows:

Ruleset name:  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 MUST contain the formatted name of  |
|          |      | an individual or organization using the "fn"  |
|          |      | property. When the name is that of an        |
|          |      | organization, the entry also MUST contain the |
|          |      | "kind" property, with a value of "org".      |
| operator  | vCard | The operator entry MUST contain the following |
|          |      | properties for the contact person responsible |
|          |      | for the device's operation: "fn", "adr",      |
|          |      | "tel", and "email".                          |
+-----------+-------+-----------------------------------------------+

Ruleset name:  ETSI-EN-301-598-1.0.9-draft
Specification document(s):  This ruleset refers to the ETSI Harmonised Standard established by ETSI.
Additional Parameter Requirements for ETSI-EN-301-598-1.0.9-draft:

DeviceDescriptor
+-------------------------+-------+-------------+-------------------+
| Parameter Name          | Type  | Requirement | Notes            |
+-------------------------+-------+-------------+-------------------+
| manufacturerId          | string| REQUIRED    | Specifies a      |
|                        |      |            | device's          |
|                        |      |            | manufacturer's    |
|                        |      |            | identifier. MUST  |
|                        |      |            | NOT exceed 64    |
|                        |      |            | octets.          |
| modelId                | string| REQUIRED    | Specifies a      |
|                        |      |            | device's model    |
|                        |      |            | identifier. MUST  |
|                        |      |            | NOT exceed 64    |
|                        |      |            | octets.          |
| etsiEnDeviceType        | string| REQUIRED    | Specifies the    |
|                        |      |            | device's ETSI    |
|                        |      |            | device type      |
| etsiEnDeviceEmissionsCl | string| REQUIRED    | Specifies the    |
| ass                    |      |            | device's ETSI    |
|                        |      |            | device emissions  |
|                        |      |            | class            |
| etsiEnTechnologyId      | string| REQUIRED    | Specifies the    |
|                        |      |            | device's ETSI    |
|                        |      |            | technology ID    |
| etsiEnDeviceCategory    | string| REQUIRED    | Specifies the    |
|                        |      |            | device's ETSI    |
|                        |      |            | device category  |
+-------------------------+-------+-------------+-------------------+

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    |
|            |        |            | MUST 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    |
|            |        |            | MUST 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            | boole | REQUIRED | The Database  |
|                                | an    |          | MUST 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| OPTIONAL | Specifies a  |
| tionRestriction                |      |          | constraint on |
|                                |      |          | simultaneous  |
|                                |      |          | channel      |
|                                |      |          | operation.    |
|                                |      |          | 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.                |
+-------------------+-------+-------------+-------------------------+

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 Expert Review 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 Harmonised Standard
 
Parameter name:  etsiEnDeviceEmissionsClass
Parameter usage location:  DeviceDescriptor
Specification document(s):  Specifies the White Space Device emissions class, as defined by the ETSI Harmonised Standard
 
Parameter name:  etsiEnTechnologyId
Parameter usage location:  DeviceDescriptor
Specification document(s):  Specifies the White Space Device technology identifier, as defined by the ETSI Harmonised Standard
 
Parameter name:  etsiEnDeviceCategory
Parameter usage location:  DeviceDescriptor
Specification document(s):  Specifies the White Space Device category, as defined by the ETSI Harmonised Standard
 
Parameter name:  etsiEnSimultaneousChannelOperationRestriction
Parameter usage location:  SpectrumSpec
Specification document(s):  Specifies the constraint on the device maximum total EIRP, as defined by the ETSI Harmonised Standard

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 Expert Review 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
------ ---------------- ---------------------------------------------
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

QUESTION: Are codes 1 - 32767 (positive values) unassigned?
The above table appears to talk about -100s, -200s, -300s, 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Protocol to Access White-Space (PAWS) Databases) to Proposed Standard


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'
  as Proposed Standard

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-07-07. 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 manage 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/

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document is intended to be published as proposed standard, as indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

Portions of the radio spectrum that are allocated to licensees are
  available for non-interfering use. 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 manage 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".

Working Group Summary

During the design of the protocol, in earlier phases, there was some controversy, even deadlock at some point over a few points. But things got sorted out, and for the last 3 versions of the document there were no substantial comments, the wg has consensus on the current content of the document.

Document Quality

During private conversations, several mailing list members indicated to me that they have an implementation of a version of the protocol, but none came forward publicly with their implementations yet, and there was no request to hold an interop event.


Personnel

Document Shepherd is Gabor Bajko.
Responsible Area  Director is Pete Resnick.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I reviewed the document and my comments were  incorporated. It is the Document Shepherd's belief that the document is ready for IESG review.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No. Several people reviewed the document.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

An in-depth review by a JSON expert might be useful.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No such concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

Yes, there were 2 IPR disclosures filed that reference this document.
They were discussed in the WG, and nobody came forward to say that they'd like to change anything in the document because of the disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

It is the Document Shepherd's understanding that the WG has consensus on the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The latest version does not have any ID nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No protocol extensions in the document.
IANA registries have been identified.
the newly proposed IANA registries include a detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested. A quick doublecheck with IANA was also done.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

3 new IANA regitries are proposed:
PAWS Parameters Registry
PAWS Ruleset ID Registry
PAWS Error Code Registry
They all require Expert Review for inclusion of additional parameters.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

The JSON examples were validated.