Subject: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10

From: Pete Resnick <[email-masked]>
Date: Wed, 23 Jan 2013 14:54:21 -0600

At long last, I got through my AD review of 
draft-ietf-paws-problem-stmt-usecases-rqmts. I first want to say that 
this draft is very much improved. The comments I have below are not (as 
far as I can tell) showstoppers. I have not had a chance to go through 
all of the commentary in Anthony's note from last week yet; I wanted to 
get this out ASAP, so if there are things in the note that answer some 
of my comments below, let me know.

Now: Don't Panic! As I said, none of the issues are showstoppers. But 
the list is long. I am willing to take direction from the chairs on 
this: I'll wait at least until tomorrow to issue the IETF wide Last 
Call. If upon reviewing these, the WG thinks, "Gee, if Pete didn't get 
the point there, perhaps we should fix the document before issuing the 
Last Call", let me know that and I'll hold off for a bit. But if you 
think all of these issues can be handled easily along with the rest of 
the Last Call comments, I'll go ahead and issue the Last Call and you 
can put these into your queue along with any new comments received.

So, here are the comments. If you can have a look in the next 24 hours, 
that would be great.

------

Abstract: End of the first paragraph, perhaps add: "The IETF has 
undertaken to develop a protocol for that management database."

Also add the above to 1.1.

1.2.1: Are 2 & 3 combinable? "Connect to and optionally register with 
the database using a well-defined protocol."

2.2: For "Device ID", it says, "that identifies the manufacturer, model 
number, and serial number." Does the device ID have to identify that 
information? Can it simply be unique?

"Device Class" is only used once in section 5.1. No need for the 
definition here.

"Location Based Service" is only used once in section 3. No need for the 
definition here.

"Protected Entity" is only used once in section 4.1. No need for the 
definition here.

"Protected Contour" is never used. No need for the definition at all.

"Radio Access Technology" is only used once in section 5.1. No need for 
the definition here.

3.1 This section (and its subsections) seems oddly placed. It is not use 
cases, but general protocol services that cut across use cases. Perhaps 
3.1 and 3.2 should be separate top-level sections?

3.1 "A complete protocol solution must enable all potential white space 
services." That seems a bit absolute. How about "must enable many 
different potential white space services"?

3.1.1 & 3.1.2: Throughout this section, there's no need to use the term 
"master". These services exist whether a device is acting as a master 
for other devices or whether it is acting on its own. Given that there's 
been no discussion of slave devices yet (that happens in 3.2), I found 
the use of the term "master" confusing in these sections. (I suppose you 
could expand the definition of master in 2.2 to explain that it could 
refer to a device acting on its own with no slaves, but I still think 
that might be confusing.

3.1.1, item 2: This says that the device will discover the database "in 
the local regulatory domain". How does the device determine the "local 
regulatory domain"? I suspect that the phrase "in the local regulatory 
domain" is meaningless for purposes of this sentence. If it is not, 
there's something that's not explained.

3.1.2: Similar questions regarding regulatory domains. For example, "2.  
To register with the database, the master device sends the database the 
registration information required under regulatory rules." How does the 
device determine which regulatory rules it is under and therefore which 
information to send to the database. If the answer is, "It queries the 
database", then it is not the regulatory rules the device cares about; 
it is the information the database is configured to ask for (which will 
presumably be in accordance to some regulations, but are out of band of 
any protocol work). If the answer is, "It is pre-configured in the 
device", then the regulatory rules are again out of band. Either way, 
mention of them would be unnecessary.

3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in 
2.2, it's only a slave for purposes of talking to the database. But 
there is an implication in these sections that the slave device uses the 
master for internet connectivity. I don't think that's the intent, but 
either way there's some clarification that's needed. Further confusing 
me about this point is (a) the master device is always the one in the 
diagrams with the antenna, but as far as I can tell, a master device 
doesn't need an antenna, the slaves do; and (b) most of the links marked 
"Air" seem to me not to require an air interface, but could also be 
wired. I could use some explanation.

3.2.1, item 7: Does the slave provide its location, device identifier, 
and antenna height, the same way the master does when it queries? If so 
(especially in the case of the master sub-allocating for the slaves), 
doesn't the master have to provide the set of locations for all of the 
slaves in step 5? Some further explanation might be in order.

3.2.1, item 8: It says that the white space is allocated to slaves "for 
communication over the network". That's not right is it? In this 
scenario, the allocated white space could be used for network (I read 
"Internet") communication *or anything else*, can't it?

3.2.1, item 9: Is this an important part of the scenario? Why wouldn't 
it be perfectly reasonable for communication between the master and 
slaves continue on its original connection and that the white space is 
only used for other communications the slave wishes to do?

3.2.2: This scenario was confusing to me because the master seems 
completely unnecessary to the example. Please explain.

3.2.4 and 3.2.5: Another example of the term "master" seems unnecessary 
in the example, since there are no slaves.

4: "Master" seems unnecessary to the example. Also, I suggest in the 
second-to-last paragraph, you say "The databases are locale specific" 
instead of "country specific", and delete the word "competing" from the 
last sentence of that paragraph.

4.1, item 1: Is this referring to the Internet connectivity between the 
WS device and the database? If so, as above, does it necessarily need to 
be an air interface?

4.1, item 3: Again I suggest changing "operate in any country" to 
"operate in any locale" and change "country-specific" to 
"locale-specific". (The other occurrence of "country" seems correct.)

4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply 
"domain" be sufficient?

5.1 and 5.2: I don't understand the distinction between "Normative" and 
"Non-normative" requirements in this context. Isn't it sufficient that 
you've separately labeled "Data Model Requirements", "Protocol 
Requirements", and "Operational Requirements"?

P.1: "The master device may validate the database against a list of 
approved databases maintained by a regulatory body." I don't understand 
that as a protocol requirement. What is being required?

P.5 and P.6: The requirement here is for *message-level* integrity and 
encryption? That's OK, but I want to make sure that's what you mean.

P.8 and P.14: I don't think "result codes" and "response codes" are the 
requirement here, are they? It sounds like the requirement is 
"indication of success or failure".

P.15: I'm not clear on what this requirement means in practical terms. 
Some more explanation seems in order.

P.16: Shouldn't this be combined with P.9?

O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy 
required by the database"?

O.3: This seems to indicate that database discovery will be out of band, 
that the WG is not developing protocol to do so. Is that what you meant? 
If not, this should be turned into a protocol requirement instead of an 
operational requirement.

O.4: This requirement seems a bit overly obvious and silly to state as a 
requirement. Why is it necessary to say that you need a connection?

O.5: Again, "regulatory body" seems unnecessary here. Substituting 
"database" seems sufficient, since you'll be getting the rule set from 
the database.

O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can 
change "local regulatory policy" to "the database rule set", "determined 
by regulator policy" can be "enumerated in the database rule set", etc.

Section 7, generally: Same issue with "regulatory". See if there are any 
that are more accurately "database rules".

Threat 7: This doesn't strike me as a security consideration per se. 
This might make more sense incorporated into an operational requirement.

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Anthony Mancuso <[email-masked]>
Date: Wed, 23 Jan 2013 13:17:22 -0800

Thanks Pete. I went through the list quickly and they seemed like very
sensible suggestions and calls for clarification. I will go over these (and
any new ones) once we hear back (or don't hear) from the WG as you suggest.

Tony

On Wed, Jan 23, 2013 at 12:54 PM, Pete Resnick <[email-masked]>wrote:

> At long last, I got through my AD review of draft-ietf-paws-problem-stmt-*
> *usecases-rqmts. I first want to say that this draft is very much
> improved. The comments I have below are not (as far as I can tell)
> showstoppers. I have not had a chance to go through all of the commentary
> in Anthony's note from last week yet; I wanted to get this out ASAP, so if
> there are things in the note that answer some of my comments below, let me
> know.
>
> Now: Don't Panic! As I said, none of the issues are showstoppers. But the
> list is long. I am willing to take direction from the chairs on this: I'll
> wait at least until tomorrow to issue the IETF wide Last Call. If upon
> reviewing these, the WG thinks, "Gee, if Pete didn't get the point there,
> perhaps we should fix the document before issuing the Last Call", let me
> know that and I'll hold off for a bit. But if you think all of these issues
> can be handled easily along with the rest of the Last Call comments, I'll
> go ahead and issue the Last Call and you can put these into your queue
> along with any new comments received.
>
> 1.2.1: Are 2 & 3 combinable? "Connect to and optionally register with the
> database using a well-defined protocol."
>
> cases, but general protocol services that cut across use cases. Perhaps 3.1
> and 3.2 should be separate top-level sections?
>
> services." That seems a bit absolute. How about "must enable many different
> potential white space services"?
>
> "master". These services exist whether a device is acting as a master for
> other devices or whether it is acting on its own. Given that there's been
> no discussion of slave devices yet (that happens in 3.2), I found the use
> of the term "master" confusing in these sections. (I suppose you could
> expand the definition of master in 2.2 to explain that it could refer to a
> device acting on its own with no slaves, but I still think that might be
> confusing.
>
> domain" is meaningless for purposes of this sentence. If it is not, there's
> something that's not explained.
>
> database", then it is not the regulatory rules the device cares about; it
> is the information the database is configured to ask for (which will
> presumably be in accordance to some regulations, but are out of band of any
> protocol work). If the answer is, "It is pre-configured in the device",
> then the regulatory rules are again out of band. Either way, mention of
> them would be unnecessary.
>
> 2.2, it's only a slave for purposes of talking to the database. But there
> is an implication in these sections that the slave device uses the master
> for internet connectivity. I don't think that's the intent, but either way
> there's some clarification that's needed. Further confusing me about this
> point is (a) the master device is always the one in the diagrams with the
> antenna, but as far as I can tell, a master device doesn't need an antenna,
> the slaves do; and (b) most of the links marked "Air" seem to me not to
> require an air interface, but could also be wired. I could use some
> explanation.
>
> 3.2.1, item 7: Does the slave provide its location, device identifier, and
> antenna height, the same way the master does when it queries? If so
> communication over the network". That's not right is it? In this scenario,
> the allocated white space could be used for network (I read "Internet")
> communication *or anything else*, can't it?
>
> 3.2.1, item 9: Is this an important part of the scenario? Why wouldn't it
> be perfectly reasonable for communication between the master and slaves
> continue on its original connection and that the white space is only used
> for other communications the slave wishes to do?
>
> 3.2.4 and 3.2.5: Another example of the term "master" seems unnecessary in
> the example, since there are no slaves.
>
> 4.1, item 1: Is this referring to the Internet connectivity between the WS
> device and the database? If so, as above, does it necessarily need to be an
> air interface?
>
> 4.1, item 3: Again I suggest changing "operate in any country" to "operate
> in any locale" and change "country-specific" to "locale-specific". (The
> other occurrence of "country" seems correct.)
>
> requirement here, are they? It sounds like the requirement is "indication
> of success or failure".
>
> O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy required
> by the database"?
>
> that the WG is not developing protocol to do so. Is that what you meant? If
> not, this should be turned into a protocol requirement instead of an
> operational requirement.
>
> "database" seems sufficient, since you'll be getting the rule set from the
> database.
>
> O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can change
> "local regulatory policy" to "the database rule set", "determined by
> regulator policy" can be "enumerated in the database rule set", etc.
>
> Threat 7: This doesn't strike me as a security consideration per se. This
> might make more sense incorporated into an operational requirement.
>
> --
> Pete Resnick<http://www.qualcomm.**com/~presnick/<http://www.qualcomm.com/~presnick/>
> >
> ______________________________**_________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/paws<https://www.ietf.org/mailman/listinfo/paws>
>

---

From: Peter Stanforth <[email-masked]>
Date: Wed, 23 Jan 2013 16:17:47 -0500

Some observations and comments on your review. Posted inline below, I don't have any specific issues with what you say.
Peter S.

From: Pete Resnick <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 23, 2013 3:54 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10

------

2.2: For "Device ID", it says, "that identifies the manufacturer, model
number, and serial number." Does the device ID have to identify that
information? Can it simply be unique?
Regulators are asking for manufacturer and model number as they may require action, enforcement or denial by the DB on the set to manufacturer devices or a specific model of device

Broadcast use case is a master with no slave, at least in the context of a slave that communicates with or is controlled by a master.

The location of a device determines it regulatory domain. However the device may understand this or it may be told. For instance our current US implementation validates that a device is within the regulatory domain. If not we deny it service but allowed for the DB to tell the device who or what it should contact. In other words you are now in Canada so you need to talk to xxx not to and FCC DB. Taken together with the comment below this may need some thought and additional work

The FCC, as an example, has two concepts of a slave. The first is a client served by a master, think 802.11 client using a channel served by an AP. This is the model for low power devices. If the device is a high power device the slave must get it's own channel list. It can use a master to do this, using white space spectrum, if it has no other means of contacting the database.

As above a low power slave, under FCC rule, does not have to provide any of this information but a high power slave does.

High power again. A slave may not get the same channel list as the master and may not be able to use the channel the master is currently using so a negotiation will be necessary.

Same comment as above

4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply
"domain" be sufficient?
The regulatory domain is assumed to be similar to a country domain but need not be. A database could be permitted to serve  a different definition. In the FCC case they currently limit the domain to the 12mile nautical limit and, as we speak databases are only permitted to service the NE USA.

O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy
required by the database"?
Acceptable Location Accuracy is defined by the regulator and applied to the calculations of the database

O.5: Again, "regulatory body" seems unnecessary here. Substituting
"database" seems sufficient, since you'll be getting the rule set from
the database.
General observation about this and the next couple of comments. The FCC Certifies a radio and a database as a "system" Ofcom is not considering a system. Other regulators may have other thoughts. In the case of the FCC some of the function is validated/certified, what ever you want to call it for the combination not as a function of one or the other.
So while it seems logical to have an implementation within a database it is not necessarily considered as such.
O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can
change "local regulatory policy" to "the database rule set", "determined
by regulator policy" can be "enumerated in the database rule set", etc.

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

---

From: Nancy Bravin <[email-masked]>
Date: Wed, 23 Jan 2013 13:33:07 -0800

I think since we are dealing with a protocol that can be used globally, terms such as listed below, with definition, will make it easier to those countries who are not
English speaking, or the translation to words, with no definition can be confusing. It is not a deal breaker, but consideration for emerging countries that lack experience in these 
areas. IMHO

Also, I do agree that air interface is not the only method. 

Sincerely, N

On Jan 23, 2013, at 1:17 PM, Peter Stanforth wrote:

> From: Pete Resnick <[email-masked]>
> To: "[email-masked]" <[email-masked]>

---

From: <[email-masked]>
Date: Wed, 23 Jan 2013 21:55:09 +0000

My suggestion would be, if Tony has the time and willingness, then generate a new version and try to address these comments, perhaps taking the clarifications from Peter (and any input from others if available until tomorrow) into consideration.
Thanks, Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Anthony Mancuso
Sent: Wednesday, January 23, 2013 1:17 PM
To: Pete Resnick
Cc: [email-masked]
Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10

Thanks Pete. I went through the list quickly and they seemed like very sensible suggestions and calls for clarification. I will go over these (and any new ones) once we hear back (or don't hear) from the WG as you suggest.

Tony

On Wed, Jan 23, 2013 at 12:54 PM, Pete Resnick <[email-masked]<mailto:[email-masked]>> wrote:
At long last, I got through my AD review of draft-ietf-paws-problem-stmt-usecases-rqmts. I first want to say that this draft is very much improved. The comments I have below are not (as far as I can tell) showstoppers. I have not had a chance to go through all of the commentary in Anthony's note from last week yet; I wanted to get this out ASAP, so if there are things in the note that answer some of my comments below, let me know.

Now: Don't Panic! As I said, none of the issues are showstoppers. But the list is long. I am willing to take direction from the chairs on this: I'll wait at least until tomorrow to issue the IETF wide Last Call. If upon reviewing these, the WG thinks, "Gee, if Pete didn't get the point there, perhaps we should fix the document before issuing the Last Call", let me know that and I'll hold off for a bit. But if you think all of these issues can be handled easily along with the rest of the Last Call comments, I'll go ahead and issue the Last Call and you can put these into your queue along with any new comments received.

So, here are the comments. If you can have a look in the next 24 hours, that would be great.

------

Abstract: End of the first paragraph, perhaps add: "The IETF has undertaken to develop a protocol for that management database."

1.2.1: Are 2 & 3 combinable? "Connect to and optionally register with the database using a well-defined protocol."

2.2: For "Device ID", it says, "that identifies the manufacturer, model number, and serial number." Does the device ID have to identify that information? Can it simply be unique?

"Device Class" is only used once in section 5.1. No need for the definition here.

"Location Based Service" is only used once in section 3. No need for the definition here.

"Protected Entity" is only used once in section 4.1. No need for the definition here.

"Radio Access Technology" is only used once in section 5.1. No need for the definition here.

3.1 This section (and its subsections) seems oddly placed. It is not use cases, but general protocol services that cut across use cases. Perhaps 3.1 and 3.2 should be separate top-level sections?

3.1 "A complete protocol solution must enable all potential white space services." That seems a bit absolute. How about "must enable many different potential white space services"?

3.1.1 & 3.1.2: Throughout this section, there's no need to use the term "master". These services exist whether a device is acting as a master for other devices or whether it is acting on its own. Given that there's been no discussion of slave devices yet (that happens in 3.2), I found the use of the term "master" confusing in these sections. (I suppose you could expand the definition of master in 2.2 to explain that it could refer to a device acting on its own with no slaves, but I still think that might be confusing.

3.1.1, item 2: This says that the device will discover the database "in the local regulatory domain". How does the device determine the "local regulatory domain"? I suspect that the phrase "in the local regulatory domain" is meaningless for purposes of this sentence. If it is not, there's something that's not explained.

3.1.2: Similar questions regarding regulatory domains. For example, "2.  To register with the database, the master device sends the database the registration information required under regulatory rules." How does the device determine which regulatory rules it is under and therefore which information to send to the database. If the answer is, "It queries the database", then it is not the regulatory rules the device cares about; it is the information the database is configured to ask for (which will presumably be in accordance to some regulations, but are out of band of any protocol work). If the answer is, "It is pre-configured in the device", then the regulatory rules are again out of band. Either way, mention of them would be unnecessary.

3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in 2.2, it's only a slave for purposes of talking to the database. But there is an implication in these sections that the slave device uses the master for internet connectivity. I don't think that's the intent, but either way there's some clarification that's needed. Further confusing me about this point is (a) the master device is always the one in the diagrams with the antenna, but as far as I can tell, a master device doesn't need an antenna, the slaves do; and (b) most of the links marked "Air" seem to me not to require an air interface, but could also be wired. I could use some explanation.

3.2.1, item 7: Does the slave provide its location, device identifier, and antenna height, the same way the master does when it queries? If so (especially in the case of the master sub-allocating for the slaves), doesn't the master have to provide the set of locations for all of the slaves in step 5? Some further explanation might be in order.

3.2.1, item 8: It says that the white space is allocated to slaves "for communication over the network". That's not right is it? In this scenario, the allocated white space could be used for network (I read "Internet") communication *or anything else*, can't it?

3.2.1, item 9: Is this an important part of the scenario? Why wouldn't it be perfectly reasonable for communication between the master and slaves continue on its original connection and that the white space is only used for other communications the slave wishes to do?

3.2.2: This scenario was confusing to me because the master seems completely unnecessary to the example. Please explain.

3.2.4 and 3.2.5: Another example of the term "master" seems unnecessary in the example, since there are no slaves.

4: "Master" seems unnecessary to the example. Also, I suggest in the second-to-last paragraph, you say "The databases are locale specific" instead of "country specific", and delete the word "competing" from the last sentence of that paragraph.

4.1, item 1: Is this referring to the Internet connectivity between the WS device and the database? If so, as above, does it necessarily need to be an air interface?

4.1, item 3: Again I suggest changing "operate in any country" to "operate in any locale" and change "country-specific" to "locale-specific". (The other occurrence of "country" seems correct.)

4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply "domain" be sufficient?

5.1 and 5.2: I don't understand the distinction between "Normative" and "Non-normative" requirements in this context. Isn't it sufficient that you've separately labeled "Data Model Requirements", "Protocol Requirements", and "Operational Requirements"?

P.1: "The master device may validate the database against a list of approved databases maintained by a regulatory body." I don't understand that as a protocol requirement. What is being required?

P.5 and P.6: The requirement here is for *message-level* integrity and encryption? That's OK, but I want to make sure that's what you mean.

P.8 and P.14: I don't think "result codes" and "response codes" are the requirement here, are they? It sounds like the requirement is "indication of success or failure".

P.15: I'm not clear on what this requirement means in practical terms. Some more explanation seems in order.

O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy required by the database"?

O.3: This seems to indicate that database discovery will be out of band, that the WG is not developing protocol to do so. Is that what you meant? If not, this should be turned into a protocol requirement instead of an operational requirement.

O.4: This requirement seems a bit overly obvious and silly to state as a requirement. Why is it necessary to say that you need a connection?

O.5: Again, "regulatory body" seems unnecessary here. Substituting "database" seems sufficient, since you'll be getting the rule set from the database.

O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can change "local regulatory policy" to "the database rule set", "determined by regulator policy" can be "enumerated in the database rule set", etc.

Section 7, generally: Same issue with "regulatory". See if there are any that are more accurately "database rules".

Threat 7: This doesn't strike me as a security consideration per se. This might make more sense incorporated into an operational requirement.

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478<tel:%2B1%20%28858%29651-4478>

---

From: Anthony Mancuso <[email-masked]>
Date: Wed, 23 Jan 2013 14:04:46 -0800

Good suggestion Gabor. I will wait another day or so and then start on
generating a new version in response to the comments and clarifications.

On Wed, Jan 23, 2013 at 1:55 PM, <[email-masked]> wrote:

>  My suggestion would be, if Tony has the time and willingness, then
> generate a new version and try to address these comments, perhaps taking
> the clarifications from Peter (and any input from others if available until
> tomorrow) into consideration. ****
>
> Thanks, Gabor****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *ext Anthony Mancuso
> *Sent:* Wednesday, January 23, 2013 1:17 PM
> *To:* Pete Resnick
> *Cc:* [email-masked]
> *Subject:* Re: [paws] AD review of
> draft-ietf-paws-problem-stmt-usecases-rqmts-10****
>
> ** **
>
> ****
> ** **
> Tony****
> ** **
> On Wed, Jan 23, 2013 at 12:54 PM, Pete Resnick <[email-masked]>
> wrote:****
>
> draft-ietf-paws-problem-stmt-usecases-rqmts. I first want to say that this
> draft is very much improved. The comments I have below are not (as far as I
> can tell) showstoppers. I have not had a chance to go through all of the
> commentary in Anthony's note from last week yet; I wanted to get this out
> ASAP, so if there are things in the note that answer some of my comments
> below, let me know.
>
> https://www.ietf.org/mailman/listinfo/paws****
>
> ** **
>

---

From: Pete Resnick <[email-masked]>
Date: Wed, 23 Jan 2013 16:10:34 -0600

One hitch: If you make the call by EOB tomorrow, I can get the Last Call 
sent out, which means (assuming the LC goes well) I can get it on the 
IESG telechat Feb 7. If we have to wait two additional weeks until the 
Feb 14 telechat, it's not a huge deal, but we have to say "go" or "no 
go" to the Last Call by EOB tomorrow for me to sneak it on to the 
earlier telechat.

pr

On 1/23/13 4:04 PM, Anthony Mancuso wrote:
> On Wed, Jan 23, 2013 at 1:55 PM, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     generate a new version and try to address these comments, perhaps
>     taking the clarifications from Peter (and any input from others if
>     available until tomorrow) into consideration.
>
>     Thanks, Gabor
>
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 23 Jan 2013 17:19:14 -0500

I think if Tony can spin a rev before EOB tomorrow, we should do that, but I'm thinking that the current rev is good enough, and I'd prefer to get it into the Feb 7 telechat.

I don't feel very strongly about that, but…

Brian

On Jan 23, 2013, at 5:10 PM, Pete Resnick <[email-masked]<mailto:[email-masked]>> wrote:

One hitch: If you make the call by EOB tomorrow, I can get the Last Call sent out, which means (assuming the LC goes well) I can get it on the IESG telechat Feb 7. If we have to wait two additional weeks until the Feb 14 telechat, it's not a huge deal, but we have to say "go" or "no go" to the Last Call by EOB tomorrow for me to sneak it on to the earlier telechat.

pr

On 1/23/13 4:04 PM, Anthony Mancuso wrote:
Good suggestion Gabor. I will wait another day or so and then start on generating a new version in response to the comments and clarifications.

On Wed, Jan 23, 2013 at 1:55 PM, <[email-masked]<mailto:[email-masked]>> wrote:
My suggestion would be, if Tony has the time and willingness, then generate a new version and try to address these comments, perhaps taking the clarifications from Peter (and any input from others if available until tomorrow) into consideration.
Thanks, Gabor

--
Pete Resnick <http://www.qualcomm.com/~presnick/><http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Anthony Mancuso <[email-masked]>
Date: Wed, 23 Jan 2013 14:54:42 -0800

I',m not sure I can turn around the doc by tomorrow since there are some
technical points I need to collaborate on.

On Wed, Jan 23, 2013 at 2:19 PM, Rosen, Brian <[email-masked]>wrote:

> I think if Tony can spin a rev before EOB tomorrow, we should do that, but
> I'm thinking that the current rev is good enough, and I'd prefer to get it
> into the Feb 7 telechat.
>
> On Jan 23, 2013, at 5:10 PM, Pete Resnick <[email-masked]>
> wrote:
>
> sent out, which means (assuming the LC goes well) I can get it on the IESG
> telechat Feb 7. If we have to wait two additional weeks until the Feb 14
> telechat, it's not a huge deal, but we have to say "go" or "no go" to the
> Last Call by EOB tomorrow for me to sneak it on to the earlier telechat.
>
> pr
>
>> tomorrow) into consideration.
>>
>> Thanks, Gabor
>>
>>
> --
> Pete Resnick <http://www.qualcomm.com/~presnick/> <http://www.qualcomm.com/~presnick/>

---

From: Pete Resnick <[email-masked]>
Date: Wed, 23 Jan 2013 16:59:08 -0600

Like I said, I'll await word from Brian and Gabor tomorrow for "go" or 
"no go" with the Last Call, even if there is no new draft ready to go. 
We can Last Call -10 if nobody thinks there's a strong reason to wait. I 
am fine with either path.

pr

On 1/23/13 4:54 PM, Anthony Mancuso wrote:
> I',m not sure I can turn around the doc by tomorrow since there are 
> some technical points I need to collaborate on.
>
>
> On Wed, Jan 23, 2013 at 2:19 PM, Rosen, Brian <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I think if Tony can spin a rev before EOB tomorrow, we should do
>     that, but I'm thinking that the current rev is good enough, and
>     I'd prefer to get it into the Feb 7 telechat.
>
>     I don't feel very strongly about that, but...
>
>     Brian
>
>     On Jan 23, 2013, at 5:10 PM, Pete Resnick
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     One hitch: If you make the call by EOB tomorrow, I can get the
>>     Last Call sent out, which means (assuming the LC goes well) I can
>>     get it on the IESG telechat Feb 7. If we have to wait two
>>     additional weeks until the Feb 14 telechat, it's not a huge deal,
>>     but we have to say "go" or "no go" to the Last Call by EOB
>>     tomorrow for me to sneak it on to the earlier telechat.
>>
>>     pr
>>
>>>     Good suggestion Gabor. I will wait another day or so and then
>>>     start on generating a new version in response to the comments
>>>     and clarifications.
>>>
>>>
>>>         My suggestion would be, if Tony has the time and
>>>         willingness, then generate a new version and try to address
>>>         these comments, perhaps taking the clarifications from Peter
>>>         (and any input from others if available until tomorrow) into
>>>         consideration.
>>>
>>>         Thanks, Gabor
>>>
>>>
>>
>>     -- 
>>     Pete Resnick<http://www.qualcomm.com/~presnick/>  <http://www.qualcomm.com/%7Epresnick/>
>>     Qualcomm Technologies, Inc. -+1 (858)651-4478  <tel:%2B1%20%28858%29651-4478>
>>     [email-masked] <mailto:[email-masked]>

---

From: Pete Resnick <[email-masked]>
Date: Wed, 23 Jan 2013 17:18:07 -0600

Replying to both Nancy and Peter. Trimming as I go:

On 1/23/13 3:33 PM, Nancy Bravin wrote:

> I think since we are dealing with a protocol that can be used 
> globally, terms such as listed below, with definition, will make it 
> easier to those countries who are not English speaking, or the 
> translation to words, with no definition can be confusing. It is not a 
> deal breaker, but consideration for emerging countries that lack 
> experience in these areas. IMHO

Sorry, I think I wasn't clear enough. Other than "Protected Contour" 
(which is not used anywhere), I was not suggesting having *no* 
definition of the terms listed. I was just saying that if they only 
occur once in the document, define them inline where they are used 
instead of in the definitions section. But that's strictly an editorial 
comment. Entirely up to you all whether you want to make a change.

>> Regulators are asking for manufacturer and model number as they may 
>> require action, enforcement or denial by the DB on the set to 
>> manufacturer devices or a specific model of device

I guess the question is: Are there any potential implementers of this 
protocol (or potential regulatory bodies) that *don't* care about 
manufacturer or model or etc.?

>> Broadcast use case is a master with no slave, at least in the context 
>> of a slave that communicates with or is controlled by a master.

So are you saying we do or do not need the term "master" in these sections?

>> The location of a device determines it regulatory domain. However the 
>> device may understand this or it may be told.

Right. That seems to indicate that the device that this section should 
say, "for its current location" and not "in the local regulatory 
domain". The device needs to know its location, but not its regulatory 
domain.

>> For instance our current US implementation validates that a device is 
>> within the regulatory domain. If not we deny it service but allowed 
>> for the DB to tell the device who or what it should contact. In other 
>> words you are now in Canada so you need to talk to xxx not to and FCC 
>> DB. Taken together with the comment below this may need some thought 
>> and additional work

I think we're on the same page.

>> The FCC, as an example, has two concepts of a slave. The first is a 
>> client served by a master, think 802.11 client using a channel served 
>> by an AP. This is the model for low power devices.

OK, but does the low power device actually ever request white space 
spectrum? If not, then it is not involved in this protocol, right?

>> If the device is a high power device the slave must get it's own 
>> channel list. It can use a master to do this, using white space 
>> spectrum, if it has no other means of contacting the database.

This I understood until you said "using white space spectrum". It can't 
use white space spectrum to talk to the master until it is allocated 
spectrum by the database, can it? It talks to the master *not* using 
white space spectrum, gets it's answer through the master about which 
spectrum to use, and then stops talking to the master, correct?

>> As above a low power slave, under FCC rule, does not have to provide 
>> any of this information but a high power slave does.

Does a low power slave talk to the database at all?

>> High power again. A slave may not get the same channel list as the 
>> master and may not be able to use the channel the master is currently 
>> using so a negotiation will be necessary.

I'm not sure whether you agree or disagree with my point here. I don't 
understand your reply.

>> The regulatory domain is assumed to be similar to a country domain 
>> but need not be. A database could be permitted to serve  a different 
>> definition. In the FCC case they currently limit the domain to the 
>> 12mile nautical limit and, as we speak databases are only permitted 
>> to service the NE USA.

I don't think you answered my question.

>> to the calculations of the database

So the database will tell the device what level of accuracy is required?

>> So while it seems logical to have an implementation within a database 
>> it is not necessarily considered as such.

Again, I'm not understand your reply. Can you expand on what you mean here?

pr

---

From: <[email-masked]>
Date: Thu, 24 Jan 2013 23:19:26 +0000

Will wait for Tony to generate a new version by addressing the received comments, before issuing the Last Call.

-          Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Pete Resnick
Sent: Wednesday, January 23, 2013 2:59 PM
To: Anthony Mancuso
Cc: [email-masked]
Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10

Like I said, I'll await word from Brian and Gabor tomorrow for "go" or "no go" with the Last Call, even if there is no new draft ready to go. We can Last Call -10 if nobody thinks there's a strong reason to wait. I am fine with either path.

pr

On 1/23/13 4:54 PM, Anthony Mancuso wrote:
I',m not sure I can turn around the doc by tomorrow since there are some technical points I need to collaborate on.

On Wed, Jan 23, 2013 at 2:19 PM, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:
I think if Tony can spin a rev before EOB tomorrow, we should do that, but I'm thinking that the current rev is good enough, and I'd prefer to get it into the Feb 7 telechat.

Brian

pr

--

Pete Resnick <http://www.qualcomm.com/~presnick/><http://www.qualcomm.com/%7Epresnick/>

paws mailing list

--

---

From: Anthony Mancuso <[email-masked]>
Date: Fri, 25 Jan 2013 09:51:41 -0800

I just posted version 11 of the PAWS Use Case & Requirements draft to IETF.
In this draft, I responded to several of the comments posted to the list; I
left a few TODOs, and am awaiting further comments for the next draft.

My notes are in preparing this version are set out below.

Tony Mancuso

***************
Tony Mancuso Notes - PAWS Use Case & Requirements Notes v. 11 (I
consolidated Pete Resnick's initial comments with other comments received
on selected points together with my responses)

Abstract: End of the first paragraph, perhaps add: "The IETF has undertaken
to develop a protocol for that management database."
___
Mancuso: Done
_____

_____
Mancuso: Done:
_____

2.2: For "Device ID", it says, "that identifies the manufacturer, model
number, and serial number." Does the device ID have to identify that
information? Can it simply be unique?
____
Stanforth: Regulators are asking for manufacturer and model number as they
may require action, enforcement or denial by the DB on the set to
manufacturer devices or a specific model of device
_____
Resnick: I guess the question is: Are there any potential implementers of
this protocol (or potential regulatory bodies) that *don't* care about
manufacturer or model or etc.?
_____
Mancuso: Waiting for further comment.
_____
"Device Class" is only used once in section 5.1. No need for the definition
here.

"Radio Access Technology" is only used once in section 5.1. No need for the
definition here.
_____
Nancy Bravin: I think since we are dealing with a protocol that can be used
globally, terms such as listed below, with definition, will make it easier
to those countries who are not English speaking, or the translation to
words, with no definition can be confusing. It is not a deal breaker, but
consideration for emerging countries that lack experience in these areas.
_____
Resnick: Sorry, I think I wasn't clear enough. Other than "Protected
Contour" (which is not used anywhere), I was not suggesting having *no*
definition of the terms listed. I was just saying that if they only occur
once in the document, define them inline where they are used instead of in
the definitions section. But that's strictly an editorial comment. Entirely
up to you all whether you want to make a change.
_____
Mancuso: Deleted Protected Contour, and moved the definition of single-use
terms into the text.
_____

3.1 This section (and its subsections) seems oddly placed. It is not use
cases, but general protocol services that cut across use cases. Perhaps 3.1
and 3.2 should be separate top-level sections?
---
Mancuso: Done. Moved Protocol Services to new top-level head (Section 3);
Use Cases now in new Section 4.
_____

____
Mancuso: Done.
_____

3.1.1 & 3.1.2: Throughout this section, there's no need to use the term
"master". These services exist whether a device is acting as a master for
other devices or whether it is acting on its own. Given that there's been
no discussion of slave devices yet (that happens in 3.2), I found the use
of the term "master" confusing in these sections. (I suppose you could
expand the definition of master in 2.2 to explain that it could refer to a
device acting on its own with no slaves, but I still think that might be
confusing.
_____
Stanforth: Broadcast use case is a master with no slave, at least in the
context of a slave that communicates with or is controlled by a master.
_____
Resnick: So are you saying we do or do not need the term "master" in these
sections?
_____
Mancuso: I clarified the definition of master device: "A device that
queries a database, on its own behalf and/or on behalf of a slave device,
to obtain available spectrum information.". I think this definition plus
the definition of a slave device ("A device that queries the database
through a Master Device.") makes the use of the term in the section
appropriate -- namely, a master device is one that contacts a database to
obtain spectrum (for itself or other devices). Slave devices under these
definitions, do not contact the db directly, omitting them from the
discussion at this point makes sense. Another way of saying it: we use the
term master only as a way of describing a device used to query the db
directly for spectrum availability. Denoting a device as master does not
necessarily imply the use of slaves (devices that are not used to query the
db directly) in a particular use case.
_______________

3.1.1, item 2: This says that the device will discover the database "in the
local regulatory domain". How does the device determine the "local
regulatory domain"? I suspect that the phrase "in the local regulatory
domain" is meaningless for purposes of this sentence. If it is not, there's
something that's not explained.
_____
Stanforth: The location of a device determines it regulatory domain.
However the device may understand this or it may be told.
_____
Resnick: Right. That seems to indicate that the device that this section
should say, "for its current location" and not "in the local regulatory
domain". The device needs to know its location, but not its regulatory
domain.
_____
Stanforth: For instance our current US implementation validates that a
device is within the regulatory domain. If not we deny it service but
allowed for the DB to tell the device who or what it should contact. In
other words you are now in Canada so you need to talk to xxx not to and FCC
DB. Taken together with the comment below this may need some thought and
additional work.
_____
Resnick: I think we're on the same page.
_____
Mancuso: The intent of the existing wording is simply that the master sends
out a request and waits for a response, not to imply that it the device
query is constrained or qualified by the device's understanding of its
regulatory domain. I deleted the extra language to read as follows: "The
master device constructs and sends a service request over the Internet."
_______
3.1.2: Similar questions regarding regulatory domains. For example, "2.  To
register with the database, the master device sends the database the
registration information required under regulatory rules." How does the
device determine which regulatory rules it is under and therefore which
information to send to the database. If the answer is, "It queries the
database", then it is not the regulatory rules the device cares about; it
is the information the database is configured to ask for (which will
presumably be in accordance to some regulations, but are out of band of any
protocol work). If the answer is, "It is pre-configured in the device",
then the regulatory rules are again out of band. Either way, mention of
them would be unnecessary.
___
Mancuso: Agreed. Again, I think this was simply a matter of misphrasing.
Deleted the extra language to read: "To register with the database, the
master device sends registration information to the database."
_____

3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in 2.2,
it's only a slave for purposes of talking to the database. But there is an
implication in these sections that the slave device uses the master for
internet connectivity. I don't think that's the intent, but either way
there's some clarification that's needed. Further confusing me about this
point is (a) the master device is always the one in the diagrams with the
antenna, but as far as I can tell, a master device doesn't need an antenna,
the slaves do; and (b) most of the links marked "Air" seem to me not to
require an air interface, but could also be wired. I could use some
explanation.
_____
Stanforth
The FCC, as an example, has two concepts of a slave. The first is a client
served by a master, think 802.11 client using a channel served by an AP.
This is the model for low power devices.
_____
Resnick: OK, but does the low power device actually ever request white
space spectrum? If not, then it is not involved in this protocol, right?
___
Stanforth: If the device is a high power device the slave must get it's own
channel list. It can use a master to do this, using white space spectrum,
if it has no other means of contacting the database.
____
Resnick: This I understood until you said "using white space spectrum". It
can't use white space spectrum to talk to the master until it is allocated
spectrum by the database, can it? It talks to the master *not* using white
space spectrum, gets it's answer through the master about which spectrum to
use, and then stops talking to the master, correct?
____
Mancuso: Waiting for any further input.
_____

3.2.1, item 7: Does the slave provide its location, device identifier, and
antenna height, the same way the master does when it queries? If so
(especially in the case of the master sub-allocating for the slaves),
doesn't the master have to provide the set of locations for all of the
slaves in step 5? Some further explanation might be in order.
_____
Stanforth: As above a low power slave, under FCC rule, does not have to
provide any of this information but a high power slave does.
_____
Resnick: Does a low power slave talk to the database at all?
_____
Mancuso: Waiting for any further input.
______
3.2.1, item 8: It says that the white space is allocated to slaves "for
communication over the network". That's not right is it? In this scenario,
the allocated white space could be used for network (I read "Internet")
communication *or anything else*, can't it?
_____
Stanforth: High power again. A slave may not get the same channel list as
the master and may not be able to use the channel the master is currently
using so a negotiation will be necessary.
_____
Resnick: I'm not sure whether you agree or disagree with my point here. I
don't understand your reply.
_____
Mancuso: Waiting for any further input.
_____

_____
Stanforth: same as Iten 8, above.
____
Mancuso: TODO.
_____

3.2.2: This scenario was confusing to me because the master seems
completely unnecessary to the example. Please explain.
_____
Mancuso: TODO. The master is optionally used by the slave to query the db
for spectrum. And again, master only connotes ability to query the db
directly by the device. I do think we need to eliminate the implication
that the slave then connects to the Internet through the master (it uses
white space spectrum, right)?
_____

3.2.4 and 3.2.5: Another example of the term "master" seems unnecessary in
the example, since there are no slaves.
____
Mancuso: Again, master only connotes ability to query the db directly by
the device.
____
4: "Master" seems unnecessary to the example. Also, I suggest in the
second-to-last paragraph, you say "The databases are locale specific"
instead of "country specific", and delete the word "competing" from the
last sentence of that paragraph.
________
Mancuso: Same response re masters as above. Made the suggested wording
changes re "locale" and "competing."
_____

___
Mancuso: TODO
_____

4.1, item 3: Again I suggest changing "operate in any country" to "operate
in any locale" and change "country-specific" to "locale-specific". (The
other occurrence of "country" seems correct.)
____
Mancuso: Made suggested wording changes.
_____

4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply
"domain" be sufficient?
_____
Stanforth: The regulatory domain is assumed to be similar to a country
domain but need not be. A database could be permitted to serve  a different
definition. In the FCC case they currently limit the domain to the 12mile
nautical limit and, as we speak databases are only permitted to service the
NE USA.
_____
Resnick: I don't think you answered my question.
_____
Mancuso: I changed to "domain specific". Not that the db may not be
locale-based (a South American country may opt for FCC domain rules).
_____

5.1 and 5.2: I don't understand the distinction between "Normative" and
"Non-normative" requirements in this context. Isn't it sufficient that
you've separately labeled "Data Model Requirements", "Protocol
Requirements", and "Operational Requirements"?
_____
Mancuso: Agreed. Changed the heads and organization.
_____
Mancuso: Remaining items TODO.
_____
P.1: "The master device may validate the database against a list of
approved databases maintained by a regulatory body." I don't understand
that as a protocol requirement. What is being required?

P.15: I'm not clear on what this requirement means in practical terms. Some
more explanation seems in order.

O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy required
by the database"?
_____
Stanforth: Acceptable Location Accuracy is defined by the regulator and
applied to the calculations of the database
_____
Resnick: So the database will tell the device what level of accuracy is
required?
_____

O.5: Again, "regulatory body" seems unnecessary here. Substituting
"database" seems sufficient, since you'll be getting the rule set from the
database.
_____
Stanforth: General observation about this and the next couple of comments.
The FCC Certifies a radio and a database as a "system" Ofcom is not
considering a system. Other regulators may have other thoughts. In the case
of the FCC some of the function is validated/certified, what ever you want
to call it for the combination not as a function of one or the other.
So while it seems logical to have an implementation within a database it is
not necessarily considered as such.
_____
Resnick: Again, I'm not understand your reply. Can you expand on what you
mean here?
_____

On Thu, Jan 24, 2013 at 3:19 PM, <[email-masked]> wrote:

>  Will wait for Tony to generate a new version by addressing the received
> comments, before issuing the Last Call.****
>
> ** **
>
> **-          **Gabor****
>
> ** **
>
> Of *ext Pete Resnick
> *Sent:* Wednesday, January 23, 2013 2:59 PM
> *To:* Anthony Mancuso
>
> *Cc:* [email-masked]
> Like I said, I'll await word from Brian and Gabor tomorrow for "go" or "no
> go" with the Last Call, even if there is no new draft ready to go. We can
> Last Call -10 if nobody thinks there's a strong reason to wait. I am fine
> with either path.
>
>
> pr
>
> On 1/23/13 4:54 PM, Anthony Mancuso wrote: ****
>
> technical points I need to collaborate on.****
>
> ** **
>
> On Wed, Jan 23, 2013 at 2:19 PM, Rosen, Brian <[email-masked]>
> wrote:****
>
> into the Feb 7 telechat.   ****
>
> ** **
>
> I don't feel very strongly about that, but…****
>
> ** **
>
> Brian****
>
> ** **
>
>   One hitch: If you make the call by EOB tomorrow, I can get the Last
> Call sent out, which means (assuming the LC goes well) I can get it on the
> IESG telechat Feb 7. If we have to wait two additional weeks until the Feb
> 14 telechat, it's not a huge deal, but we have to say "go" or "no go" to
> the Last Call by EOB tomorrow for me to sneak it on to the earlier telechat.
>
> pr
>
> On 1/23/13 4:04 PM, Anthony Mancuso wrote: ****
>
> generating a new version in response to the comments and clarifications.**
> **
>
> ** **
>
> On Wed, Jan 23, 2013 at 1:55 PM, <[email-masked]> wrote:****
>
> -- ****
> Pete Resnick <http://www.qualcomm.com/~presnick/> <http://www.qualcomm.com/%7Epresnick/>****
>
> Qualcomm Technologies, Inc. - +1 (858)651-4478****
>
>   _______________________________________________ ****
>
>
> paws mailing list
> [email-masked]
> -- ****
> Pete Resnick <http://www.qualcomm.com/~presnick/> <http://www.qualcomm.com/~presnick/>****
>
> Qualcomm Technologies, Inc. - +1 (858)651-4478****
>
>

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Fri, 25 Jan 2013 11:44:28 -0800

On 1/25/2013 9:51 AM, Anthony Mancuso wrote:
> 3.1 "A complete protocol solution must enable all potential white 
> space services." That seems a bit absolute. How about "must enable 
> many different potential white space services"?
I'd strike the entire sentence. There is no such thing as a "complete 
protocol".   If you must have it, change it to "this protocol" and it 
isn't wrong (but still not adding information).

---

From: Anthony Mancuso <[email-masked]>
Date: Tue, 29 Jan 2013 15:15:47 -0800

To PAWS list:

Here are the collected comments on version 10 (the last posted version) of
the PAWS Use Case & Requirements draft and my responses (what I did and
didn't do) for version 12, which I just posted to IETF.

Thanks for all the feedback!

Tony Mancuso

Abstract

End of the first paragraph, perhaps add: "The IETF has undertaken to
develop a protocol for that management database."
___
Mancuso: Done
_____

Introduction

Also added reference to the PAWS protocol to 1.1.

Conventions and Terminology

Mancuso: Simplified to:  "An identifier for each master device."
_________

Protocol Services (separated out Protocol Services from Use Cases per
comment below. (I renumbered the comments below to correspond to the new
organization).

3. This section (and its subsections) seems oddly placed. It is not use

3. "A complete protocol solution must enable all potential white space
services." That seems a bit absolute. How about "must enable many different
potential white space services"?
____

Benjamin Rolfe: I'd strike the entire sentence. There is no such thing as a
"complete protocol".   If you must have it, change it to "this protocol"
and it isn't wrong (but still not adding information).

Mancuso: Rephrased to: "A protocol solution must enable many different
potential white space services. ".
_____

3.1 & 3.2: Throughout this section, there's no need to use the term
"master". These services exist whether a device is acting as a master for
other devices or whether it is acting on its own. Given that there's been
no discussion of slave devices yet (that happens in 3.2), I found the use
of the term "master" confusing in these sections. (I suppose you could
expand the definition of master in 2.2 to explain that it could refer to a
device acting on its own with no slaves, but I still think that might be
confusing.
_____
Stanforth: Broadcast use case is a master with no slave, at least in the
context of a slave that communicates with or is controlled by a master.
_____
Resnick: So are you saying we do or do not need the term "master" in these
sections?
_____
Mancuso: I clarified the definition of master device: "A device that
queries a database, on its own behalf and/or on behalf of a slave device,
to obtain available spectrum information.". I think this definition plus
the definition of a slave device ("A device that queries the database
through a Master Device.") makes the use of the term in this and latter
sections and illustrations appropriate -- namely, a master device is one
that contacts a database to obtain spectrum (for itself or other devices).
Slave devices under these definitions, do not contact the db directly,
omitting them from the discussion and refering in the text or illustrations
solely to a master device makes sense, and is not dependent on also
referencing a slave device. Another way of saying it: we use the term
master only as a way of describing a device used to query the db directly
for spectrum availability. Denoting a device as master does not necessarily
imply the use of slaves (devices that are not used to query the db
directly) in a particular use case or illustration.
_______________

3.1, item 2: This says that the device will discover the database "in the
local regulatory domain". How does the device determine the "local
regulatory domain"? I suspect that the phrase "in the local regulatory
domain" is meaningless for purposes of this sentence. If it is not, there's
something that's not explained.
_____
Stanforth: The location of a device determines it regulatory domain.
However the device may understand this or it may be told.
_____
Resnick: Right. That seems to indicate that the device that this section
should say, "for its current location" and not "in the local regulatory
domain". The device needs to know its location, but not its regulatory
domain.
_____
Stanforth: For instance our current US implementation validates that a
device is within the regulatory domain. If not we deny it service but
allowed for the DB to tell the device who or what it should contact. In
other words you are now in Canada so you need to talk to xxx not to and FCC
DB. Taken together with the comment below this may need some thought and
additional work.
_____
Resnick: I think we're on the same page.
_____
Mancuso: Rewrote to clarify the difference between the discovery phase
(locating a trusted database) and the initial contact with the trusted
database. Also noted the different ways a device can locate the database
URI (through discovery or pre-configured URIs).
_______
3.2: Similar questions regarding regulatory domains. For example, "2.  To
register with the database, the master device sends the database the
registration information required under regulatory rules." How does the
device determine which regulatory rules it is under and therefore which
information to send to the database. If the answer is, "It queries the
database", then it is not the regulatory rules the device cares about; it
is the information the database is configured to ask for (which will
presumably be in accordance to some regulations, but are out of band of any
protocol work). If the answer is, "It is pre-configured in the device",
then the regulatory rules are again out of band. Either way, mention of
them would be unnecessary.
___
Mancuso: Agreed. I think this was simply a matter of misphrasing. Deleted
the extra language to read: "To register with the database, the master
device sends registration information to the database."
_____

Use Cases

4.1, 4.2, and 4.3, in general: When "slave device" is defined in 2.2, it's
only a slave for purposes of talking to the database. But there is an
implication in these sections that the slave device uses the master for
internet connectivity. I don't think that's the intent, but either way
there's some clarification that's needed. Further confusing me about this
point is (a) the master device is always the one in the diagrams with the
antenna, but as far as I can tell, a master device doesn't need an antenna,
the slaves do; and (b) most of the links marked "Air" seem to me not to
require an air interface, but could also be wired. I could use some
explanation.
_____
Stanforth
The FCC, as an example, has two concepts of a slave. The first is a client
served by a master, think 802.11 client using a channel served by an AP.
This is the model for low power devices.
_____
Resnick: OK, but does the low power device actually ever request white
space spectrum? If not, then it is not involved in this protocol, right?
___
Stanforth: If the device is a high power device the slave must get it's own
channel list. It can use a master to do this, using white space spectrum,
if it has no other means of contacting the database.
____
Resnick: This I understood until you said "using white space spectrum". It
can't use white space spectrum to talk to the master until it is allocated
spectrum by the database, can it? It talks to the master *not* using white
space spectrum, gets it's answer through the master about which spectrum to
use, and then stops talking to the master, correct?
____
Mancuso: Masters are defined as the device that can contact the db on its
own (knows its geolocation), and the use cases I think are consistent with
this definition. There is no constraint on how the slaves or masters
communicate (air or wire) but the illustrations attempt to show common
connections for the examples (for hotspots, WANS, etc., slave devices will
connect over air to master). Also, slaves can use white space spectrum as
appropriate to the local white space network being established -- to
connect to the Internet through the master (or some other AP), for local
communications only, or some other use of the spectrum. I deleted the extra
master antenna shown in use case 5 (local tv broadcast).

4.1, item 7: Does the slave provide its location, device identifier, and
antenna height, the same way the master does when it queries? If so
(especially in the case of the master sub-allocating for the slaves),
doesn't the master have to provide the set of locations for all of the
slaves in step 5? Some further explanation might be in order.
_____
Stanforth: As above a low power slave, under FCC rule, does not have to
provide any of this information but a high power slave does.
_____
Resnick: Does a low power slave talk to the database at all?
_____
Mancuso: I moved related slave requests into the corresponding sections for
the master.
______
4.1, item 8: It says that the white space is allocated to slaves "for
communication over the network". That's not right is it? In this scenario,
the allocated white space could be used for network (I read "Internet")
communication *or anything else*, can't it?
_____
Stanforth: High power again. A slave may not get the same channel list as
the master and may not be able to use the channel the master is currently
using so a negotiation will be necessary.
_____
Resnick: I'm not sure whether you agree or disagree with my point here. I
don't understand your reply.
_____
Mancuso: The network refers to the local master-slave network, not to
connectivity to the Internet. I deleted "for communication over the
network" for clarity.
_____

3.2.1, item 9: Is this an important part of the scenario? Why wouldn't it
be perfectly reasonable for communication between the master and slaves
continue on its original connection and that the white space is only used
for other communications the slave wishes to do?
_____
Stanforth: same as Iten 8, above.
____
Mancuso: Changed to "may occur". Technically, the "network" we are talking
about here is the white space network, which only uses white space (after
initial bootstrapping communications between slaves and masters). But I
agree that we should recognize (implicitly) the ability of devices to use
other spectrum/technologies for ongoing communications.
_____

4.2: This scenario was confusing to me because the master seems completely
unnecessary to the example. Please explain.
_____
Mancuso: As noted, the master is optionally used by the slave to query the
db for spectrum. And again, master only connotes the device's ability to
query the db directly.
_____

4.4 and 4.5: Another example of the term "master" seems unnecessary in the
example, since there are no slaves.
____
Mancuso: Again, master only connotes ability to query the db directly by
the device.
____

Problem Statement

5: "Master" seems unnecessary to the example. Also, I suggest in the

5.1, item 1: Is this referring to the Internet connectivity between the WS
device and the database? If so, as above, does it necessarily need to be an
air interface?
___
Mancuso: This wasn't meant to imply air the exclusive interface -- Made
this clearer by using "any" air interface used by devices; further limited
reference to messages betweein devices and db as messages from master
device to db (since, by definition, slave devices don't communicate
directly to db).
_____

5.1, item 3: Again I suggest changing "operate in any country" to "operate
in any locale" and change "country-specific" to "locale-specific". (The
other occurrence of "country" seems correct.)
____
Mancuso: Made suggested wording changes.
_____

5.2: Instead of "regulatory-domain", wouldn't either "locale" or simply
"domain" be sufficient?
_____

Requirements:
_____
P.1: "The master device may validate the database against a list of
approved databases maintained by a regulatory body." I don't understand
that as a protocol requirement. What is being required?
___
Mancuso: (Moved info up from Operation requirements per later comment).
Rephrased to clarify that the master device MUST identify a db, and MAY
discover or be pre-configured with db URIs, and MAY validate db URIs
against a list of approved databases maintained by a regulatory body."

P.5 and P.6: The requirement here is for *message-level* integrity and
encryption? That's OK, but I want to make sure that's what you mean.
___
Rex Buddenberg: encryption gets you confidentiality (which may or may not
be a
requirement).  It does not get you authenticity.

integrity gets you bit-perfection.  Which is a requirement.  But
integrity does not get you authenticity ... which is a requirement. I
can't think of a situation where you don't need both.  (In public key, a
digital signature provides both authenticity and integrity, assuming you
have a PKI you can rely on.
____
Mancuso: Yes, that is the intent, and yes, we want all three. DB
authenticity is addressed in p4.
___
P.8 and P.14: I don't think "result codes" and "response codes" are the
requirement here, are they? It sounds like the requirement is "indication
of success or failure".
_____
Mancuso: Rephrased to state the requirement in terms of the success or
failure of the requests.
_____

P.15: I'm not clear on what this requirement means in practical terms. Some
more explanation seems in order.
___
Mancuso: Rephrased for clarity to: "The protocol MUST support the
capability for the database to inform master devices of changes to spectrum
availability information in a timely manner."

P.16: Shouldn't this be combined with P.9?
___
Mancuso: Deleted P.16; this was already included under D.9.
_____

O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy required
by the database"?
_____
Stanforth: Acceptable Location Accuracy is defined by the regulator and
applied to the calculations of the database
_____
Resnick: So the database will tell the device what level of accuracy is
required?
_____
Mancuso: Clarified as follows: "Locations MUST be determined to the
accuracy required by the applicable regualtory domain." These are
operational requirements, and not part of the protocol. Accuracy is
verified by certification of devices by regulators.
____

__

Mancuso: The master locating the DB is a requirement, so I moved this to
P.1. Renumbered the remaining requirements (and comments below).
____

O.3: This requirement seems a bit overly obvious and silly to state as a
requirement. Why is it necessary to say that you need a connection?
____

Mancuso: Deleted the first sentence.

O.4: Again, "regulatory body" seems unnecessary here. Substituting
"database" seems sufficient, since you'll be getting the rule set from the
database.
_____
Stanforth: General observation about this and the next couple of comments.
The FCC Certifies a radio and a database as a "system" Ofcom is not
considering a system. Other regulators may have other thoughts. In the case
of the FCC some of the function is validated/certified, what ever you want
to call it for the combination not as a function of one or the other.
So while it seems logical to have an implementation within a database it is
not necessarily considered as such.
_____
Resnick: Again, I'm not understand your reply. Can you expand on what you
mean here?
_____
Mancuso: The statment here is regarding the rule set, which is from the
regulator, so the current phrasing seems OK. Note there are a significant
number of device-only rule-set requirements (complexity is to be expected),
so the operational requirement here is for the master to obtain
"information." The current expectation is that the db may communicate the
name of the applicable regulatory ruleset to the device, but not the
specific parameters.
_____

O.5 (and O.9 through O.10 and O.12 through O.14): As above, you can change
"local regul8atory policy" to "the database rule set", "determined by
regulator policy" can be "enumerated in the database rule set", etc.
____
Mancuso: A db can serve multiple regulatory domains, and hence, rulesets.
And note that the currently applicaple rule set may not come from a local
regulatory domain, but be imported from a foreign regulator (e.g., Brazil
decides to use FCC rules)
_____

Security Considerations

Section 8, generally: Same issue with "regulatory". See if there are any
that are more accurately "database rules".
____
Mancuso: Again, multiple rule sets may apply for a given regulatory domain.

Threat 7: This doesn't strike me as a security consideration per se. This
might make more sense incorporated into an operational requirement.
___
Mancuso: Agreed. Moved duscussion of emergency services need for white
space to new O.17 requirement, and condensed it to: "In the case of a
natural disaster,emergency services may need to use distributed white space
databases on short notice. The database should support any emergency
regulations adopted by regulators to provide priority allocation of white
space spectrum to emergency services."

---
end of comments

On Fri, Jan 25, 2013 at 9:51 AM, Anthony Mancuso <[email-masked]>wrote:

> I just posted version 11 of the PAWS Use Case & Requirements draft to
> IETF. In this draft, I responded to several of the comments posted to the
> list; I left a few TODOs, and am awaiting further comments for the next
> draft.
>
> Nancy Bravin: I think since we are dealing with a protocol that can be
> used globally, terms such as listed below, with definition, will make it
> easier to those countries who are not English speaking, or the translation
> to words, with no definition can be confusing. It is not a deal breaker,
> but consideration for emerging countries that lack experience in these
> areas.
> _____
> Mancuso: The intent of the existing wording is simply that the master
> sends out a request and waits for a response, not to imply that it the
> device query is constrained or qualified by the device's understanding of
> its regulatory domain. I deleted the extra language to read as follows:
> "The master device constructs and sends a service request over the
> Internet."
> _______
> Stanforth: If the device is a high power device the slave must get it's
> own channel list. It can use a master to do this, using white space
>> "no go" with the Last Call, even if there is no new draft ready to go. We
>> can Last Call -10 if nobody thinks there's a strong reason to wait. I am
>> fine with either path.
>>
>>
>> pr
>>
>> some technical points I need to collaborate on.****
>>
>> ** **
>>
>> I think if Tony can spin a rev before EOB tomorrow, we should do that,
>> but I'm thinking that the current rev is good enough, and I'd prefer to get
>> it into the Feb 7 telechat.   ****
>>
>> ** **
>>
>> generating a new version in response to the comments and clarifications.*
>> ***
>>
>> ** **
>>

---

From: <[email-masked]>
Date: Wed, 30 Jan 2013 18:30:23 +0000

Thanks Tony.
Pete, this version I think is ready for Last Call.

-          Gabor

From: ext Anthony Mancuso [mailto:[email-masked]]
Sent: Tuesday, January 29, 2013 3:16 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: Pete Resnick; [email-masked]
Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10

To PAWS list:

Here are the collected comments on version 10 (the last posted version) of the PAWS Use Case & Requirements draft and my responses (what I did and didn't do) for version 12, which I just posted to IETF.

Tony Mancuso

Abstract

End of the first paragraph, perhaps add: "The IETF has undertaken to develop a protocol for that management database."
___
Mancuso: Done
_____

Introduction

2.2: For "Device ID", it says, "that identifies the manufacturer, model number, and serial number." Does the device ID have to identify that information? Can it simply be unique?
____
Stanforth: Regulators are asking for manufacturer and model number as they may require action, enforcement or denial by the DB on the set to manufacturer devices or a specific model of device
_____
Resnick: I guess the question is: Are there any potential implementers of this protocol (or potential regulatory bodies) that *don't* care about manufacturer or model or etc.?
_____
Mancuso: Simplified to:  "An identifier for each master device."
_________

"Radio Access Technology" is only used once in section 5.1. No need for the definition here.
_____
Nancy Bravin: I think since we are dealing with a protocol that can be used globally, terms such as listed below, with definition, will make it easier to those countries who are not English speaking, or the translation to words, with no definition can be confusing. It is not a deal breaker, but consideration for emerging countries that lack experience in these areas.
_____
Resnick: Sorry, I think I wasn't clear enough. Other than "Protected Contour" (which is not used anywhere), I was not suggesting having *no* definition of the terms listed. I was just saying that if they only occur once in the document, define them inline where they are used instead of in the definitions section. But that's strictly an editorial comment. Entirely up to you all whether you want to make a change.
_____
Mancuso: Deleted Protected Contour, and moved the definition of single-use terms into the text.
_____

Protocol Services (separated out Protocol Services from Use Cases per comment below. (I renumbered the comments below to correspond to the new organization).

3. This section (and its subsections) seems oddly placed. It is not use cases, but general protocol services that cut across use cases. Perhaps 3.1 and 3.2 should be separate top-level sections?
---
Mancuso: Done. Moved Protocol Services to new top-level head (Section 3); Use Cases now in new Section 4.
_____

3. "A complete protocol solution must enable all potential white space services." That seems a bit absolute. How about "must enable many different potential white space services"?
____

Benjamin Rolfe: I'd strike the entire sentence. There is no such thing as a "complete protocol".   If you must have it, change it to "this protocol" and it isn't wrong (but still not adding information).

Mancuso: Rephrased to: "A protocol solution must enable many different potential white space services. ".
_____

3.1 & 3.2: Throughout this section, there's no need to use the term "master". These services exist whether a device is acting as a master for other devices or whether it is acting on its own. Given that there's been no discussion of slave devices yet (that happens in 3.2), I found the use of the term "master" confusing in these sections. (I suppose you could expand the definition of master in 2.2 to explain that it could refer to a device acting on its own with no slaves, but I still think that might be confusing.
_____
Stanforth: Broadcast use case is a master with no slave, at least in the context of a slave that communicates with or is controlled by a master.
_____
Resnick: So are you saying we do or do not need the term "master" in these sections?
_____
Mancuso: I clarified the definition of master device: "A device that queries a database, on its own behalf and/or on behalf of a slave device, to obtain available spectrum information.". I think this definition plus the definition of a slave device ("A device that queries the database through a Master Device.") makes the use of the term in this and latter sections and illustrations appropriate -- namely, a master device is one that contacts a database to obtain spectrum (for itself or other devices). Slave devices under these definitions, do not contact the db directly, omitting them from the discussion and refering in the text or illustrations solely to a master device makes sense, and is not dependent on also referencing a slave device. Another way of saying it: we use the term master only as a way of describing a device used to query the db directly for spectrum availability. Denoting a device as master does not necessarily imply the use of slaves (devices that are not used to query the db directly) in a particular use case or illustration.
_______________

3.1, item 2: This says that the device will discover the database "in the local regulatory domain". How does the device determine the "local regulatory domain"? I suspect that the phrase "in the local regulatory domain" is meaningless for purposes of this sentence. If it is not, there's something that's not explained.
_____
Stanforth: The location of a device determines it regulatory domain. However the device may understand this or it may be told.
_____
Resnick: Right. That seems to indicate that the device that this section should say, "for its current location" and not "in the local regulatory domain". The device needs to know its location, but not its regulatory domain.
_____
Stanforth: For instance our current US implementation validates that a device is within the regulatory domain. If not we deny it service but allowed for the DB to tell the device who or what it should contact. In other words you are now in Canada so you need to talk to xxx not to and FCC DB. Taken together with the comment below this may need some thought and additional work.
_____
Resnick: I think we're on the same page.
_____
Mancuso: Rewrote to clarify the difference between the discovery phase (locating a trusted database) and the initial contact with the trusted database. Also noted the different ways a device can locate the database URI (through discovery or pre-configured URIs).
_______
3.2: Similar questions regarding regulatory domains. For example, "2.  To register with the database, the master device sends the database the registration information required under regulatory rules." How does the device determine which regulatory rules it is under and therefore which information to send to the database. If the answer is, "It queries the database", then it is not the regulatory rules the device cares about; it is the information the database is configured to ask for (which will presumably be in accordance to some regulations, but are out of band of any protocol work). If the answer is, "It is pre-configured in the device", then the regulatory rules are again out of band. Either way, mention of them would be unnecessary.
___
Mancuso: Agreed. I think this was simply a matter of misphrasing. Deleted the extra language to read: "To register with the database, the master device sends registration information to the database."
_____

Use Cases

4.1, 4.2, and 4.3, in general: When "slave device" is defined in 2.2, it's only a slave for purposes of talking to the database. But there is an implication in these sections that the slave device uses the master for internet connectivity. I don't think that's the intent, but either way there's some clarification that's needed. Further confusing me about this point is (a) the master device is always the one in the diagrams with the antenna, but as far as I can tell, a master device doesn't need an antenna, the slaves do; and (b) most of the links marked "Air" seem to me not to require an air interface, but could also be wired. I could use some explanation.
_____
Stanforth
The FCC, as an example, has two concepts of a slave. The first is a client served by a master, think 802.11 client using a channel served by an AP. This is the model for low power devices.
_____
Resnick: OK, but does the low power device actually ever request white space spectrum? If not, then it is not involved in this protocol, right?
___
Stanforth: If the device is a high power device the slave must get it's own channel list. It can use a master to do this, using white space spectrum, if it has no other means of contacting the database.
____
Resnick: This I understood until you said "using white space spectrum". It can't use white space spectrum to talk to the master until it is allocated spectrum by the database, can it? It talks to the master *not* using white space spectrum, gets it's answer through the master about which spectrum to use, and then stops talking to the master, correct?
____
Mancuso: Masters are defined as the device that can contact the db on its own (knows its geolocation), and the use cases I think are consistent with this definition. There is no constraint on how the slaves or masters communicate (air or wire) but the illustrations attempt to show common connections for the examples (for hotspots, WANS, etc., slave devices will connect over air to master). Also, slaves can use white space spectrum as appropriate to the local white space network being established -- to connect to the Internet through the master (or some other AP), for local communications only, or some other use of the spectrum. I deleted the extra master antenna shown in use case 5 (local tv broadcast).

4.1, item 7: Does the slave provide its location, device identifier, and antenna height, the same way the master does when it queries? If so (especially in the case of the master sub-allocating for the slaves), doesn't the master have to provide the set of locations for all of the slaves in step 5? Some further explanation might be in order.
_____
Stanforth: As above a low power slave, under FCC rule, does not have to provide any of this information but a high power slave does.
_____
Resnick: Does a low power slave talk to the database at all?
_____
Mancuso: I moved related slave requests into the corresponding sections for the master.
______
4.1, item 8: It says that the white space is allocated to slaves "for communication over the network". That's not right is it? In this scenario, the allocated white space could be used for network (I read "Internet") communication *or anything else*, can't it?
_____
Stanforth: High power again. A slave may not get the same channel list as the master and may not be able to use the channel the master is currently using so a negotiation will be necessary.
_____
Resnick: I'm not sure whether you agree or disagree with my point here. I don't understand your reply.
_____
Mancuso: The network refers to the local master-slave network, not to connectivity to the Internet. I deleted "for communication over the network" for clarity.
_____

3.2.1, item 9: Is this an important part of the scenario? Why wouldn't it be perfectly reasonable for communication between the master and slaves continue on its original connection and that the white space is only used for other communications the slave wishes to do?
_____
Stanforth: same as Iten 8, above.
____
Mancuso: Changed to "may occur". Technically, the "network" we are talking about here is the white space network, which only uses white space (after initial bootstrapping communications between slaves and masters). But I agree that we should recognize (implicitly) the ability of devices to use other spectrum/technologies for ongoing communications.
_____

4.2: This scenario was confusing to me because the master seems completely unnecessary to the example. Please explain.
_____
Mancuso: As noted, the master is optionally used by the slave to query the db for spectrum. And again, master only connotes the device's ability to query the db directly.
_____

4.4 and 4.5: Another example of the term "master" seems unnecessary in the example, since there are no slaves.
____
Mancuso: Again, master only connotes ability to query the db directly by the device.
____

Problem Statement

5: "Master" seems unnecessary to the example. Also, I suggest in the second-to-last paragraph, you say "The databases are locale specific" instead of "country specific", and delete the word "competing" from the last sentence of that paragraph.
________
Mancuso: Same response re masters as above. Made the suggested wording changes re "locale" and "competing."
_____

5.1, item 1: Is this referring to the Internet connectivity between the WS device and the database? If so, as above, does it necessarily need to be an air interface?
___
Mancuso: This wasn't meant to imply air the exclusive interface -- Made this clearer by using "any" air interface used by devices; further limited reference to messages betweein devices and db as messages from master device to db (since, by definition, slave devices don't communicate directly to db).
_____

5.1, item 3: Again I suggest changing "operate in any country" to "operate in any locale" and change "country-specific" to "locale-specific". (The other occurrence of "country" seems correct.)
____
Mancuso: Made suggested wording changes.
_____

5.2: Instead of "regulatory-domain", wouldn't either "locale" or simply "domain" be sufficient?
_____
Stanforth: The regulatory domain is assumed to be similar to a country domain but need not be. A database could be permitted to serve  a different definition. In the FCC case they currently limit the domain to the 12mile nautical limit and, as we speak databases are only permitted to service the NE USA.
_____
Resnick: I don't think you answered my question.
_____
Mancuso: I changed to "domain specific". Not that the db may not be locale-based (a South American country may opt for FCC domain rules).
_____

Requirements:
_____
P.1: "The master device may validate the database against a list of approved databases maintained by a regulatory body." I don't understand that as a protocol requirement. What is being required?
___
Mancuso: (Moved info up from Operation requirements per later comment). Rephrased to clarify that the master device MUST identify a db, and MAY discover or be pre-configured with db URIs, and MAY validate db URIs against a list of approved databases maintained by a regulatory body."

P.5 and P.6: The requirement here is for *message-level* integrity and encryption? That's OK, but I want to make sure that's what you mean.
___
Rex Buddenberg: encryption gets you confidentiality (which may or may not be a
requirement).  It does not get you authenticity.

integrity gets you bit-perfection.  Which is a requirement.  But
integrity does not get you authenticity ... which is a requirement. I
can't think of a situation where you don't need both.  (In public key, a
digital signature provides both authenticity and integrity, assuming you
have a PKI you can rely on.
____
Mancuso: Yes, that is the intent, and yes, we want all three. DB authenticity is addressed in p4.
___
P.8 and P.14: I don't think "result codes" and "response codes" are the requirement here, are they? It sounds like the requirement is "indication of success or failure".
_____
Mancuso: Rephrased to state the requirement in terms of the success or failure of the requests.
_____

P.15: I'm not clear on what this requirement means in practical terms. Some more explanation seems in order.
___
Mancuso: Rephrased for clarity to: "The protocol MUST support the capability for the database to inform master devices of changes to spectrum availability information in a timely manner."

O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy required by the database"?
_____
Stanforth: Acceptable Location Accuracy is defined by the regulator and applied to the calculations of the database
_____
Resnick: So the database will tell the device what level of accuracy is required?
_____
Mancuso: Clarified as follows: "Locations MUST be determined to the accuracy required by the applicable regualtory domain." These are operational requirements, and not part of the protocol. Accuracy is verified by certification of devices by regulators.
____

Mancuso: The master locating the DB is a requirement, so I moved this to P.1. Renumbered the remaining requirements (and comments below).
____

O.3: This requirement seems a bit overly obvious and silly to state as a requirement. Why is it necessary to say that you need a connection?
____

O.4: Again, "regulatory body" seems unnecessary here. Substituting "database" seems sufficient, since you'll be getting the rule set from the database.
_____
Stanforth: General observation about this and the next couple of comments. The FCC Certifies a radio and a database as a "system" Ofcom is not considering a system. Other regulators may have other thoughts. In the case of the FCC some of the function is validated/certified, what ever you want to call it for the combination not as a function of one or the other.
So while it seems logical to have an implementation within a database it is not necessarily considered as such.
_____
Resnick: Again, I'm not understand your reply. Can you expand on what you mean here?
_____
Mancuso: The statment here is regarding the rule set, which is from the regulator, so the current phrasing seems OK. Note there are a significant number of device-only rule-set requirements (complexity is to be expected), so the operational requirement here is for the master to obtain "information." The current expectation is that the db may communicate the name of the applicable regulatory ruleset to the device, but not the specific parameters.
_____

O.5 (and O.9 through O.10 and O.12 through O.14): As above, you can change "local regul8atory policy" to "the database rule set", "determined by regulator policy" can be "enumerated in the database rule set", etc.
____
Mancuso: A db can serve multiple regulatory domains, and hence, rulesets. And note that the currently applicaple rule set may not come from a local regulatory domain, but be imported from a foreign regulator (e.g., Brazil decides to use FCC rules)
_____

Security Considerations

Section 8, generally: Same issue with "regulatory". See if there are any that are more accurately "database rules".
____
Mancuso: Again, multiple rule sets may apply for a given regulatory domain.

Threat 7: This doesn't strike me as a security consideration per se. This might make more sense incorporated into an operational requirement.
___
Mancuso: Agreed. Moved duscussion of emergency services need for white space to new O.17 requirement, and condensed it to: "In the case of a natural disaster,emergency services may need to use distributed white space databases on short notice. The database should support any emergency regulations adopted by regulators to provide priority allocation of white space spectrum to emergency services."

---
end of comments

On Fri, Jan 25, 2013 at 9:51 AM, Anthony Mancuso <[email-masked]<mailto:[email-masked]>> wrote:
I just posted version 11 of the PAWS Use Case & Requirements draft to IETF. In this draft, I responded to several of the comments posted to the list; I left a few TODOs, and am awaiting further comments for the next draft.

Tony Mancuso

***************
Tony Mancuso Notes - PAWS Use Case & Requirements Notes v. 11 (I consolidated Pete Resnick's initial comments with other comments received on selected points together with my responses)

2.2: For "Device ID", it says, "that identifies the manufacturer, model number, and serial number." Does the device ID have to identify that information? Can it simply be unique?
____
Stanforth: Regulators are asking for manufacturer and model number as they may require action, enforcement or denial by the DB on the set to manufacturer devices or a specific model of device
_____
Resnick: I guess the question is: Are there any potential implementers of this protocol (or potential regulatory bodies) that *don't* care about manufacturer or model or etc.?
_____
Mancuso: Waiting for further comment.
_____
"Device Class" is only used once in section 5.1. No need for the definition here.

"Radio Access Technology" is only used once in section 5.1. No need for the definition here.
_____
Nancy Bravin: I think since we are dealing with a protocol that can be used globally, terms such as listed below, with definition, will make it easier to those countries who are not English speaking, or the translation to words, with no definition can be confusing. It is not a deal breaker, but consideration for emerging countries that lack experience in these areas.
_____
Resnick: Sorry, I think I wasn't clear enough. Other than "Protected Contour" (which is not used anywhere), I was not suggesting having *no* definition of the terms listed. I was just saying that if they only occur once in the document, define them inline where they are used instead of in the definitions section. But that's strictly an editorial comment. Entirely up to you all whether you want to make a change.
_____
Mancuso: Deleted Protected Contour, and moved the definition of single-use terms into the text.
_____

3.1 This section (and its subsections) seems oddly placed. It is not use cases, but general protocol services that cut across use cases. Perhaps 3.1 and 3.2 should be separate top-level sections?
---
Mancuso: Done. Moved Protocol Services to new top-level head (Section 3); Use Cases now in new Section 4.
_____

3.1.1 & 3.1.2: Throughout this section, there's no need to use the term "master". These services exist whether a device is acting as a master for other devices or whether it is acting on its own. Given that there's been no discussion of slave devices yet (that happens in 3.2), I found the use of the term "master" confusing in these sections. (I suppose you could expand the definition of master in 2.2 to explain that it could refer to a device acting on its own with no slaves, but I still think that might be confusing.
_____
Stanforth: Broadcast use case is a master with no slave, at least in the context of a slave that communicates with or is controlled by a master.
_____
Resnick: So are you saying we do or do not need the term "master" in these sections?
_____
Mancuso: I clarified the definition of master device: "A device that queries a database, on its own behalf and/or on behalf of a slave device, to obtain available spectrum information.". I think this definition plus the definition of a slave device ("A device that queries the database through a Master Device.") makes the use of the term in the section appropriate -- namely, a master device is one that contacts a database to obtain spectrum (for itself or other devices). Slave devices under these definitions, do not contact the db directly, omitting them from the discussion at this point makes sense. Another way of saying it: we use the term master only as a way of describing a device used to query the db directly for spectrum availability. Denoting a device as master does not necessarily imply the use of slaves (devices that are not used to query the db directly) in a particular use case.
_______________

3.1.1, item 2: This says that the device will discover the database "in the local regulatory domain". How does the device determine the "local regulatory domain"? I suspect that the phrase "in the local regulatory domain" is meaningless for purposes of this sentence. If it is not, there's something that's not explained.
_____
Stanforth: The location of a device determines it regulatory domain. However the device may understand this or it may be told.
_____
Resnick: Right. That seems to indicate that the device that this section should say, "for its current location" and not "in the local regulatory domain". The device needs to know its location, but not its regulatory domain.
_____
Stanforth: For instance our current US implementation validates that a device is within the regulatory domain. If not we deny it service but allowed for the DB to tell the device who or what it should contact. In other words you are now in Canada so you need to talk to xxx not to and FCC DB. Taken together with the comment below this may need some thought and additional work.
_____
Resnick: I think we're on the same page.
_____
Mancuso: The intent of the existing wording is simply that the master sends out a request and waits for a response, not to imply that it the device query is constrained or qualified by the device's understanding of its regulatory domain. I deleted the extra language to read as follows: "The master device constructs and sends a service request over the Internet."
_______
3.1.2: Similar questions regarding regulatory domains. For example, "2.  To register with the database, the master device sends the database the registration information required under regulatory rules." How does the device determine which regulatory rules it is under and therefore which information to send to the database. If the answer is, "It queries the database", then it is not the regulatory rules the device cares about; it is the information the database is configured to ask for (which will presumably be in accordance to some regulations, but are out of band of any protocol work). If the answer is, "It is pre-configured in the device", then the regulatory rules are again out of band. Either way, mention of them would be unnecessary.
___
Mancuso: Agreed. Again, I think this was simply a matter of misphrasing. Deleted the extra language to read: "To register with the database, the master device sends registration information to the database."
_____

3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in 2.2, it's only a slave for purposes of talking to the database. But there is an implication in these sections that the slave device uses the master for internet connectivity. I don't think that's the intent, but either way there's some clarification that's needed. Further confusing me about this point is (a) the master device is always the one in the diagrams with the antenna, but as far as I can tell, a master device doesn't need an antenna, the slaves do; and (b) most of the links marked "Air" seem to me not to require an air interface, but could also be wired. I could use some explanation.
_____
Stanforth
The FCC, as an example, has two concepts of a slave. The first is a client served by a master, think 802.11 client using a channel served by an AP. This is the model for low power devices.
_____
Resnick: OK, but does the low power device actually ever request white space spectrum? If not, then it is not involved in this protocol, right?
___
Stanforth: If the device is a high power device the slave must get it's own channel list. It can use a master to do this, using white space spectrum, if it has no other means of contacting the database.
____
Resnick: This I understood until you said "using white space spectrum". It can't use white space spectrum to talk to the master until it is allocated spectrum by the database, can it? It talks to the master *not* using white space spectrum, gets it's answer through the master about which spectrum to use, and then stops talking to the master, correct?
____
Mancuso: Waiting for any further input.
_____

3.2.1, item 7: Does the slave provide its location, device identifier, and antenna height, the same way the master does when it queries? If so (especially in the case of the master sub-allocating for the slaves), doesn't the master have to provide the set of locations for all of the slaves in step 5? Some further explanation might be in order.
_____
Stanforth: As above a low power slave, under FCC rule, does not have to provide any of this information but a high power slave does.
_____
Resnick: Does a low power slave talk to the database at all?
_____
Mancuso: Waiting for any further input.
______
3.2.1, item 8: It says that the white space is allocated to slaves "for communication over the network". That's not right is it? In this scenario, the allocated white space could be used for network (I read "Internet") communication *or anything else*, can't it?
_____
Stanforth: High power again. A slave may not get the same channel list as the master and may not be able to use the channel the master is currently using so a negotiation will be necessary.
_____
Resnick: I'm not sure whether you agree or disagree with my point here. I don't understand your reply.
_____
Mancuso: Waiting for any further input.
_____

3.2.2: This scenario was confusing to me because the master seems completely unnecessary to the example. Please explain.
_____
Mancuso: TODO. The master is optionally used by the slave to query the db for spectrum. And again, master only connotes ability to query the db directly by the device. I do think we need to eliminate the implication that the slave then connects to the Internet through the master (it uses white space spectrum, right)?
_____

3.2.4 and 3.2.5: Another example of the term "master" seems unnecessary in the example, since there are no slaves.
____
Mancuso: Again, master only connotes ability to query the db directly by the device.
____
4: "Master" seems unnecessary to the example. Also, I suggest in the second-to-last paragraph, you say "The databases are locale specific" instead of "country specific", and delete the word "competing" from the last sentence of that paragraph.
________
Mancuso: Same response re masters as above. Made the suggested wording changes re "locale" and "competing."
_____

4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply "domain" be sufficient?
_____
Stanforth: The regulatory domain is assumed to be similar to a country domain but need not be. A database could be permitted to serve  a different definition. In the FCC case they currently limit the domain to the 12mile nautical limit and, as we speak databases are only permitted to service the NE USA.
_____
Resnick: I don't think you answered my question.
_____
Mancuso: I changed to "domain specific". Not that the db may not be locale-based (a South American country may opt for FCC domain rules).
_____

O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy required by the database"?
_____
Stanforth: Acceptable Location Accuracy is defined by the regulator and applied to the calculations of the database
_____
Resnick: So the database will tell the device what level of accuracy is required?
_____

O.5: Again, "regulatory body" seems unnecessary here. Substituting "database" seems sufficient, since you'll be getting the rule set from the database.
_____
Stanforth: General observation about this and the next couple of comments. The FCC Certifies a radio and a database as a "system" Ofcom is not considering a system. Other regulators may have other thoughts. In the case of the FCC some of the function is validated/certified, what ever you want to call it for the combination not as a function of one or the other.
So while it seems logical to have an implementation within a database it is not necessarily considered as such.
_____
Resnick: Again, I'm not understand your reply. Can you expand on what you mean here?
_____

On Thu, Jan 24, 2013 at 3:19 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Will wait for Tony to generate a new version by addressing the received comments, before issuing the Last Call.

-          Gabor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Pete Resnick
Sent: Wednesday, January 23, 2013 2:59 PM
To: Anthony Mancuso

Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10

pr

Brian

pr

--

paws mailing list

--

---

From: Pete Resnick <[email-masked]>
Date: Thu, 31 Jan 2013 08:44:27 -0600

> Pete, this version I think is ready for Last Call.

Excellent. I'll have a few more minor comments, but you can simply 
consider them as Last Call comments and deal with them with any other 
comments that come in. I'll do the Last Call request today.

Dan Romascanu (our IEEE-SA liaison manager) reminded me that we promised 
to notify the assorted IEEE 802 WGs when documents reach Last Call. 
Gabor or Brian: Can you take care of that?

Thanks,

pr

---

From: <[email-masked]>
Date: Thu, 31 Jan 2013 21:17:57 +0000

Yes. I'll send a notification to the relevant ieee802 wgs.

-          Gabor

From: ext Pete Resnick [mailto:[email-masked]]
Sent: Thursday, January 31, 2013 6:44 AM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]; [email-masked]
Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10

On 1/30/13 12:30 PM, [email-masked]<mailto:[email-masked]> wrote:
Pete, this version I think is ready for Last Call.

Excellent. I'll have a few more minor comments, but you can simply consider them as Last Call comments and deal with them with any other comments that come in. I'll do the Last Call request today.

Dan Romascanu (our IEEE-SA liaison manager) reminded me that we promised to notify the assorted IEEE 802 WGs when documents reach Last Call. Gabor or Brian: Can you take care of that?

Thanks,

pr

--

---

From: Pete Resnick <[email-masked]>
Date: Thu, 31 Jan 2013 23:44:23 -0600

The Last Call should be coming out of the secretariat soon. Trimming the 
message to things where I still have some comments. Please consider the 
following part of the Last Call comments:

> Also added reference to the PAWS protocol to 1.1.

Please don't refer to the WG, either in the Abstract or in the Intro. 
First of all, there ought to be no references in the Abstract anyway 
since the Abstract is often displayed in announcements and other places 
without the rest of the document. But more importantly, I don't think 
what you put in flows very well. In the Abstract, just saying "protocol" 
is sufficient. In the Intro, I'd suggest simply changing the last 
paragraph to:

    This document includes the problem statement for the development of a
    database query protocol to access a database of whitespace
    information followed by use cases and requirements for that protocol
    associated with the use of white space spectrum by secondary users.

> for other devices or whether it is acting on its own. Given that 
> there's been no discussion of slave devices yet (that happens in 3.2), 
> I found the use of the term "master" confusing in these sections. (I 
> suppose you could expand the definition of master in 2.2 to explain 
> that it could refer to a device acting on its own with no slaves, but 
> I still think that might be confusing.
> _____
> Stanforth: Broadcast use case is a master with no slave, at least in 
> the context of a slave that communicates with or is controlled by a 
> master.
> _____
> queries a database, on its own behalf and/or on behalf of a slave 
> device, to obtain available spectrum information.". I think this 
> definition plus the definition of a slave device ("A device that 
> queries the database through a Master Device.") makes the use of the 
> term in this and latter sections and illustrations appropriate -- 
> namely, a master device is one that contacts a database to obtain 
> spectrum (for itself or other devices). Slave devices under these 
> discussion and refering in the text or illustrations solely to a 
> master device makes sense, and is not dependent on also referencing a 
> slave device. Another way of saying it: we use the term master only as 
> a way of describing a device used to query the db directly for 
> spectrum availability. Denoting a device as master does not 
> necessarily imply the use of slaves (devices that are not used to 
> query the db directly) in a particular use case or illustration.

That's all fine, but then in the first sentence of 3.1, it says "A white 
space radio network is created by a master device." That's not true, or 
at least not necessarily true. The white space network is created by 
either the master or the high-power slave. What defines something as a 
master is not that it creates a white space radio network. A master is 
simply defined as that which queries the database. So I suspect the word 
"master" in this section is wrong and the first paragraph of 3.1 needs a 
bit more work to remove all reference to creation of the whitespace 
network. Creating the network is not part of the discovery phase at all.

> 3.2: Similar questions regarding regulatory domains. For example, "2. 
>  To register with the database, the master device sends the database 
> the registration information required under regulatory rules." How 
> does the device determine which regulatory rules it is under and 
> therefore which information to send to the database. If the answer is, 
> "It queries the database", then it is not the regulatory rules the 
> device cares about; it is the information the database is configured 
> to ask for (which will presumably be in accordance to some 
> regulations, but are out of band of any protocol work). If the answer 
> is, "It is pre-configured in the device", then the regulatory rules 
> are again out of band. Either way, mention of them would be unnecessary.
> ___
> Mancuso: Agreed. I think this was simply a matter of misphrasing. 
> Deleted the extra language to read: "To register with the database, 
> the master device sends registration information to the database.

There are still several references in 3.2 to "regulatory domain" and 
"regulatory requirement" that I think are unnecessary and confusing and 
should be removed.

> 4.2: This scenario was confusing to me because the master seems 
> Mancuso: As noted, the master is optionally used by the slave to query 
> the db for spectrum. And again, master only connotes the device's 
> ability to query the db directly.

OK, this section still does not make sense to me. The slave is getting 
whitespace in this scenario. But in the diagram, the slave doesn't have 
the antenna; the master does. That doesn't jibe with the rest of the 
example. If it's the slave that wants to move away from it's metered 
service and use whitespace, then it should have the antenna. If the 
slave wants to talk to an AP that's going to use the whitespace, there 
should be a box for the AP in the diagram. If you want to say that the 
master and the AP can be one device, still show two boxes but say they 
can be in the same box. If the master is doing the querying and setting 
up the whitespace and the "slave" is doing nothing with regard to 
whitespace but simply using the master as an Internet gateway, then the 
"slave" is not a slave.

> 5.1, item 1: Is this referring to the Internet connectivity between 
> the WS device and the database? If so, as above, does it necessarily 
> need to be an air interface?
> ___
> Mancuso: This wasn't meant to imply air the exclusive interface -- 
> Made this clearer by using "any" air interface used by devices; 
> further limited reference to messages betweein devices and db as 
> messages from master device to db (since, by definition, slave devices 
> don't communicate directly to db).

You missed one bit of what I was asking: Couldn't the interface between 
the database and the master be wired, not air at all?

> approved databases maintained by a regulatory body." I don't 
> understand that as a protocol requirement. What is being required?
> ___
> Mancuso: (Moved info up from Operation requirements per later 
> comment). Rephrased to clarify that the master device MUST identify a 
> db, and MAY discover or be pre-configured with db URIs, and MAY 
> validate db URIs against a list of approved databases maintained by a 
> regulatory body."

I don't think I explained my question well enough. So let me try it this 
way. Here's what you currently have:

    P.1  The master device MUST identify a database to which it can
       register, make spectrum availability requests, etc.

That's not the requirement. Here you're just describing what the master 
is going to do. So MUST isn't needed here. "will" is probably 
sufficient. Next comes the requirement:

       The master
       device MAY select a database by discovery at run time or by means
       of a pre-programmed URI address.

That's fine, but it doesn't make it clear that the discovery protocol is 
a requirement. Shouldn't it say, "The protocol must support the 
discovery of an appropriate database given a location provided by the 
master device. The master device may select a database..."?

       The master device MAY validate
       discovered or configured database addresses against a list of
       approved databases maintained by a regulatory body.

Here's my original confusion. I think this would be better as, "The 
master device may validate discovered or configured database addresses 
against a list of known databases (e.g., a list of databases approved by 
a regulatory body)." That is, the requirement (and it's not a protocol 
requirement) is that the master will have the ability to (optionally) do 
the validation against a list. Where that list comes from, e.g., a 
regulatory body, is not part of the requirement.

> Stanforth: Acceptable Location Accuracy is defined by the regulator 
> and applied to the calculations of the database
> _____

Oh, I think that made it worse. If the regulators are determining the 
accuracy and certifying the devices, this is not an operational 
requirement; it's all going to be pre-configured. Is that what you mean?

> Stanforth: General observation about this and the next couple of 
> comments. The FCC Certifies a radio and a database as a "system" Ofcom 
> is not considering a system. Other regulators may have other thoughts. 
> In the case of the FCC some of the function is validated/certified, 
> what ever you want to call it for the combination not as a function of 
> one or the other.
> Mancuso: The statment here is regarding the rule set, which is from 
> the regulator, so the current phrasing seems OK.

I think we are talking past each other: How does the master device 
determine the rule set? Is it getting it from the database? Is it 
pre-configured? In any event, does the master device know that the rule 
set came from the regulator? If not, then there's no need to mention the 
regulator at all.

> Note there are a significant number of device-only rule-set 
> requirements (complexity is to be expected), so the operational 
> requirement here is for the master to obtain "information." The 
> current expectation is that the db may communicate the name of the 
> applicable regulatory ruleset to the device, but not the specific 
> parameters.

But the master device is only dealing with the name of the rule set. It 
doesn't have semantics to the master device. The master device DOES NOT 
CARE that the rule set came from a regulator, or the manufacturer, or 
from invaders from Mars. The concept of the regulator is irrelevant to 
the operational requirement.

> _____
>
> O.5 (and O.9 through O.10 and O.12 through O.14): As above, you can 
> change "local regul8atory policy" to "the database rule set", 
> "determined by regulator policy" can be "enumerated in the database 
> rule set", etc.
> ____
> Mancuso: A db can serve multiple regulatory domains, and hence, 
> rulesets. And note that the currently applicaple rule set may not come 
> from a local regulatory domain, but be imported from a foreign 
> regulator (e.g., Brazil decides to use FCC rules)
> _____
>
> Security Considerations
>
> Section 8, generally: Same issue with "regulatory". See if there are 
> any that are more accurately "database rules".
> ____

See above.

pr