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
