Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts

From: <[email-masked]>
Date: Thu, 7 Jun 2012 15:39:47 +0000

Folks,

I issued the below 2nd wglc on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-04.txt
and I only got one review with a comment which is easy to address.

We really need more reviews in order to be able to progress the draft. If you care about the use cases and requirements related to White Space Database Access, please read the draft and send your comments to the list. If you do not have comments, then send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments.

I cannot send the draft to the IESG without a minimum number of reviews. Ie, if we don't get reviews, we can't make progress.

Thanks, Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, May 15, 2012 5:50 PM
To: [email-masked]
Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts

Since there were quite a few changes made to the new version -04, let's have another WGLC for this document.

Therefore, I'd like to initiate a 2nd WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-04.txt

Please review the draft and send your comments to the list by June 1st, 2012.

If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments.

Thanks, Gabor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Probasco Scott (Nokia-CIC/Dallas)
Sent: Friday, May 11, 2012 11:51 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [paws] UC&R document

Hello All,

A new version of the Use Cases & Requirements draft has been uploaded. This version of the Internet Draft has addressed all of the issues raised during Working Group Last Call, including discussion from IETF #83, and is ready to be forwarded to IESG.

Kind Regards,
Raj & Scott

Draft:  http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-04.txt

Diff:   http://tools.ietf.org/rfcdiff?url2=draft-ietf-paws-problem-stmt-usecases-rqmts-04

Abstract:
   Portions of the radio spectrum that are assigned to a particular use
   but are unused or unoccupied at specific locations and times are
   defined as "white space".  The concept of allowing additional
   transmissions (which may or may not be licensed) in white space is a
   technique to &quot;unlock&quot; existing spectrum for new use.  An obvious
   requirement is that these additional transmissions do not interfere
   with the assigned use of the spectrum.  One approach to using the
   white space spectrum at a given time and location is to verify with a
   database for available channels.

   This document describes the concept of TV White Spaces.  It also
   describes the problems that need to be addressed to enable white
   space spectrum for additional uses, without causing interference to
   currently assigned use, by querying a database which stores
   information about the channel availability at any given location and
   time.  A number of possible use cases of white space spectrum and
   technology as well as a set of requirements for the database query
   protocol are also described.

---

From: <[email-masked]>
Date: Tue, 12 Jun 2012 11:51:20 +0100

Gabor

I will review the use cases and requirements document against the latest UK Ofcom requirements and send comments to the list, possibly this week.

Regards

Andy

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 07 June 2012 16:40
To: [email-masked]
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts

Folks,

Thanks, Gabor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, May 15, 2012 5:50 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts

Thanks, Gabor

Hello All,

Kind Regards,
Raj & Scott

Abstract:

---

From: "Das, Subir" <[email-masked]>
Date: Wed, 13 Jun 2012 03:28:39 +0000

We have reviewed the draft and it looks good.   Below are some technical and editorial comments.  Hope these are helpful.

Regards,
-Subir

====================
Technical:

Section 1.2.1, In Scope:  Page 6:

"2.  Connect to the database using a well-defined access method."

SD> What is the meaning of 'well-defined access method' here?  Then in the following bullet point,  it says  'using a well-defined protocol'. May be this is not necessary since the starting sentence of the section says  "The protocol will enable".

"As a result, some of the scenarios described in the following section are out of scope for this specification (although they might be  addressed by future specifications)."

SD> It would be good if the 'out of scope' sections are explicitly identified.

Section 2.2: Terminology: Page 6:

Database
In the context of white space and cognitive radio technologies, the database is an entity which contains, but is not limited to, current information about available spectrum at any given location

SD>  Suggest  modifying the definition like this:

In the context of white space and cognitive radio technologies, the database is an entity which contains, but is not limited to, current information about available spectrum at any given location  and time as  required by the regulatory policies.

Page 8:

"White Space Device (WSD)

A device which opportunistically uses some part of white space spectrum.  A white space device can be an access point, base  station, a portable device or similar.  A white space device may  be required by local regulations to query a database with its location to obtain information about available spectrum."

SD> Suggest  adding definition  of `Master Device` and ` Slave Device`  as two types of WSDS here and then delete  them from Page 7

-          Master Device WSD
A device   which is required to query the WS Database to find out the available operating channels.

-          Slave Device WSD
      A device which uses the spectrum made available by a master device and cannot query the  database  directly.

Section 4.1: Page 9

"A complete protocol solution must provide all services that are essential to enable the white space paradigm.  Before a white space device can begin operating it needs to know what channels are available by sending a query to a white space database for a list of available channels, the white space device must first locate or  "discover" a suitable database."

SD> Suggest changing the last sentence like this: "...., the white space device must have the capability to first locate or discover  a suitable database."

Section 4.1.2: Page 11

SD> In Figure 2,   Where is the 'Slave Device'?  Also it may be better just to mention 'Air IF'  instead of 'TDD Air IF'.

Page 15:

Comment: In some use case it says 'Dev' and other use cases it says 'Slave Dev'. Good to have the consistency.

Section 4.2.3: Page 18

"1. The dual mode (or multi mode) device (3G + TVWS) is connected to a 3G network.  The device has contacted a trusted database to discover the list of available TV channels at its current location.  The device has located a TVWS master/AP operating on  an available channel and has associated or connected with the TVWS master/AP."

SD>  I got the impression from the above text   that 'The device' refers to the `Slave  WS Dev'  in Figure 5 and it has contacted  the database.  Am I correct?   If so,  the text  needs to be updated to clarify that the slave cannot contact the database directly.

Section 4.2.6:  Page 22:

"7. The slave/user device scans to locate a mobile master transmission, and associates with the mobile master."

SD> Where is the slave device coming from? There is no 'Slave device' in  figure 8?

Section  4.2.7, Page 23:

SD> In Figure 9, there is a connection between Master devices using 'WS Air IF' . Does this mean these devices have both 'Master' and 'Slave' capabilities?  There is no such description and it is hard to understand why this connection is necessary and its intended purpose.

Section 4.2.8: Page 26:

"7. The slave devices fitted to the machines scan the TV bands to locate the master transmissions, and associate with the master device."

SD> The above step implies to me that all slave devices are connected to Master but the Figure 10 does not indicate that.

Section 5: Page 28:

SD>  In Figure it says 'WS device' and it interfaces to the Database directly . OTH, in all use cases the  interface with the database is coming from the 'Master Device'.  It should be consistent. Suggest changing to 'Master Device' or WSD Device (Master)'.

Section 5.2 : Page 29:

SD> This section seems to be a duplicate since Section 4.1.1 already covers this.

Section 5.4: Page 29:

"Use of XML for specifying a data model is an attractive option.  The intent is to evaluate the best option that meets the need for use between white space devices and databases."

SD> Suggest adding  XML  as an example

Section 6.1: Page 30:

"D.2: The Data Model  MAY  support specifying the regulatory domain and its corresponding data requirements."

SD> This requirement   should be a 'MUST'; if not how will the databases interpret it?  Also in P.2 it says "The protocol MUST support determination of regulatory domain governing its current location".  Unless it is a must, P.2 cannot be satisfied, IMO

Page 31:

"D.4:   The Data Model MUST support specifying a manufacturer's serial number for a master device"

SD>  Suggest deleting ` the master device' at the end.   Since the serial number is also applicable for slave device.

Page 33:

SD> Q.6 and Q.7 may  be merged.

Section 8: Page 38:

"Threat 8:  Natural disaster resulting in inability to obtain authorization for white space spectrum use by emergency responders"

Last sentence of this section says " The security requirements arising from the above threats are captured  in the requirements of section 6.1."

SD> Not sure I understand the threat model  here. Also it seems that the section reference is not correct.

========================

Editorial:

Abstract 2nd paragraph : Page 1
"This document describes the concept of TV White Spaces."

>From the above sentence I got the impression that the main focus of this draft is to describe the concept of TV white Space which I believe is not.  May rephrase this or start with the second sentence like: This document describes the use cases and requirements of TV White Space and introduces the problems that need ...."

Section 3.2, Page 8:

"More information about the switch to digital transmission is at : [DTV]."

SD> Delete ':'

Page 17:

If the channel that a slave/user terminal is currently using is not longer ..

SD> Typo :  'not/no  longer ...'

Page 28:

4.  Address regulatory requirements - Each country will likely have ...

SD> typo:  'likely to have ...'

Page 35:

"Threat 1:  .... A white space database may be operated by a commercial entity which restricts
access to authorized users. "

SD> May add 'only'  after 'access';  'access to only authorized users.

'Threat 2: A master device discovers a white space database(s) thru which it can query for channel information.'

SD> Typo: 'thru/through'

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 07, 2012 11:40 AM
To: [email-masked]
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts

Folks,

Thanks, Gabor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, May 15, 2012 5:50 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts

Thanks, Gabor

Hello All,

Kind Regards,
Raj & Scott

Abstract:

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 14 Jun 2012 17:17:19 -0400

Gabor, all,

I have reviewed the document and I think it is in very good shape. These
are some minor comments I have:

Abstract

Even though TV bands are currently the primary applications for PAWS,
the protocol could be applicable to other bands. Hence, I would suggest
removing "TV" from the second paragraph of the Abstract.

Section 1.1

Multiple examples are provided throughout this section. Some are inside
parenthesis, some are preceded by "e.g." and some are not. I would
suggest keeping a common writing style when providing these examples.

Replace "...such as antenna height, and sometimes power." by "...such as
antenna height and power."

Section 1.2.1

Replace "...basic service in TV white space." by  "...basic service in
white spaces." (or alternatively "...basic service in white space
frequencies.")

Section 6.1

P.5 and P.6 could be combined into one single requirement with some
wording similar to the one used in P.7, e.g. "The messages sent by the
master device and database MUST support integrity protection."

Section 6.2

I believe there is a preposition missing in O.5: "The master device MUST
obtain an indication 'about' the regulatory domain governing
operation..."

Regards,

Juan Carlos

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, June 07, 2012 11:40 AM
To: [email-masked]
Subject: Re: [paws] 2nd WGLC for
draft-ietf-paws-problem-stmt-usecases-rqmts

Folks,

I issued the below 2nd wglc on
http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecase
s-rqmts-04.txt

We really need more reviews in order to be able to progress the draft.
If you care about the use cases and requirements related to White Space
Database Access, please read the draft and send your comments to the
list. If you do not have comments, then send a note to the list that the
draft is good as it is, we need these notes as much as we need the
actual comments.

I cannot send the draft to the IESG without a minimum number of reviews.
Ie, if we don't get reviews, we can't make progress.

Thanks, Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, May 15, 2012 5:50 PM
To: [email-masked]
Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts

Since there were quite a few changes made to the new version -04, let's
have another WGLC for this document.

Therefore, I'd like to initiate a 2nd WG Last Call for comments on
http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecase
s-rqmts-04.txt

Please review the draft and send your comments to the list by June 1st,
2012.

If you review the draft and have no comments, send a note to the list
that the draft is good as it is, we need these notes as much as we need
the actual comments.

Thanks, Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Probasco Scott (Nokia-CIC/Dallas)
Sent: Friday, May 11, 2012 11:51 AM
To: [email-masked]
Subject: [paws] UC&R document

Hello All,

A new version of the Use Cases & Requirements draft has been uploaded.
This version of the Internet Draft has addressed all of the issues
raised during Working Group Last Call, including discussion from IETF
#83, and is ready to be forwarded to IESG.

Kind Regards,

Raj & Scott

Draft:
http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-04.tx
t

Diff:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-paws-problem-stmt-usecases
-rqmts-04

Abstract:

   technique to &quot;unlock&quot; existing spectrum for new use.  An
obvious

---

From: <[email-masked]>
Date: Wed, 20 Jun 2012 20:55:53 +0000

Hello Subir,

Thank you for reviewing the draft and providing comments. I have addressed each of your comments, please see below (MSP->) for further information.

Kind Regards,
Scott

From: "ext Das, Subir" <[email-masked]<mailto:[email-masked]>>
Date: Wed, 13 Jun 2012 03:28:39 +0000
To: Gabor Bajko <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts

Regards,
-Subir

====================
Technical:

“2.  Connect to the database using a well-defined access method.”

SD> What is the meaning of ‘well-defined access method’ here?  Then in the following bullet point,  it says  ‘using a well-defined protocol’. May be this is not necessary since the starting sentence of the section says  “The protocol will enable”.
MSP->These terms refer to the completed PAWS protocol.

“As a result, some of the scenarios described in the following section are out of scope for this specification (although they might be  addressed by future specifications).”

SD> It would be good if the ‘out of scope’ sections are explicitly identified.
MSP->I have removed the sentence citing 'out of scope'.

Database

In the context of white space and cognitive radio technologies, the database is an entity which contains, but is not limited to, current information about available spectrum at any given location  and time as  required by the regulatory policies.
MSP->I have modified the definition based on your proposal.

Page 8:

“White Space Device (WSD)

A device which opportunistically uses some part of white space spectrum.  A white space device can be an access point, base  station, a portable device or similar.  A white space device may  be required by local regulations to query a database with its location to obtain information about available spectrum.”

-          Master Device WSD

-          Slave Device WSD
      A device which uses the spectrum made available by a master device and cannot query the  database  directly.
MSP-> I have updated the definition of Slave Device based on your text above. I have left the definitions as stand-alone definitions rather than placing them under "White Space Device (WSD)" as the definitions are listed alphabetically.

Section 4.1: Page 9

“A complete protocol solution must provide all services that are essential to enable the white space paradigm.  Before a white space device can begin operating it needs to know what channels are available by sending a query to a white space database for a list of available channels, the white space device must first locate or  "discover" a suitable database.”

SD> Suggest changing the last sentence like this: “…., the white space device must have the capability to first locate or discover  a suitable database.”
MSP->I have implemented your proposal.

Section 4.1.2: Page 11

SD> In Figure 2,   Where is the ‘Slave Device’?  Also it may be better just to mention ‘Air IF’  instead of ‘TDD Air IF’.
MSP->There is no slave device since only the Master Device registers with the database. I have removed "TDD" from the figure.

Page 15:

Comment: In some use case it says ‘Dev’ and other use cases it says ‘Slave Dev’. Good to have the consistency.
MSP->I have made changes in 4.2.1 step 6 & 9.

Section 4.2.3: Page 18

“1. The dual mode (or multi mode) device (3G + TVWS) is connected to a 3G network.  The device has contacted a trusted database to discover the list of available TV channels at its current location.  The device has located a TVWS master/AP operating on  an available channel and has associated or connected with the TVWS master/AP.”

SD>  I got the impression from the above text   that ‘The device’ refers to the `Slave  WS Dev’  in Figure 5 and it has contacted  the database.  Am I correct?   If so,  the text  needs to be updated to clarify that the slave cannot contact the database directly.
MSP->I have removed the text describing the slave device contacting the database.

Section 4.2.6:  Page 22:

“7. The slave/user device scans to locate a mobile master transmission, and associates with the mobile master.”

SD> Where is the slave device coming from? There is no ‘Slave device’ in  figure 8?
MSP->I have added a slave device to Figure 8 and clarified in step 6 that master-master communications are possible outside the scope of PAWS.

Section  4.2.7, Page 23:

SD> In Figure 9, there is a connection between Master devices using ‘WS Air IF’ . Does this mean these devices have both ‘Master’ and ‘Slave’ capabilities?  There is no such description and it is hard to understand why this connection is necessary and its intended purpose.
MSP->This capability is described in the first paragraph under 4.2.7. I have clarified in step 6 that master-master communications are possible outside the scope of PAWS.

Section 4.2.8: Page 26:

“7. The slave devices fitted to the machines scan the TV bands to locate the master transmissions, and associate with the master device.”

SD> The above step implies to me that all slave devices are connected to Master but the Figure 10 does not indicate that.
MSP->The first paragraph in 4.2.8 does specify that each slave device is under control of a master device.

Section 5: Page 28:

SD>  In Figure it says ‘WS device’ and it interfaces to the Database directly . OTH, in all use cases the  interface with the database is coming from the ‘Master Device’.  It should be consistent. Suggest changing to ‘Master Device’ or WSD Device (Master)’.
MSP->I have updated Figure 11 to "Master" WS Device.

Section 5.2 : Page 29:

SD> This section seems to be a duplicate since Section 4.1.1 already covers this.
MSP->This section is relevant to the Problem Statement (Chapter 5) and should be kept.

Section 5.4: Page 29:

“Use of XML for specifying a data model is an attractive option.  The intent is to evaluate the best option that meets the need for use between white space devices and databases.”

SD> Suggest adding  XML  as an example
MSP->Examples are nice, however as we are concluding the 2nd WGLC I propose to leave this as written.

Section 6.1: Page 30:

“D.2: The Data Model  MAY  support specifying the regulatory domain and its corresponding data requirements.”

SD> This requirement   should be a ‘MUST’; if not how will the databases interpret it?  Also in P.2 it says “The protocol MUST support determination of regulatory domain governing its current location”.  Unless it is a must, P.2 cannot be satisfied, IMO
MSP->Changed D.2 to MUST.

Page 31:

“D.4:   The Data Model MUST support specifying a manufacturer's serial number for a master device”

SD>  Suggest deleting ` the master device’ at the end.   Since the serial number is also applicable for slave device.
MSP->Changed 'master' to 'white space'

Page 33:

MSP->Merged O.6 and O.7

Section 8: Page 38:

“Threat 8:  Natural disaster resulting in inability to obtain authorization for white space spectrum use by emergency responders”

Last sentence of this section says “ The security requirements arising from the above threats are captured  in the requirements of section 6.1.”

SD> Not sure I understand the threat model  here. Also it seems that the section reference is not correct.
MSP->Section 6.1 is Normative Requirements, and contain the requirements agreed as result of the threat model.

========================

Editorial:
MSP->I have included the editorial corrections.

Abstract 2nd paragraph : Page 1
“This document describes the concept of TV White Spaces.”

>From the above sentence I got the impression that the main focus of this draft is to describe the concept of TV white Space which I believe is not.  May rephrase this or start with the second sentence like: This document describes the use cases and requirements of TV White Space and introduces the problems that need ….”

Section 3.2, Page 8:

“More information about the switch to digital transmission is at : [DTV].”

SD> Delete ‘:’

Page 17:

SD> Typo :  ‘not/no  longer …’

Page 28:

4.  Address regulatory requirements - Each country will likely have …

SD> typo:  ‘likely to have …’

Page 35:

“Threat 1:  …. A white space database may be operated by a commercial entity which restricts
access to authorized users. “

SD> May add ‘only’  after ‘access’;  ‘access to only authorized users.

‘Threat 2: A master device discovers a white space database(s) thru which it can query for channel information.’

SD> Typo: ‘thru/through’

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, June 07, 2012 11:40 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts

Folks,

I cannot send the draft to the IESG without a minimum number of reviews. Ie, if we don’t get reviews, we can’t make progress.

Thanks, Gabor

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, May 15, 2012 5:50 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts

Since there were quite a few changes made to the new version -04, let’s have another WGLC for this document.

Thanks, Gabor

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Probasco Scott (Nokia-CIC/Dallas)
Sent: Friday, May 11, 2012 11:51 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [paws] UC&R document

Hello All,

Kind Regards,
Raj & Scott

Abstract:

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

---

From: <[email-masked]>
Date: Wed, 20 Jun 2012 20:58:40 +0000

Hello Juan Carlos,

Kind Regards,
Scott

From: Juan Zuniga <[email-masked]<mailto:[email-masked]>>
Date: Thu, 14 Jun 2012 17:17:19 -0400
To: Gabor Bajko <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts

Gabor, all,

I have reviewed the document and I think it is in very good shape. These are some minor comments I have:

Abstract

Even though TV bands are currently the primary applications for PAWS, the protocol could be applicable to other bands. Hence, I would suggest removing “TV” from the second paragraph of the Abstract.
MSP->This section has received some changes based on comments from Subir. "TV" is still in the abstract, but in a lower priority. Recall that we had discussion on the email reflector whether to remove 'TV' or not, with the result that many instances were removed, but some remain.

Section 1.1

Multiple examples are provided throughout this section. Some are inside parenthesis, some are preceded by “e.g.” and some are not. I would suggest keeping a common writing style when providing these examples.

Replace “…such as antenna height, and sometimes power.” by “…such as antenna height and power.”
MSP->Agree, made the changes to the section.

Section 1.2.1

Replace “…basic service in TV white space.” by  “…basic service in white spaces.” (or alternatively “…basic service in white space frequencies.”)
MSP->Agree, made the change.

Section 6.1

P.5 and P.6 could be combined into one single requirement with some wording similar to the one used in P.7, e.g. “The messages sent by the master device and database MUST support integrity protection.”
MSP->Agree, combined P.5 and P.5

Section 6.2

I believe there is a preposition missing in O.5: “The master device MUST obtain an indication ‘about’ the regulatory domain governing operation…”
MSP->Agree, made the change.

Regards,

Juan Carlos

Folks,

Thanks, Gabor

Thanks, Gabor

Hello All,

Kind Regards,
Raj & Scott

Abstract:

---

From: <[email-masked]>
Date: Wed, 20 Jun 2012 21:23:02 +0000

Folks,

Thanks for the comments received. The editors will generate a new version of the draft including proposed changes from Subir and JC, and add a new requirement to support pre-configured databases as requested by Peter and Joel (eg, add a new requirement P.x: The address of a database (eg in form of a URI) can be preconfigured in a master device. The master device MUST be able to contact a database using a pre-configured database address.)

If there won't be any additional comments received in the next week or so, we can hopefully send the updated draft to the iesg, then the wg can focus on the solution space.

Regards, Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of Probasco Scott (Nokia-CIC/Dallas)
Sent: Wednesday, June 20, 2012 1:59 PM
To: [email-masked]
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts

Hello Juan Carlos,

Kind Regards,
Scott

Gabor, all,

Abstract

Even though TV bands are currently the primary applications for PAWS, the protocol could be applicable to other bands. Hence, I would suggest removing "TV" from the second paragraph of the Abstract.
MSP->This section has received some changes based on comments from Subir. "TV" is still in the abstract, but in a lower priority. Recall that we had discussion on the email reflector whether to remove 'TV' or not, with the result that many instances were removed, but some remain.

Section 1.1

Multiple examples are provided throughout this section. Some are inside parenthesis, some are preceded by "e.g." and some are not. I would suggest keeping a common writing style when providing these examples.

Replace "...such as antenna height, and sometimes power." by "...such as antenna height and power."
MSP->Agree, made the changes to the section.

Section 1.2.1

Replace "...basic service in TV white space." by  "...basic service in white spaces." (or alternatively "...basic service in white space frequencies.")
MSP->Agree, made the change.

Section 6.1

P.5 and P.6 could be combined into one single requirement with some wording similar to the one used in P.7, e.g. "The messages sent by the master device and database MUST support integrity protection."
MSP->Agree, combined P.5 and P.5

Section 6.2

I believe there is a preposition missing in O.5: "The master device MUST obtain an indication 'about' the regulatory domain governing operation..."
MSP->Agree, made the change.

Regards,

Juan Carlos

Folks,

Thanks, Gabor

Thanks, Gabor

Hello All,

Kind Regards,
Raj & Scott

Abstract:

---

From: "Das, Subir" <[email-masked]>
Date: Thu, 21 Jun 2012 02:57:47 +0000

Hi Scott,
Thanks for addressing the comments.

Regards,
-Subir

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, June 20, 2012 4:56 PM
To: [email-masked]
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts

Hello Subir,

Kind Regards,
Scott

Regards,
-Subir

====================
Technical:

Database

Page 8:

-          Master Device WSD

-          Slave Device WSD

Section 4.1: Page 9

Section 4.1.2: Page 11

Page 15:

Section 4.2.3: Page 18

Section 4.2.6:  Page 22:

Section  4.2.7, Page 23:

Section 4.2.8: Page 26:

Section 5: Page 28:

Section 5.2 : Page 29:

Section 5.4: Page 29:

Section 6.1: Page 30:

Page 31:

Page 33:

Section 8: Page 38:

========================

Editorial:

Section 3.2, Page 8:

SD> Delete ':'

Page 17:

Page 28:

Page 35:

SD> Typo: 'thru/through'

Folks,

Thanks, Gabor

Thanks, Gabor

Hello All,

Kind Regards,
Raj & Scott

Abstract: