Unfortunately we don’t have a reference architecture to work upon, so people 
will make the proposals and comments based on what they understand.

 

We have agreed before to limit the terminology to “WSD <-> WSDB” to keep it 
simple.

 

We know that WSD will be a device and WSDB a server-based service provided by a 
WS Service Provider (most likely not the Regulator).

 

This is a proposal defining a protocol between WSD and WSDB, so I believe it is 
in scope. Perhaps if we wanted to provide constructive feedback to the authors 
we could suggest revising the terminology of their draft.

 

Jc

 

From: [email protected] [mailto:[email protected]] On Behalf Of 
[email protected]
Sent: Tuesday, March 13, 2012 2:06 PM
To: [email protected]; [email protected]
Subject: Re: [paws] Time to present my ID in IETF Paris meeting

 

>Why would the chairs mediate this discussion?

In order to ensure we are not wasting bandwidth on topics that are clearly 
outside the WG scope...
And it is your responsibility to moderate to ensure we are making forward 
progress..
And because you get to wear the blue dot ;)

Sent from my Lumia 800

________________________________

From: Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: 3/13/2012 6:43 PM
To: [email protected]
Subject: Re: [paws] Time to present my ID in IETF Paris meeting

Why would the chairs mediate this discussion? There’s an individual submission 
and the author is seeking comments on the list before the presentation in the 
f2f.

That is how ietf works, we need comments to the list to make progress one way 
or the other.

 

-          Gabor

 

From: [email protected] [mailto:[email protected]] On Behalf Of ext 
Paul Lambert
Sent: Tuesday, March 13, 2012 2:32 PM
To: ZhuLei; [email protected]
Subject: Re: [paws] Time to present my ID in IETF Paris meeting

 

Hi Zhu,

 

> I am not sure that you would support this idea, but the text describing this 
> can make things clearer when talking about this.

 

No I do not support the idea of additional layers of “coordinating database”.  
Especially for detailed designs using HTTPS.

 

> I would not image one database serving huge number of Master devices. For 
> some reasons, regulator 

>may authorize branches to administrate or maintain white space data base which 
>dominates a particular region.

 

Out-of-scope and completely unnecessary.  When you use SSL to access a bank 
account do you care that there may be multiple servers that look like a single 
entity to the user?   New layers of abstraction are not required for 
scalability.  The same protocol can be used to one or multiple servers.  Yes, 
some considerations need to be discussed about authentication.  No new 
entities, layers, architectural blocks, concepts, frameworks or protocols are 
required for “serving a huge number … “.

 

I also see that we waste a lot of words on the list on this topic that may be 
out of scope (up to chair to mediate …).  The purpose of the requirements and 
use case process is to create consensus from the top down to facilitate the 
creation  of a specification of the best possible document from the working 
group.  We should ignore any discussions and contributions on out-of-scope 
contributions and focus on the current scope and work items.

 

Paul

 

 

Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141

 

From: ZhuLei [mailto:[email protected]] 
Sent: Tuesday, March 13, 2012 1:47 AM
To: Paul Lambert; [email protected]
Subject: RE: Time to present my ID in IETF Paris meeting

 

Hi Paul,

 

Do you prefer to remove this intermediary function? The intention of this draft 
is still to provide a proposal of framework and protocol, probably including 
whole picture with essential elements, discovery, query, update etc.

 

As what is mentioned in e-mail list and last F2F meeting, possibly, the PAWS 
might be very extensible since the basic concepts, scenarios and requirements 
are established upon the FCC and other regulators’ process of white space. We 
still have some potential needs doing further at feature level or even 
architecture level. At least, the design of this protocol should make sure this 
need. From this perspective, authentication and content protection might be 
considered further, hopefully, we are able to discuss security in Paris.

 

We also really met vary situations of different areas and regions who dominate 
a quite number of Master devices. I would not image one database serving huge 
number of Master devices. For some reasons, regulator may authorize branches to 
administrate or maintain white space data base which dominates a particular 
region. I do not think the multiple data bases or distributed data model 
framework are controversial to us, but the additional functions of this 
coordinating data base. This intermediate node with white space spectrum 
decision making function is the issue of extensibility, which can be helpful 
when adding some feature which is not desired to main data base. Decision 
making function could be not a functionality of main data base which needs to 
be very stable and static. If we really extent coexistence or interference 
avoidance role to PAWS protocol, it would be easier to extent intermediary 
function without impacts on framework of PAWS, and, structure and protocol of 
PAWS. This node is believed to exist for this purpose.

 

I am not sure that you would support this idea, but the text describing this 
can make things clearer when talking about this.

 

Best regards,

Zhu Lei

 

 

发件人: Paul Lambert [mailto:[email protected]] 
发送时间: 2012年3月13日 15:28
收件人: ZhuLei; [email protected]
主题: RE: Time to present my ID in IETF Paris meeting

 

 

Did our consensus process include a coordinating intermediary function?

 

   The coordinating database can get white space channels from database,

   receive the white space querying message from master device and

   provide the available white space channels for master devices with

   some degree decision making process.  These decision making process 

   might provide functionality of white space access protocol power to

   response available channels according to received device parameters

   (e.g. power, RF parameter), location information(e.g. altitude,

   position and direction of antenna ) and some particular white space

   spectrum decision making policies.

 

Don’t see that this is in scope. Seems inappropriate to create complete IDs 
with features that are out-of-scope.

 

Paul 

 

 

From: [email protected] [mailto:[email protected]] On Behalf Of ZhuLei
Sent: Tuesday, March 13, 2012 12:02 AM
To: [email protected]
Subject: [paws] Time to present my ID in IETF Paris meeting

 

Hi Folks and chairs,

 

As what you might notice, I uploaded a ID on PAWS framework and protocol which 
is to fulfill PAWS requirements and regulators’ requirements, 
“www.ietf.org/id/draft-lei-paws-framework-datamodel-00.txt”.  I would very like 
to request 25 minutes presenting and discussing it during IETF Paris meeting. 

 

Best regards,

Zhu Lei

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

Reply via email to