John, all >From a business strategy point of view it allows for more innovation with the >ability to have more things in scope of the DB's, the management of, and its >parts as described below. It seems to broaden the horizon of what will be possible into a sensible path. No longer will coexistence be out of scope, or the many possible uses that one can only dream of at this moment that a DB group can do, or the many different uses that could be used in whitespace.
My 2 cents.. SIncerely, Nancy On Feb 24, 2012, at 2:37 PM, Stine, John A. wrote: > I wrote previously about the goodness of dividing data models into at least > two halves, the data that describes the spectrum use and the data that is > necessary for the business processes of resolving what spectrum a device may > use. On further thought, I believe we should divide the data into three > parts, the data required for messaging and trust, the particular > administrative data required by a regulatory domain, and the data defining > the spectrum. The purpose of separating these data models is to allow growth > of the whitespace concept. > > The motivation for separating out the messaging data is to allow the > messaging data to be very broadly applied to all types of whitespace > management for all regulatory domains. This part of the standard would be > expanded as new capabilities are added. > > The purpose for separating out the administrative data is to allow each > regulatory domain to specify and to modify their data requirements without > having international ramifications. We may want this data model to convey > particular regulatory requirements obtaining and keeping authorization to use > channels. > > The purpose for separating out the spectrum data is to make it independent of > any particular business processes. This is very important for expansion > where the spectrum data model is used to trade spectrum, arbitrate > coexistence, or give policy to cognitive radios. The spectrum models may be > changed in whole based on whether and how spectrum coexistence is managed. > > Using the requirements sent out earlier this week in > > http://www.ietf.org/mail-archive/web/paws/current/msg00775.html > > this is my take on how the requirements would affect the different data > models. > > The data requirements D2, D3, and D4 would be part of the messaging data > model. The data requirements D5, D6, and D8 would be part of the > administrative data. The data requirements D1, D7, D9, and D10 would be part > of the spectrum use model. > > The data elements implied by the protocol requirements, P1, P2, P3, P4, P5, > P6, P7, P8, P9, P11, P15, P16, and P18 would be included in the messaging > data model. The data implied by the protocol requirement P12 (less > location), P14 (less location), P17, and P19 would be included in the > administration data models. The data implied by the protocol requirements > p13, P19, and P20 would be included in the spectrum data model. Location > would be defined in the spectrum data model. > > The data implied by the operational requirements O1, O2, O4, O5, and O20, > would be part of the messaging data model. The data implied by the > operational requirements O6, O7, O10, O11, O12, O13 (the response code), O14, > O15, O16, O17, O18 (less location), O19 (less location) and O22 would be part > of the administration data model. The data implied by the operational > requirements O2, O8, O9, O11, O13 (the channel list) and O21 would be part of > the spectrum data model. > > To clarify the use of three data models I would make changes to the > requirements. > > Data Requirements > > <Add> > > "D11: The Data Model MUST be subdivided into three parts, messaging, > administration, and spectrum. There shall be one schema for the messaging > part. There may be multiple schemas for the administration and spectrum > parts differentiated by regulatory domain." > > I would modify all the data requirements, less D2, D3, and D4, to explicitly > state "as required by the regulatory domain." Also some data requirements > might be softened and listed as examples, for example in D1, I doubt that the > North American Datum of 1983 would be relevant to European administrations. > > Protocol Requirements > > In general, I would add to the requirements an explicit mention of the > different data schemas and would specify messaging to resolve the schemas > that are used. > > Possibly before P3, I would add the requirement: > > P.X The protocol MUST support the use of multiple administrative and > spectrum data models. > > And, then extend P.3 as follows: > > P.3 The protocol MUST support determination of the regulatory domain > governing its current location and the administration and spectrum data > models that are to be used. > > Other protocol requirements may be softened to acknowledge that requirements > vary by regulatory domain. > > There would likely be some additional changes in the operational requirements > but before I suggest any I would prefer to get some feedback. If this is > acceptable, I would be glad to prepare a revised list of requirements with > the tweaks to support the separate data models and differentiation by > regulatory domain. > > John Stine > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
