Hi John, Rather than stating that the data model MUST be modular or the protocol MUST support determination of which administrative and spectrum specific modules are used, I would propose these to be included as guidelines to be used in the design of the data model and protocol. In addition to having a set of requirements, we could add guidelines as well to abet the solutions.
-Raj On 2/28/12 12:02 PM, "ext Stine, John A." <[email protected]> wrote: >How about this > >D.X The data model MUST provide a modular design separating out >messaging specific, administrative specific, and spectrum specific parts >into separate modules. > >P.X The protocol MUST support determination of which administrative >specific and spectrum specific modules are used. > >This is very specific and it is NOT requiring any increase in scope. > >John > >-----Original Message----- >From: [email protected] [mailto:[email protected]] >Sent: Tuesday, February 28, 2012 12:45 PM >To: [email protected]; Stine, John A.; [email protected] >Cc: [email protected] >Subject: Re: [paws] Further explanation of partitioned data models > >Inline: > >On 2/27/12 10:41 PM, "ext [email protected]" ><[email protected]> wrote: > >>Hi, >> >>As a way forward, how about two additional requirements >> >>D.X The Data Model MUST be extensible. >> >>P.X The protocol MUST be extensible. >> >>This captures the desire to extend both the Data Model and the protocol >>in >>the future, without identifying a specific solution at this time. > >The above requirements are overly broad and tends to result in protocol >bloat. >Extensibility is something to be kept in mind with the cognizance that the >WS technology will evolve but I would refrain from adding the above >requirements to the I-D. > >-Raj > >> >>Kind Regards, >>Scott >> >> >> >> >>On 2/27/12 4:47 PM, "ext Stine, John A." <[email protected]> wrote: >> >>>Brian, >>> >>> I want to make it very clear that I am not advocating that in this go >>>around that you add anything that increase the scope toward managing >>>coexistence or adding spectrum to the database. I used those as >>>examples >>>of future upgrades. I am just making recommendations that you don't do >>>something now that makes it more difficult to do something different in >>>the future. >>> >>> I agree with your personal comment that most of your messaging would >>>remain the same. However, I do not believe the administrative (i.e., >>>regulatory )data and spectrum use data that you will come up with for TV >>>whitespace will be rich enough to account for the many ways of sharing >>>spectrum in the future and the coordination that must take place. >>>Trying >>>to make it so now will cause the very problem you are objecting to. It >>>will complicate this first effort. Proceeding on the assumption that it >>>can be upgraded easily, I believe, will be the original sin of PAWS and >>>make upgrade very difficult. The first iteration of PAWS will affect >>>other standards and those standards will serve as inertia to upgrades. >>>Creating a PAWS standard that allows for the use of different data >>>models >>>simply keeps this from being a problem. The legacy data model can be >>>used with the legacy standard. A new data model can be used with a new >>>standard or a different band or different regulations. >>> >>> Consider this problem. In future upgrades, if coexistence were ever >>>managed, how would the different database administrators collaborate in >>>defining the boundaries between the TVWS users? Right now it is going >>>to >>>be the wild west. Short range unlicensed is a different problem than >>>long range unlicensed. With the larger spaces of the TVWS frequencies >>>there will be greater potential for overlap of users and so interference >>>among users. >>> >>>John >>> >>>-----Original Message----- >>>From: Rosen, Brian [mailto:[email protected]] >>>Sent: Monday, February 27, 2012 4:36 PM >>>To: Stine, John A. >>>Cc: [email protected] >>>Subject: Re: [paws] Further explanation of partitioned data models >>> >>><As chair> >>>Discussions of spectrum coexistence is explicitly out of scope, and we >>>have a big enough job to do without increasing scope. >>>The scope is also limited to the problem of a device requesting >>>spectrum, >>>and discussions of provisioning ("releasing new spectrum") is out of >>>scope. Only the device-to-database query and its response is in scope. >>> >>><as individual> >>>If we ever get to coexistence work, the additional messaging is some >>>form >>>of <DB to device>"use this explicit spectrum, I'm suggesting that you >>>use >>>it, even if you could use other spectrum" or <device to db>"of the >>>choices you gave me, I'll use this part, and please try and keep other >>>users out of my way". Either is a simple expansion of the basic query >>>(location and band in, spectrum choices out). As such, I don't think we >>>have to do anything in anticipation of such a future capability. >>> >>>I do think the notion of authentication of the device and the database >>>is >>>in scope, and I certainly think exchange of credentials or equivalent >>>precedes spectrum query, so I suspect we're separating that part anyway. >>>I certainly think we're trying to return spectrum choices that depend on >>>location, device characteristics and things like time of day, and we're >>>trying to design a protocol that will work for any country that decides >>>to open spectrum for whitespace use and on any band they decide to do >>>so. >>> So long as we have enough data elements in the query to allow any of >>>the >>>algorithms that the regulators decide on to determine the available >>>spectrum from the input query and provisioning information in the >>>database, as well as have sufficient flexibility in the response of >>>available spectrum to cover all the limits the regulators want to have, >>>we should be okay. So far, I don't see any problems staying within the >>>model we have been talking about. >>> >>>Brian >>> >>>On Feb 27, 2012, at 4:13 PM, Stine, John A. wrote: >>> >>>> From the lack of response to my email last week, I assume folks just >>>>don't understand why I am recommending the division of the data model. >>>>Please let me explain in a different way. >>>> >>>> Last December, at the SDR Forum, Julius Knapp, the Director of the OET >>>>at the FCC, hosted a panel attended by five of the ten database >>>>administrators. In that panel, he asked the panelists what was in it >>>>for them. Several responded that they hoped they could provide a >>>>service to those looking for spectrum and to help broker these >>>>arrangements. >>>> >>>> This is not the model of TVWS. At present, the urgency of the paws >>>>effort surrounds a narrower goal of enabling TVWS devices to obtain >>>>channels they can use. I do not want to make any suggestions that >>>>would >>>>prevent us from achieving this goal first. I do want to make an effort >>>>to prevent what is done from becoming an impediment to a bigger role >>>>for >>>>whitespace database administration in the future, one of managing >>>>coexistence and brokering spectrum reuse. >>>> >>>> In all methods of using a database where a device negotiates with a >>>>database, the types of messages that will be used are likely to be >>>>similar: >>>> - This is who I am, what rules should I apply in negotiating for >>>>spectrum? >>>> - This is the spectrum I am looking for, what do you have? >>>> - This is the spectrum that meets your query criteria. >>>> - etc. >>>> The methods developed for trust are also reusable. This is the reason >>>>for having a portion of the data model remain the same for all >>>>expansions. >>>> >>>> The differences between a TVWS scenario and a brokering scenario are >>>>likely to be additional messaging and different data, both for the >>>>business of brokering and for defining the spectrum authorization. For >>>>example, in the brokering use case there needs to be a spectrum data >>>>model that allows a primary spectrum user to release spectrum into the >>>>market, (e.g., provide their contours ) and to specify the terms of >>>>use. >>>> My concern is that if the data model of TVWS comingles the data of >>>>messaging, administration, and spectrum; that this sort of expansion of >>>>paws would require increasing the size of the data model and would make >>>>expanding its capability more difficult both because of the impact of >>>>this expansion on legacy uses and because of the confusion of using >>>>large schemas that have similar but different data elements. >>>> >>>> My solution is to divide the data model into three parts. The data >>>>document of messages would use the namespace of three schemas. In the >>>>TVWS edition, this would also allow different administrative and >>>>spectrum schemas for different regulatory domains. In end, the data >>>>for >>>>TVWS management would not be any different, it would just be defined in >>>>three schemas >>>> >>>> In the initial exchanges between a device and a database, there would >>>>be agreement on which schemas to use. This is equivalent to resolving >>>>the regulatory domain. The messaging that follows would be the exact >>>>same, with the exact same data as the messaging if a comingled data >>>>model were used. >>>> >>>> If the division is done well, then, in the long term, others can >>>>create >>>>schemas for administration and spectrum definition that meets their >>>>business needs without having to do so through paws. They would be >>>>able >>>>expand the way the paws protocol is used without having to revise paws. >>>> >>>> I hope this better explains my intent. It would also be helpful to >>>>understand why anyone thinks this should not be done. >>>> >>>> John >>>> _______________________________________________ >>>> paws mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/paws >>> >>>_______________________________________________ >>>paws mailing list >>>[email protected] >>>https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
