+1 to all of Joels comments
Why would a third ack message ever be different from the original request? There's been no time to connect clients or make any other interesting choices that would change the way the spectrum would be used. The ack is a useless message and any such informative information about the capabilities or plans of a device to use a range of spectrum should have been carried in the first message. Paul >-----Original Message----- >From: Joel M. Halpern [mailto:[email protected]] >Sent: Friday, March 09, 2012 8:00 AM >To: [email protected] >Cc: Paul Lambert; [email protected]; [email protected]; >[email protected]; [email protected]; >[email protected]; [email protected]; [email protected]; >[email protected]; [email protected]; [email protected] >Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >rqmts-03:channel reporting > >I am having trouble connecting the goal of the requirement, the expected >protocol behavior, and the expected real-world operation. > >Lets keep it simple. A master, connected by wired internet to the >World. A set of slaves who want to use whitespace to talk to the >master. All within a small physical space. All within the the time >limit of whatever answer the master gets from the database. > >The Ofcom requirement is described as being important for understanding >interference effects. Therefore, presumably, it needs to relate to >actual spectrum usage. > >The stated protocol behavior is that the master would reply to the >shitespace database with an ack indicating what it expects to use, at >what power level. >The way folks are writing this, I believe the intention is "respond >once". > >As I understand such master / slave behavior (and I am by no means a >radio expert), the actual usage of spectrum, within the whitespace band, >will depend upon how many slaves are active, and possibly on what they >are doing. > >If the actual usage is going to depend upon the slave device population >/ behavior, then the only answer the master can correctly provide is "I >will use all of the whitespace you have identified, with the highest >power I might use. > >Such an answer is a valid answer in terms of protocol and in terms of >the stated regulatory requirements. However, it is utterly useless in >terms of the stated goal. >As an engineer, I am very uncomfortable designing a protocol messaging >exchange which I know will not meet the end-users needs. > >Note1: If I have mischaracterized ro misunderstood what folks ahve >explained, I apologize. > >Note2: If instead the intention is for the master to update the database >every time it changes the spectrum usage pattern, then this is NOT an >acknowledgment of the reply from the database. It is a dynamic behavior >reporting requirement. > >Yours, >Joel > >On 3/9/2012 6:36 AM, [email protected] wrote: >> Hi >> >> My reading of the UK regulatory requirements that Ofcom has made >available is that the Acknowledgement message that must be communicated >back to the database from the white space device is simply the frequency >range (or ranges) and maximum eirp density that the device intends to >use (a subset of what it would have been offered by the database). I >don't believe there is any intent to limit modulation schemes etc. as >part of this exchange. This seems a relatively straightforward >requirement and the PAWS protocol should accommodate this if it is to be >relevant for the UK regulatory environment. >> >> Regards, >> >> Chris >> >> -----Original Message----- >> From: Paul Lambert [mailto:[email protected]] >> Sent: 09 March 2012 02:15 >> To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos; >[email protected]; [email protected]; >[email protected]; [email protected] >> Cc: [email protected]; [email protected]; Reza Karimi; >Dixon,JS,Johnny,COD R; Cheeseman,CJ,Chris,COD R >> Subject: RE: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >rqmts-03:channel reporting >> >> >> >> >> >> >>> I have a question here. Is it really an acknowledgement or we would >>> like to see a kind of notification message that includes channel, and >>> other parameters? >> >> What if it's multiple channels? What happens if the device adapts and >changes between modulation technique or bandwidth? Does every change >over the air need to be indicated to the GDB? >> >> This Channel acknowledgement does not seem useful and would limit real >world behaviors (like channel and modulation adaptation). >> >> If viewed as a potential regulatory requirement - does this imply we >need to parameterize the protocol to have different behaviors in >different regions? >> >> Paul >> >> >> >>> >>> Regards, >>> _Subir >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf >Of >>> Siew Yoon Tan >>> Sent: Thursday, March 08, 2012 4:06 PM >>> To: Zuniga, Juan Carlos; [email protected]; >>> [email protected]; [email protected]; >>> [email protected] >>> Cc: [email protected]; [email protected]; Reza Karimi; >>> [email protected]; [email protected] >>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>> rqmts-03:channel reporting >>> >>> Dear All, >>> >>> Regarding Ofcom's requirement to have a return channel as part of the >>> protocol between the WSD and WSDB, I would like to confirm to >following >>> sequence of messaging >>> >>> Channel request >>> Channel response >>> Channel acknowledgement >>> >>> which was raised in an earlier email to this list. >>> >>> Our view is that it would be beneficial to define the protocol >between >>> WSD and WSDB that supports this requirement even though how the >>> information could be used is still subject to discussion in the UK. >>> >>> >>> Best regards, >>> >>> Siew Yoon >>> >>> >>> ________________________________________ >>> From: [email protected] [[email protected]] on behalf of >>> Zuniga, Juan Carlos [[email protected]] >>> Sent: 08 March 2012 20:41 >>> To: [email protected]; [email protected]; >>> [email protected]; [email protected] >>> Cc: [email protected]; [email protected]; [email protected]; >>> [email protected] >>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt- >usecases- >>> rqmts-03:channel reporting >>> >>> Hi Raj, >>> >>> I was reusing the language used from Gerald (which I know is familiar >>> to people working on IEEE 802 WS groups): >>> >>>>> [GC] You got it. This would be useless for spectrum regulators. >One >>>>> should realize that, from the spectrum regulator's point of view, >>>>> the second and third messages could be iterated upon to optimize >the >>>>> spectrum use. >>>>> Knowing >>>>> what channels the systems in an area are using, the spectrum >>>>> regulators and/or other entities such as those taking care of >>>>> coexistence could use the database in near-real-time to iterate on >>>>> the two last messages to reduce the range of channels that some >>>>> systems may use once they know precisely what channels are being >>>>> used in the area. The PAWS protocol would carry the information >back >>>>> and forth but would not be involved in such spectrum use >optimization. >>> >>> Having said that, I have no issue sticking to the WSDB terminology. I >>> like keeping things simple :) >>> >>> JC >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] >>>> Sent: Thursday, March 08, 2012 3:33 PM >>>> To: Zuniga, Juan Carlos; [email protected]; >>>> [email protected]; [email protected] >>>> Cc: [email protected]; [email protected]; [email protected]; >>>> [email protected] >>>> Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases- >>>> rqmts-03:channel reporting >>>> >>>> >>>> Hi JC, >>>> >>>> Where/why did the coexistence manager come into the picture? Your >>>> comment about "communicating back to the WSDB/coexistence manager" >>>> may result in further misunderstanding. If we simply stick to to >WSDB >>>> I think we are okay. >>>> >>>> -Raj >>>> >>>> On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos" >>>> <[email protected]> wrote: >>>> >>>>> So, from Gerald and Andy's comments, it seems like from the point >of >>>> view >>>>> of (at least) two regulatory entities it is important for the >>>>> protocol >>>> to >>>>> allow communicating back to the WSDB/coexistence manager the actual >>>>> channel usage after the first query is made. >>>>> >>>>> This is to me a very clear requirement. >>>>> >>>>> The actual messages/IEs that would carry this information should be >>>>> discussed as part of the solution document, and not the >requirements. >>>>> >>>>> JC >>>>> >>>>>> -----Original Message----- >>>>>> From: [email protected] [mailto:[email protected]] On >>>>>> Behalf >>>> Of >>>>>> Gerald Chouinard >>>>>> Sent: Thursday, March 08, 2012 1:59 PM >>>>>> To: 'Joel M. Halpern'; [email protected] >>>>>> Cc: [email protected]; [email protected]; [email protected]; >>>>>> [email protected] >>>>>> Subject: Re: [paws] WGLC for >>>>>> draft-ietf-paws-problem-stmt-usecases- >>>>>> rqmts-03:channel reporting >>>>>> >>>>>> Joel, Scott, >>>>>> >>>>>> Interesting discussion! See my comments in line below. >>>>>> >>>>>> Gerald >>>>>> >>>>>> -----Original Message----- >>>>>> From: [email protected] [mailto:[email protected]] On >>>>>> Behalf >>>> Of >>>>>> Joel >>>>>> M. Halpern >>>>>> Sent: Thursday, 08 March, 2012 13:17 >>>>>> To: [email protected] >>>>>> Cc: [email protected]; [email protected]; [email protected]; >>>>>> [email protected] >>>>>> Subject: Re: [paws] WGLC for >>>>>> draft-ietf-paws-problem-stmt-usecases- >>>>>> rqmts-03: >>>>>> channel reporting >>>>>> >>>>>> So why won't the device simply say "I will use all of this?" >>>>>> [GC] This would defeat the purpose of the acknowledgement message. >>>>>> 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. >>>>>> [GC] You got it. This would be useless for spectrum regulators. >>>>>> One should realize that, from the spectrum regulator's point of >>>>>> view, the >>>> second >>>>>> and >>>>>> third messages could be iterated upon to optimize the spectrum >use. >>>>>> Knowing >>>>>> what channels the systems in an area are using, the spectrum >>>> regulators >>>>>> and/or other entities such as those taking care of coexistence >>>>>> could use the database in near-real-time to iterate on the two >>>>>> last messages to reduce the range of channels that some systems >>>>>> may use once they know precisely what channels are being used in >the area. >>>>>> The PAWS protocol would carry >>>> the >>>>>> information back and forth but would not be involved in such >>>> spectrum >>>>>> use >>>>>> optimization. >>>>>> >>>>>> 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. >>>>>> [GC] Agree with Scott but this is only a portion of the >>>> considerations. >>>>>> If a >>>>>> device was to operate on its own, this would be true but a >>>>>> communication device usually implies at least 2 devices to >>>>>> communicate. Hence, the choice of the channel to be used will need >>>>>> to be negotiated between the two devices before a choice can be >>>>>> made. The chosen channel will belong to the >>>> set >>>>>> of >>>>>> available channels that is common to both devices. Remember that >>>> some >>>>>> channels may be available at one device and not at the other >>>>>> because >>>> of >>>>>> their geolocation or other reason. Extending this concept to a >>>>>> star network topology, the channel that will be selected by this >>>>>> network will >>>> have >>>>>> to >>>>>> belong to the set of channels that are available to all devices. >>>> Each >>>>>> device >>>>>> will not be able to decide by itself which channel it wants to >use. >>>>>> >>>>>> This is why in such a star topology, it makes sense that the slave >>>>>> devices to a base station or access point be represented by the >>>>>> base station acting as the master on their behalf to query the >>>>>> database and receive the list of available channels (and/or >>>>>> maximum EIRP per channel). It is then the responsibility of the >>>>>> base station to identify the set of available channels that is >>>>>> common for itself and all its slaves to decide on the >>>> channel >>>>>> that >>>>>> the network will use. As you can see, in this case, there is no >>>>>> need for each slave to receive its list of available channels. On >>>>>> its own, it would not know what to do with it. The only thing that >>>>>> needs to be sent >>>> from >>>>>> the >>>>>> master device to its slaves is the resulting operating channel. >>>>>> >>>>>> I a more sophisticated operation, the master device may add one or >>>>>> a few backup channels extracted from the common set of available >>>>>> channel >>>> to >>>>>> the >>>>>> message going to its slave so that if a change in channel >>>> availability >>>>>> occurs, an instantaneous switch to the next backup channel can be >>>> made >>>>>> without any further signaling, thus providing for a channel switch >>>> that >>>>>> is >>>>>> transparent to the user. It is the scheme that has been included >>>>>> in >>>> the >>>>>> IEEE >>>>>> 802.22-2011 Standard. This is why I don't believe that PAWS should >>>> get >>>>>> involved in defining this signaling between the base station and >>>>>> its slaves devices. >>>>>>>> >>>>>>>> 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). >>>>>> [GC] If the process involves 2 messages, then, the device and its >>>>>> associated devices could change channels at will as long as all >>>>>> these channels belong to the set of available channel. However, if >>>>>> the third message is added, it would make sense that the master >>>>>> device reports to the database any channel change that would occur >>>>>> to the database, otherwise, the status of >>>> the >>>>>> spectrum occupation would be wrong at any moment and would be >>>> useless >>>>>> for >>>>>> the purpose of any spectrum usage optimization such as >coexistence. >>>>>>>> >>>>>>>> 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 >>>>> _______________________________________________ >>>>> paws mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/paws >>> >>> _______________________________________________ >>> paws mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/paws >>> >>> ________________________________ >>> >>> >*********************************************************************** >>> * >>> ****************************************** >>> For more information visit www.ofcom.org.uk >>> >>> This email (and any attachments) is confidential and intended for the >>> use of the addressee only. >>> >>> If you have received this email in error please notify the originator >>> of the message and delete it from your system. >>> >>> This email has been scanned for viruses. However, you open any >>> attachments at your own risk. >>> >>> Any views expressed in this message are those of the individual >sender >>> and do not represent the views or opinions of Ofcom unless expressly >>> stated otherwise. >>> >*********************************************************************** >>> * >>> ****************************************** >>> _______________________________________________ >>> 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
