Besides, regardless of one's opinion on the coordinating database concept, it is really just a minor part of this draft. The draft goes into quite a bit of detail on an XML schema for device<->WSDB communication. I would hope it gets some agenda time in Paris.
-Pete Nancy Bravin wrote: > All, > > In my opinion, we must address how the rest of the world beside the > USA, UK, FInland etc would need to use a DB(s) and if one or more > countries wants to have an offloading database in its regs for one > reason or another..that is not out of scope, it is under the DB and > regulator control. > It may be a great business opportunity, it may be a way for a country > with a huge population to do things it cannot do now. I think if it is > under the database, and it is something that the regs in China will > ask for, why not listen to a presentation with an open mind. > Maybe one database will be for one set of circumstances, another for > offloading, when needed? or One will be dedicated to more than WSD and > have some proprietary things on it, the other will not? I myself would > like to learn more of the thoughts of having what Zhu Lei is > presenting, and you will be able to ask questions, maybe there will be > a slide deck for examples of how her country is thinking. > > Knowledge is a good thing…let's give it a chance to be heard under the > scope of DB. > > My 2 cents. > > Nancy > > > On Mar 13, 2012, at 7:20 PM, Paul Lambert wrote: > > > > > >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. > > The “coordinating database” is neither a WSD or a WSDB. The > constructive criticism is that this concept is: out-of-scope (IMO), > unnecessary and should be fully removed from the draft and further > discussions on this list. > > Paul > > > Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 > > From: [email protected] [mailto:[email protected]] On Behalf > Of Zuniga, Juan Carlos > Sent: Tuesday, March 13, 2012 6:43 PM > To: [email protected] > Subject: Re: [paws] Time to present my ID in IETF Paris meeting > > 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 > > _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
