Joel, while this sounds on the surface like simply greedy, there's a scalability rationale too.
Radio-WAN capacity is about four orders of magnitude less than terrestrial-WAN capacity. Worse, the diff is likely to widen as the limitations on terrestrial-WAN backbones are engineering while the radio-WAN is approaching physics limitations. What you may get is indeed: > device simply say "I will use all of this and the device indeed might use all -- in an inverse multiplex fashion. In keeping with the intent of PAWS we should not impose a value judgment -- the greed may be good or bad. (I'm not sure what the WG should be doing about this; simply an observation at this point). On Thu, 2012-03-08 at 13:16 -0500, Joel M. Halpern wrote: > So why won't the device simply say "I will use all of this?" > After all, that way it needs to do less work with the database. And it > can change frequencies when it wants. > Given that the stated goal of the Ofcom requriement was to be able to > analyze interference effects, it seems that this will not actually lead > to them getting what they want, even if it does comply with the regulations. > > Yours, > joel > > On 3/8/2012 1:09 PM, [email protected] wrote: > > Hi Peter, > > > > Answers below. > > > > Kind Regards, > > Scott > > > > On 3/8/12 11:39 AM, "ext Peter Saint-Andre"<[email protected]> wrote: > > > >> Hi Scott, I have two clarifying questions: > >> > >> 1. Does the device know, when it receives the channel response, which > >> channel it will actually use? > > Scott->This is all new and I am not aware of any existing implementations. > > I would argue that the device must decide what channel(s) it will use when > > it receives the channel response. > >> > >> 2. If the device then uses another channel or a different channel, does > >> it need to report that change to the database? > > Scott->My interpretation of section 3.18 is that the device can only > > transmit within the upper& lower frequencies returned in the > > acknowledgment. I do not (quickly) find any reference in the requirements > > to changing channels. Thus operationally it could be that the channel > > request process must be repeated before the device can use a different > > channel (frequencies). > >> > >> Thanks! > >> > >> Peter > >> > >> On 3/8/12 10:17 AM, [email protected] wrote: > >>> Hi, > >>> > >>> The point from Brian is very relevant: > >>> > >>> Channel request > >>> Channel response > >>> Channel acknowledgement > >>> > >>> What Ofcom does with the information in the acknowledgement does not > >>> matter. As the regulator in UK, they write rules that must be followed > >>> in > >>> order to operate a whitespace radio in the UK. I believe the scope of > >>> the > >>> WG must be focused on a working solution. If this is simple channel > >>> request& response in one regulator's domain, PAWS can support this. If > >>> it > >>> means a channel request, response and acknowledgement in another > >>> regulator's domain, PAWS can support this. As a participating member of > >>> the work group, I believe the scope should be basic working solution, > >>> not > >>> limited to a specific number of messages. > >>> > >>> Kind Regards, > >>> Scott > >>> > >>> > >>> > >>> On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos" > >>> <[email protected]> wrote: > >>> > >>>> Peter, Nancy, > >>>> > >>>> I agree should design a protocol with the best of our current > >>>> knowledge, > >>>> and that should be accounting for all the known regulations at present > >>>> time. We should not limit the scope with the purpose of designing a > >>>> protocol 'faster'. Our goal is not only to design a WSDB protocol. Our > >>>> goal is to design a WSDB protocol that is USEFUL to the community. > >>>> > >>>> The charter does state that > >>>> > >>>> "...the group should also reach out to other potential > >>>> "customers" for a white space database access method and consider input > >>> >from regulatory entities that are involved in the specification of the > >>>> rules for secondary use of spectrum in specific radio bands. " > >>>> > >>>> I think that is exactly what we are doing now. > >>>> > >>>> Regarding whether the types of requirements belong to #1 or #2, I > >>>> believe > >>>> it is more of #1 type, as the information to be exchanged would be > >>>> known > >>>> after the initial query/response. > >>>> > >>>> If we know it today, I see no reason why we should not work on it in > >>>> the > >>>> first phase of the work. > >>>> > >>>> Regards, > >>>> > >>>> Juan Carlos > >>>> > >>>>> -----Original Message----- > >>>>> From: [email protected] [mailto:[email protected]] On Behalf > >>>>> Of > >>>>> Peter Saint-Andre > >>>>> Sent: Thursday, March 08, 2012 11:59 AM > >>>>> To: Nancy Bravin > >>>>> Cc: [email protected]; [email protected]; [email protected]; Pete > >>>>> Resnick > >>>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- > >>>>> rqmts-03: channel reporting > >>>>> > >>>>> Hi Nancy, > >>>>> > >>>>> You are absolutely right that different locales will have different > >>>>> rules and requirements. We need to understand those, and work to > >>>>> address > >>>>> them if possible (although we don't necessarily need to address them > >>>>> all > >>>>> at the same time). I see several kinds of requirements: > >>>>> > >>>>> 1. Some requirements might lead to features beyond the query/response > >>>>> protocol we've envisioned so far. One example might be real-time > >>>>> reporting about the channels that a device is actually using. In my > >>>>> opinion, it would be best to handle those in the next phase of work, > >>>>> because as far as I can see they are outside the scope of our charter. > >>>>> > >>>>> 2. Some requirements might be handled through by defining additional > >>>>> fields that can be included in the query or response. We definitely > >>>>> planned for that when working on the charter with the IESG: > >>>>> > >>>>> In addition, the particular > >>>>> data exchanged between a device and a database might depend on the > >>>>> ranges of radio spectrum that are to be used, the requirements of > >>>>> the > >>>>> database operators and their governing regulations, and other > >>>>> factors. > >>>>> Therefore, the database access method and the query/response data > >>>>> formats that are exchanged using that method need to be designed for > >>>>> extensibility rather than being tied to any specific spectrum, > >>>>> country, or phy/mac/air interface. > >>>>> > >>>>> It's unclear to me right now if the Ofcom requirement fits into #1 or > >>>>> #2, which is why we're having this discussion. :) > >>>>> > >>>>> Peter > >>>>> > >>>>> On 3/7/12 8:17 PM, Nancy Bravin wrote: > >>>>>> Peter and all, > >>>>>> > >>>>>> I agree that it is important to revisit now, so that in the future, > >>>>>> it will be easy to align things in their proper place. Every country > >>>>>> may have different regulations, spectrum, policy and what > >>>>>> responsibility is in the domain of the system, and what comes under > >>>>>> the PAWS charter is important. Maybe some separation might be > >>>>>> possible, and dividing and clarifying issues now will help in the > >>>>>> future. Certainly it seems that the FCC may change some rules, and > >>>>>> we know that Ofcom is not yet finished with their regulations. Canada > >>>>>> has their own, and other countries are working on this as well. Just > >>>>>> a thought...Sharing is a realistic goal...as is off loading... Or you > >>>>>> slim line and every 6 months decide what to incorporate in the > >>>>>> protocol based on new information, new ideas, new innovation new > >>>>>> regulations and maybe spend more time than you could if addressed > >>>>>> now. > >>>>>> > >>>>>> That way you leave the door open and outside of referencing what is > >>>>>> known today, by referencing regulations i.e. Ofcom, FCC, Industry > >>>>>> Canada etc as of XX-XX-XXXX date. Out of scope not something we know > >>>>>> enough about to say at this point, In my opinion. > >>>>>> > >>>>>> My 2 cents.. > >>>>>> > >>>>>> Sincerely, Nancy > >>>>>> > >>>>>> On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote: > >>>>>> > >>>>>>> <hat type='AD'/> > >>>>>>> > >>>>>>> As your responsible Area Director (until March 28, when Pete > >>>>>>> Resnick will take over from me), I have reviewed this thread. > >>>>>>> > >>>>>>> In my opinion (I am happy to be proven wrong), this new requirement > >>>>>>> goes beyond what the charter defined as the scope of this working > >>>>>>> group, which was to enable a device to discover the white space > >>>>>>> available to it in its current location. Reporting usage back to > >>>>>>> the database is simply not mentioned in the charter. > >>>>>>> > >>>>>>> Earlier in this thread, Andy Sago wrote: > >>>>>>> > >>>>>>> There's no language I can find in the charter that explicitly puts > >>>>>>> this out of scope. > >>>>>>> > >>>>>>> An IETF charter defines what the working group shall work on. Many > >>>>>>> interesting features could be developed here. However, it is not > >>>>>>> the job of the charter to mention explicitly that each of those > >>>>>>> interesting features is out of scope. > >>>>>>> > >>>>>>> The charter does say: > >>>>>>> > >>>>>>> Once the device learns of the available white space (e.g., in a TV > >>>>>>> white space implementation, the list of available channels at that > >>>>>>> location), it can then select one of the bands from the list and > >>>>>>> begin to transmit and receive on the selected band. > >>>>>>> > >>>>>>> This text might have assumed that no further communication or > >>>>>>> authorization was required in order to select one of the bands from > >>>>>>> the list and then transmit/receive. Perhaps that assumption was > >>>>>>> mistaken. If so, it would be good to have a discussion about that, > >>>>>>> so we can determine if we need to revisit the assumptions we made > >>>>>>> early on. If in fact we made some faulty or limited assumptions, > >>>>>>> then let's get that out in the open. > >>>>>>> > >>>>>>> Peter > >>>>>>> > >>>>>>> On 3/7/12 9:40 AM, Rosen, Brian wrote: > >>>>>>>> <as individual, at least for now> I'd also suggest that our > >>>>>>>> charter limitation is really support for sharing of whitespace by > >>>>>>>> whitespace devices. Reporting what you use is not sharing, it's > >>>>>>>> just data gathering. > >>>>>>>> > >>>>>>>> The point of excluding sharing was to eliminate the complexities > >>>>>>>> of what constituted fairness, and what kinds of communication > >>>>>>>> might be needed between databases, where more than one could > >>>>>>>> supply available whitespace in a band. This doesn't have any of > >>>>>>>> those issues, As long as it's just sending information, I don't > >>>>>>>> have a problem. Once the database is supposed to do anything > >>>>>>>> with it that involves changing what spectrum it reports, then I > >>>>>>>> think we cross the line. > >>>>>>>> > >>>>>>>> Brian > >>>>>>>> > >>>>>>>> On Mar 6, 2012, at 12:28 PM,<[email protected]> > >>>>>>>> <[email protected]> wrote: > >>>>>>>> > >>>>>>>>> Joel > >>>>>>>>> > >>>>>>>>> Indeed, the regulator has not described the process or provided > >>>>>>>>> a flow diagram, so there may be some wrinkles, but we need to > >>>>>>>>> provide for their intent. To answer your question, the channels > >>>>>>>>> that the master will use are sent in a separate message > >>>>>>>>> (described in P.12 ter), that occurs after the master receives > >>>>>>>>> the response to its channel request, but before the master can > >>>>>>>>> transmit. At this point, it knows what channels are available, > >>>>>>>>> and which one it will use. As far as the slaves are concerned, > >>>>>>>>> as they associate, the master will need to gather their details > >>>>>>>>> and send further channel usage messages to the database on > >>>>>>>>> their behalf. > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> > >>>>>>>>> Andy > >>>>>>>>> > >>>>>>>>> -----Original Message----- From: [email protected] > >>>>>>>>> [mailto:[email protected]] On Behalf Of Joel M. Halpern > >>>>>>>>> Sent: 06 March 2012 17:05 To: [email protected] Cc: > >>>>>>>>> [email protected]; Cheeseman,CJ,Chris,COD R; Dixon,JS,Johnny,COD R > >>>>>>>>> Subject: Re: [paws] WGLC for > >>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel > >>>>>>>>> reporting > >>>>>>>>> > >>>>>>>>> Ahh. I think I see where the request and my understanding > >>>>>>>>> divurge. If the idea here is that the master must provide, in > >>>>>>>>> the request, an indication of what channels it expects to use, > >>>>>>>>> I can at least understand that. I will return to technical > >>>>>>>>> concerns in a moment. > >>>>>>>>> > >>>>>>>>> However, when you say "provide channel usage information, in > >>>>>>>>> order to evaluate interference", what that says to me is > >>>>>>>>> providing, during operation, information as to what channels > >>>>>>>>> are being used, and at what power levels. That is what would > >>>>>>>>> be needed to analyze actual interference effects. And that is > >>>>>>>>> out of scope as I understand our scope. > >>>>>>>>> > >>>>>>>>> I do see a technical difficulty with having the master provide, > >>>>>>>>> as part of either registering or requesting spectrum > >>>>>>>>> information, what channels it intends to use. It doesn;t know > >>>>>>>>> what channels it intends to use. It intends to use some number > >>>>>>>>> of available channels. It will figure out which ones when it > >>>>>>>>> is told what is available. How can it send that information in > >>>>>>>>> the request? > >>>>>>>>> > >>>>>>>>> Yours, Joel > >>>>>>>>> > >>>>>>>>> On 3/6/2012 11:48 AM, [email protected] wrote: > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> There is a similarity here with device ID. In context of PAWS > >>>>>>>>>> we are not concerned with why a device ID is required by a > >>>>>>>>>> regulator, we accept it is a requirement from a regulator and > >>>>>>>>>> include it to the protocol. Ofcom identifies in 3.18& 3.19 > >>>>>>>>>> that channel usage information is required and thus we need > >>>>>>>>>> to include this information. Since the master must provide > >>>>>>>>>> this information prior to transmitting, PAWS will not > >>>>>>>>>> function in the UK without this information and thus I > >>>>>>>>>> believe channel usage information is integral to the channel > >>>>>>>>>> request& response messaging. > >>>>>>>>>> > >>>>>>>>>> Kind Regards, Scott > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 3/6/12 10:30 AM, "ext Joel M. > >>>>>>>>>> Halpern"<[email protected]> wrote: > >>>>>>>>>> > >>>>>>>>>>> I would draw a distinction. Ofcom regulations about > >>>>>>>>>>> whitespace requests are very much relevant. Ofcom > >>>>>>>>>>> regulations about notification of dynamic behavior (which > >>>>>>>>>>> spectrum is being used) are not in scope as I understand > >>>>>>>>>>> the earlier discussions, particularly the chartering > >>>>>>>>>>> discussions. > >>>>>>>>>>> > >>>>>>>>>>> Yours, Joel > >>>>>>>>>>> > >>>>>>>>>>> On 3/6/2012 11:22 AM, [email protected] wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> The ofcom requirements are very much relevant to the > >>>>>>>>>>>> scope of the PAWS WG. The only other regulatory > >>>>>>>>>>>> requirements that we have today is the FCC. Ofcom > >>>>>>>>>>>> requirements are a good addition to the set. > >>>>>>>>>>>> > >>>>>>>>>>>> -Raj > >>>>>>>>>>>> > >>>>>>>>>>>> On 3/6/12 10:03 AM, "ext > >>>>>>>>>>>> [email protected]"<[email protected]> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi Joel > >>>>>>>>>>>>> > >>>>>>>>>>>>> There's no language I can find in the charter that > >>>>>>>>>>>>> explicitly puts this out of scope. On the other hand, > >>>>>>>>>>>>> the charter says that the group will "consider input > >>>>>>>>>>>>> from regulatory entities", and this is one of the > >>>>>>>>>>>>> requirements from Ofcom that they have just published. > >>>>>>>>>>>>> The protocol will be worthless for the UK if it omits > >>>>>>>>>>>>> some requirements. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards > >>>>>>>>>>>>> > >>>>>>>>>>>>> Andy > >>>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- From: Joel M. Halpern > >>>>>>>>>>>>> [mailto:[email protected]] Sent: 06 March 2012 15:53 > >>>>>>>>>>>>> To: Sago,AJ,Andy,COD R Cc: [email protected]; > >>>>>>>>>>>>> [email protected] Subject: Re: [paws] WGLC for > >>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel > >>>>>>>>>>>>> reporting > >>>>>>>>>>>>> > >>>>>>>>>>>>> As I understand, the information you are asking for is > >>>>>>>>>>>>> explicitly out of scope for the working group. Yours, > >>>>>>>>>>>>> Joel > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 3/6/2012 10:42 AM, [email protected] wrote: > >>>>>>>>>>>>>> All > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Comparing the draft with the Ofcom requirements at > >>>>>>>>>>>>>> http://www.cept.org/Documents/se- > >>>>> 43/4161/SE43(12)Info03_Draft-UK-r > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>> egul > >>>>>>>>>>>>>> atory-requirements-for-white-space-devices-in-the-UHF-TV- > >>>>> band, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>> I believe the WG draft is deficient in the area of reporting > >>>>>>>>>>>>>> frequencies and powers actually used by masters and > >>>>>>>>>>>>>> slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom > >>>>>>>>>>>>>> intends to collect this data to assesses the impact > >>>>>>>>>>>>>> of aggregate interference into other services. It > >>>>>>>>>>>>>> would also provide usage information (frequency in > >>>>>>>>>>>>>> use) that would inform the operation of a kill switch > >>>>>>>>>>>>>> capability. I suggest this deficiency can be remedied > >>>>>>>>>>>>>> with the following changes: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> New P requirements (probably best placed following > >>>>>>>>>>>>>> P.12): > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> P.12bis: The protocol MUST support a channel usage > >>>>>>>>>>>>>> message from the slave device to the master device. > >>>>>>>>>>>>>> The channel usage message MUST include parameters as > >>>>>>>>>>>>>> required by local regulatory requirement. These > >>>>>>>>>>>>>> parameters MAY include device ID, manufacturer's > >>>>>>>>>>>>>> serial number, channel usage and power level > >>>>>>>>>>>>>> information. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> P.12ter: The protocol MUST support a channel usage > >>>>>>>>>>>>>> message from the master device to the database. The > >>>>>>>>>>>>>> channel usage message MUST include parameters as > >>>>>>>>>>>>>> required by local regulatory requirement for the > >>>>>>>>>>>>>> master and its associated slaves. These parameters > >>>>>>>>>>>>>> MAY include device ID, manufacturer's serial number, > >>>>>>>>>>>>>> channel usage and power level information. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> P.12qua: The protocol MUST support a channel usage > >>>>>>>>>>>>>> message acknowledgement. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> New O requirements (probably best placed following > >>>>>>>>>>>>>> O13): > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> O.13bis: According to local regulatory policy, after > >>>>>>>>>>>>>> connecting to a master device's radio network a slave > >>>>>>>>>>>>>> device MAY inform the master device of the actual > >>>>>>>>>>>>>> channel usage. The slave MUST include parameters > >>>>>>>>>>>>>> required by local regulatory policy, e.g. device ID, > >>>>>>>>>>>>>> manufacturer's serial number, channel usage and power > >>>>>>>>>>>>>> level information. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> O.13ter: According to local regulatory policy, a > >>>>>>>>>>>>>> master device MAY inform the database of the actual > >>>>>>>>>>>>>> channel usage of the master and its slaves. The > >>>>>>>>>>>>>> master MUST include parameters required by local > >>>>>>>>>>>>>> regulatory policy, e.g. device ID, manufacturer's > >>>>>>>>>>>>>> serial number, channel usage and power level > >>>>>>>>>>>>>> information of the master and its slaves. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> New steps could be introduced into one or more use > >>>>>>>>>>>>>> cases to cover these Ofcom requirements, e.g. new > >>>>>>>>>>>>>> steps 6bis and 9bis in the hotspot use case at > >>>>>>>>>>>>>> 4.2.1: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 6bis. Prior to initiating transmission, if required > >>>>>>>>>>>>>> by local regulation, the master/AP informs the > >>>>>>>>>>>>>> database of the channel and power level it has > >>>>>>>>>>>>>> chosen. This is repeated for each slave that > >>>>>>>>>>>>>> associated with the master. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 9bis. Prior to initiating transmission, if required > >>>>>>>>>>>>>> by local regulation, the slave informs the master/AP > >>>>>>>>>>>>>> of the channel and power level it has chosen, and the > >>>>>>>>>>>>>> master/AP relays this information to the database. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> - end of new text - > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> For information, for those not accessing the url in > >>>>>>>>>>>>>> the first paragraph of this email, the full Ofcom > >>>>>>>>>>>>>> requirements leading to this new PAWS text are as > >>>>>>>>>>>>>> follows: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3.18 After receiving instructions from a WSDB in > >>>>>>>>>>>>>> relation to the maximum permitted EIRPs over the DTT > >>>>>>>>>>>>>> channels, and prior to initiating transmissions > >>>>>>>>>>>>>> within the UHF TV band, a master WSD must communicate > >>>>>>>>>>>>>> to the WSDB the following information: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3.18.1 The lower and upper frequency boundaries^13 of > >>>>>>>>>>>>>> the in-block emissions of the master WSD, and those > >>>>>>>>>>>>>> of the in-block emissions of its associated slaves. A > >>>>>>>>>>>>>> lower frequency will be specified as (470 + 8k + > >>>>>>>>>>>>>> 0.2n) MHz, with the corresponding upper frequency > >>>>>>>>>>>>>> specified as (470 + 8k + 0.2m) MHz, where 0 3Ž4 k 3Ž4 > >>>>>>>>>>>>>> 39, 0 3Ž4 n 3Ž4 39, 1 3Ž4 m 3Ž4 40, and n< m. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3.18.2 The maximum in-block EIRP spectral densities > >>>>>>>>>>>>>> (in dBm/(0.2 MHz)) that the master WSD, and its > >>>>>>>>>>>>>> associated slaves, actually radiate between each > >>>>>>>>>>>>>> reported lower frequency boundary and its > >>>>>>>>>>>>>> corresponding upper frequency boundary. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Footnote 13 states: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The use of upper and lower frequency boundaries > >>>>>>>>>>>>>> (defined over a 200 kHz raster) allows a WSDB to > >>>>>>>>>>>>>> collect more granular information with regards to the > >>>>>>>>>>>>>> usage of the frequency resource by narrowband WSD > >>>>>>>>>>>>>> technologies. The upper and lower frequencies of a > >>>>>>>>>>>>>> boundary pair do not straddle a DTT channel boundary. > >>>>>>>>>>>>>> Note that a WSD may transmit over multiple, > >>>>>>>>>>>>>> non-contiguous, whole DTT channels or fractions of > >>>>>>>>>>>>>> DTT channels. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3.19 A master WSD must be able to receive the > >>>>>>>>>>>>>> following information^14 from a WSDB: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> <snip> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3.19.8 [An acknowledgement from the WSDB, in the > >>>>>>>>>>>>>> context of 3.18, that the reported information on the > >>>>>>>>>>>>>> DTT channels and EIRP spectral densities actually > >>>>>>>>>>>>>> used by the master and slave WSDs were received > >>>>>>>>>>>>>> successfully by the WSDB^18 ]. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Footnote 14 states: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 14 While the communication of some of this > >>>>>>>>>>>>>> information from a WSDB to a master WSD is optional, > >>>>>>>>>>>>>> master WSDs must be able to receive and interpret > >>>>>>>>>>>>>> these. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Footnote 18 states: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 18 This forms part of a handshake protocol and may be > >>>>>>>>>>>>>> an area where industry could harmonise without the > >>>>>>>>>>>>>> need for an explicit requirement in the regulations. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Regards > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Andy > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> *From:*[email protected] > >>>>>>>>>>>>>> [mailto:[email protected]] *On Behalf Of > >>>>>>>>>>>>>> *[email protected] *Sent:* 05 March 2012 19:46 > >>>>>>>>>>>>>> *To:* [email protected] *Subject:* [paws] WGLC for > >>>>>>>>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The authors of the use cases and requirements draft > >>>>>>>>>>>>>> have just posted a new version of the draft and > >>>>>>>>>>>>>> indicated that there are no unresolved > >>>>>>>>>>>>>> comments/issues they are aware of. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Therefore, I'd like to initiate a WG Last Call for > >>>>>>>>>>>>>> comments on > >>>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem- > >>>>> stmt-u > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>> seca > >>>>>>>>>>>>>> ses-rqmts-03.txt > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Please review the draft and send your comments to the > >>>>>>>>>>>>>> list by March 20th, 2012. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> If you review the draft and have no comments, send a > >>>>>>>>>>>>>> note to the list that the draft is good as it is, we > >>>>>>>>>>>>>> need these notes as much as we need the actual > >>>>>>>>>>>>>> comments. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, Gabor > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > > > > _______________________________________________ > > 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
