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

From: <[email-masked]>
Date: Wed, 16 May 2012 00:49:51 +0000

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]] 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.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: Peter Stanforth <[email-masked]>
Date: Wed, 16 May 2012 15:32:41 -0400

Gabor,
The latest version has updates that seem inconsistent and I do not see how to comply with current FCC rules based on the modification.

The following operational requirement appears to enable both FCC and Ofcom approaches :

O.3 The master device MUST identify a database to which it will register, make channel requests, etc... The master device MAY
select a database for service by discovery at runtime or the master device MAY select a database for service by means of a
pre-programmed URI address.

However in the requirements it seems that the ability to support the FCC model has been removed. Specifically:
It appears that the data model requirements that supported hardcoded URI addresses for WSDBs have been removed

D.2       The Data Model MUST support specifying the URI address of a white space database.
D.3       The Data Model MUST support specifying the URI address of a national listing service.

In addition changes have been made to  the discovery requirement (P.1), and the direct access (P.2) has been removed.
Which is how I get to the concern that I can no longer support the FCC rule that requires a specific relationship between a radio and DB (or DBs)

As a minor editorial comment. The preamble and some of the descriptive text is a little dated. For instance the FCC has issued a 3rd Report and Order since this was originally written.
Regards,
Peter S.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[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]] 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:

---

From: <[email-masked]>
Date: Thu, 17 May 2012 16:01:28 +0000

Hi Peter,
See my answers inline:

From: ext Peter Stanforth [mailto:[email-masked]]
Sent: Wednesday, May 16, 2012 12:33 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley); [email-masked]
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts

Gabor,

However in the requirements it seems that the ability to support the FCC model has been removed. Specifically:
It appears that the data model requirements that supported hardcoded URI addresses for WSDBs have been removed
<GB> pre-configuration is always possible. We don't need a separate requirement for it.

D.2       The Data Model MUST support specifying the URI address of a white space database.
<GB> after the discovery process, which results in the master device learning the URI of the DB (which can be pre-configured in some environments), the protocol itself is going to need that URI, not the data model. The above D.2 suggested me that the URI would be included in the channel request and channel response data itself, which I don't think is necessary.
D.3       The Data Model MUST support specifying the URI address of a national listing service.
<GB> same as above.

In addition changes have been made to  the discovery requirement (P.1), and the direct access (P.2) has been removed.
<GB> P.1 and P.2 have been combined. The  requirement to have direct access to an entity is redundant with the basic operating principle of the internet, so that redundant sentence was removed.
Which is how I get to the concern that I can no longer support the FCC rule that requires a specific relationship between a radio and DB (or DBs)
<GB> Pre-configuration is always possible, we do not need an explicit requirement for it. Involving the discovery process is only necessary when one needs to find the entity it wants to talk to. If that is preconfigured, then the client skips the discovery and contacts directly the entity.
Are you suggesting that including the DB URI into the channel request/response is a requirement of FCC? If not, then I do not see how the above changes affect the FCC operation.

Thanks, Gabor

Hello All,

Kind Regards,
Raj & Scott

Abstract:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 17 May 2012 13:16:31 -0400

I beg to differ slightly.
While preconfiguration is always possible, if we leave out the 
requirement to support it, then we are likely to also leave such 
configuration capabilities out of management models, etc.  If it is 
"always possible" then including it in the requirements seems inexpensive.

Yours,
Joel

On 5/17/2012 12:01 PM, [email-masked] wrote:
> O.3 The master device MUST identify a database to which it will
> register, make channel requests, etc... The master device MAY
>
> select a database for service by discovery at runtime *or the master
> device MAY select a database for service by means of a*
>
> *pre-programmed URI address.*
>
> <GB> pre-configuration is always possible. We don’t need a separate
> requirement for it.
>

---

From: <[email-masked]>
Date: Wed, 23 May 2012 21:39:23 +0000

Sure. Adding (or putting back) a requirement on pre-configuration shouldn't be a problem. We'll work out a requirement which all of us is going to be happy with.

In the meantime, I would like to ask more people to review the draft and send comments to the list. As I mentioned in my previous mail, 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

-----Original Message-----
From: ext Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, May 17, 2012 10:17 AM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]; [email-masked]
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts

I beg to differ slightly.
While preconfiguration is always possible, if we leave out the requirement to support it, then we are likely to also leave such configuration capabilities out of management models, etc.  If it is "always possible" then including it in the requirements seems inexpensive.

Yours,
Joel

On 5/17/2012 12:01 PM, [email-masked] wrote:
> However in the requirements it seems that the ability to support the 
> FCC model has been removed. Specifically:
>
> It appears that the data model requirements that supported hardcoded 
> URI addresses for WSDBs have been removed
>

---

From: Nancy Bravin <[email-masked]>
Date: Thu, 24 May 2012 04:16:10 -0400

Hi Gabor, Scott, and Raj, 

Has there been a comparison with the 3rd R & O as suggested earlier that affects the Draft and should be addressed now before
we submit and discussion there of?
I am not sure why things are so quiet, but it seems that would be a timely thing to do now.

Sincerely, Nancy

On May 23, 2012, at 5:39 PM, <[email-masked]> <[email-masked]> wrote:

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

---

From: Peter Stanforth <[email-masked]>
Date: Thu, 24 May 2012 10:59:26 -0400

Thanks for reminding me. We should also look at the latest Ofcom
publication that has a lot of discussion on master/slave requirements

On ThuMay/24/12 Thu May 24, 4:16 AM, "Nancy Bravin"
<[email-masked]> wrote:

>Has there been a comparison with the 3rd R & O as suggested earlier that
>affects the Draft and should be addressed now before
>> Sure. Adding (or putting back) a requirement on pre-configuration
>>shouldn't be a problem. We'll work out a requirement which all of us is
>>going to be happy with.
>> 
>> In the meantime, I would like to ask more people to review the draft
>>and send comments to the list. As I mentioned in my previous mail, 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
>> 
>> 
>> Subject: Re: [paws] 2nd WGLC for
>>draft-ietf-paws-problem-stmt-usecases-rqmts
>>

---

From: <[email-masked]>
Date: Thu, 24 May 2012 16:35:33 +0100

All

There was a new draft from Ofcom last Thursday on the parameters to be exchanged between WSDs and a database, which is attached for reference.

Regards

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Stanforth
Sent: 24 May 2012 15:59
To: Nancy Bravin; Gabor Bajko; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts

Thanks for reminding me. We should also look at the latest Ofcom publication that has a lot of discussion on master/slave requirements

On ThuMay/24/12 Thu May 24, 4:16 AM, "Nancy Bravin"
<[email-masked]> wrote:

>Has there been a comparison with the 3rd R & O as suggested earlier 
>that affects the Draft and should be addressed now before we submit and 
>discussion there of?
>>shouldn't be a problem. We'll work out a requirement which all of us 
>>is going to be happy with.
>> 
>>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: Nancy Bravin <[email-masked]>
Date: Fri, 25 May 2012 12:14:22 -0400

HI Andy, Peter, Gabor and all

Thanks for including the draft. My issue is to be as relevant and up to date as possible when we approach the IESG, and that includes possible
adjustments to the PAWS draft. So to you and others, how to change the wording, to be inclusive of the FCC, Ofcom, Canada, or any other country's
regulations by being general in the protocol statement, but also specific to those rules that differ in the FCC or OFcom, or some new
country that wants to do things in a different way by using a "MUST" be required if specified by local regulations ?
Yes, I want my cake and be able to eat it too…But I may not be thinking of this is the appropriate manner as far as the members
are concerned. I hope that others can join the conversation and not merely abstain involving themselves at this point publicly.
We need to have statements of support or lack of support with reasons for either, offer changes, when needed, support for what is 
OK at this point and then to get the information to Garbor, who needs and has asked for it.
And by looking at the new rules in the 3rd R & O from the FCC, and the draft attached, what issues have changed that require being addressed?
Thoughts anyone???

Sincerely,

On May 24, 2012, at 11:35 AM, <[email-masked]> <[email-masked]> wrote:

> <Ofcom WSD regulatory requirements 20120517 (Clean).pdf>