Thanks, Nancy, why have we not submitted option 2 months ago
Just for reference, this topic surfaced as early as August 25 in this thread: http://www.ietf.org/mail-archive/web/paws/current/msg01607.html In fact, is was agreed at the prior F2F meeting that option 2 was the more general (and preferable) encoding. Best regards, Andy Lee | Google Inc. | [email protected] | 408-230-0522 On Fri, Nov 1, 2013 at 3:10 PM, Nancy Bravin <[email protected]> wrote: > Sorry, meant to send to Andy, Gabor and the group as well. > > On Nov 1, 2013, at 3:02 PM, Nancy Bravin <[email protected]> wrote: > > I have a couple of concerns. > 1. why have we not submitted option 2 months ago > 2. In that we have the ability to revise every 6 months which is not > something most other SDO’s can do, there is no reason to try and > have other things in there in one FINAL and ONLY PAWS protocol which I > seem to be seeing some want to do and therefore add things now > when in fact, we can adapt easily and make changes, work with other > groups, and keep up to date with the different requirements likely to > change. > > Sincerely, Nancy > On Nov 1, 2013, at 2:45 PM, Peter Stanforth <[email protected]> > wrote: > > With all due respect you are not listing to what I am saying. > 1 I agree that providing more flexible API and more information is what we > should aim for with PAWS. > 2 You were implying, incorrectly, that the current V6 PAWS protocol could > not support the FCC rules, It can and does. We have implemented this > protocol. I am not sure why that is ‘proprietary'. > 3 my only issue is that this is not fully thought out and we also need to > get a PAWS protocol out the door. So I am trying to put this capability > into a future iteration so we can do it justice. > > > From: Andy Lee <[email protected]> > Date: Friday, November 1, 2013 at 4:46 PM > To: Peter Stanforth <[email protected]> > Cc: "[email protected]" <[email protected]>, Protocol to Access > White Space database <[email protected]> > Subject: Re: [paws] Question: Encode slopes? > > Most (perhaps all) of the device and database certifications that have > been completed thus far have used proprietary interfaces. They have not > relied on a *draft* PAWS specification. And there are other certified > devices which do get more than just a channel list. > > We're not aiming for the least common denominator here. There are many > use cases that could take advantage of this information. Just because > there is one implementation that doesn't use this feature, that doesn't > mean the protocol shouldn't support it. The FCC's testing rules clearly > indicate that it is OK for a device to rely on information from the > database to meet compliance. Just because one company decides not to make > use of this capability does not mean that others will come to the same > conclusion. And the PAWS protocol should accommodate both. > > The protocol is already not about "channels", which is a good thing, since > this is picking up steam internationally. There is also substantial work > being done in other bands that are leaning towards spectrum databases and > PAWS. Some of these other bands have no concept of channels at all. > > What's the justification for the old, less capable encoding? The old > encoding does not follow any of the common practices used in the radio > device industries. I think we should strongly consider following the lead > of IEEE 802.11 and other technologies that will be the most likely users of > white space. > > > Andy Lee | Google Inc. | [email protected] | 408-230-0522 > > > On Fri, Nov 1, 2013 at 1:24 PM, Peter Stanforth <[email protected]> > wrote: > >> The FCC does not require the DB to provide any mask information. That can >> be validated by the 5 certified radios that are not getting anything but a >> channel list from a certified database. >> I am still not convinced that, under current FCC rules, they will accept >> anything but a channel list. I don’t think they will object to a DB >> providing such information but they certainly do not require it. >> >> From: Andy Lee <[email protected]> >> Date: Friday, November 1, 2013 at 4:17 PM >> To: "[email protected]" <[email protected]> >> Cc: Peter Stanforth <[email protected]>, Protocol to Access White >> Space database <[email protected]> >> >> Subject: Re: [paws] Question: Encode slopes? >> >> What and how to encode is already defined in the FCC rules (the values >> have been referenced in previous messages). The values are explicitly >> given to us, and we just need a way to include it in a PAWS message. >> >> The current encoding does not support the encoding of those values >> (including slopes). A new encoding has been proposed that does support the >> FCC parameters. >> >> What is the justification for sticking with the less capable encoding? >> The old encoding is incapable of supporting a use case that's been >> identified in the current rules. >> >> >> Andy Lee | Google Inc. | [email protected] | 408-230-0522 >> >> >> On Fri, Nov 1, 2013 at 7:50 AM, <[email protected]> wrote: >> >>> Even if things are hard coded in firmware, an update to firmware could >>> bring the product up-to-date with the changed rules. Of course, it might be >>> more flexible to have that info delivered over paws, but the discussions on >>> this list do not indicate any consensus on what and how to encode. >>> Most people resist to changing the current encoding in draft -06. Since >>> we were not able to conclude this discussion in time and submit a revised >>> version of the document before the deadline, we can keep continue >>> discussing this encoding issue for a few more days, but I’d like to >>> conclude it by the F2F. So far, no conclusion in changing the current >>> encoding, and unless a miracle happens in the next few days, this will be >>> the conclusion, as we need to move forward. >>> There will be a separate discussion sometime in the future on whether to >>> create a paws version 2, and if yes, then what should be included in there. >>> But before that discussion happens we need to get the current protocol out >>> of the door. >>> -Gabor >>> >>> >>> *From:*[email protected] [mailto:[email protected]] *On Behalf >>> Of *ext Andy Lee >>> *Sent:* Tuesday, October 29, 2013 1:51 PM >>> *To:* Peter Stanforth >>> *Cc:* [email protected] >>> >>> *Subject:* Re: [paws] Question: Encode slopes? >>> >>> >>> Hi Peter, >>> >>> I think that channels 36 and 38 were merely being offered as examples, >>> hence the "e.g.". Perhaps it's a matter of interpretation, but it seems >>> pretty clear to me that the purpose of this note is to allow the device >>> under test (DUT) to use information from the database to meet compliance >>> requirements, if it so chooses. It is not forced to have those constraints >>> hard-coded in the firmware. >>> >>> This leaves open the possibility for the FCC to change, add, or remove >>> the constrains around channel 37 in the future. If a device chooses to >>> have hard-coded constraints in their firmware, they may end up missing out >>> on some spectrum opportunities that might be permitted in future rule >>> modifications. >>> >>> Best regards, >>> >>> >>> Andy Lee | >>> Google Inc. | >>> [email protected] | >>> 408-230-0522 >>> >>> >>> On Tue, Oct 29, 2013 at 1:33 PM, Peter Stanforth < >>> [email protected]> wrote: >>> The note you reference in the test procedure is ambiguous, there is no >>> reference to channels 36-38 in part two and no mention of tests to lock out >>> unauthorized channels, or a definition of what that really means. So I can >>> only base our interpretation on what we have been required to do to pass >>> WSD certification. The FCC being the final judge of that. The way we have >>> been required (By we I mean the DUT) to operate it that the DUT cannot have >>> it’s compliance overridden by the database. A specific example. A DUT was >>> having trouble complying with the channel 37 requirement and the >>> manufacturer made the decision to block any use of channels around it in >>> the firmware – to get a product out and allow them to rework the RF later. >>> A test was required to prove that if the database provided those blocked >>> channels as options that the DUT would in fact not operate on them, in >>> order to get FCC certification. >>> Further the requirement you reference is about permission to use a >>> channel not OOB emissions. (15.709(c)(4) which is what I was referring to. >>> >>> I still don’t think defining the mask is a bad idea, though I think >>> there are better ways of doing it than we are talking about, but I do >>> think this discussion belongs in a new version of PAWS where we can >>> describe the requirements and define the behavior comprehensively. It is >>> not required to support FCC or Ofcom management of WSDs. Which was the >>> basis of the current PAWS requirements. >>> >>> >>> *From: *Andy Lee <[email protected]> >>> *Date: *Tuesday, October 29, 2013 at 4:07 PM >>> *To: *Peter Stanforth <[email protected]> >>> *Cc: *Ray Bellis <[email protected]>, "[email protected]" < >>> [email protected]> >>> >>> *Subject: *Re: [paws] Question: Encode slopes? >>> >>> Hi Peter, >>> >>> Thanks for the link. The rules actually DO allow for these constraints >>> to come from the database (and defer to Part 2 for testing). The rules in >>> Part 1 are as follows: >>> >>> <image001.png> >>> >>> Best regards, >>> >>> >>> Andy Lee | >>> Google Inc. | >>> [email protected] | >>> 408-230-0522 >>> >>> >>> On Tue, Oct 29, 2013 at 12:02 PM, Peter Stanforth < >>> [email protected]> wrote: >>> Andy >>> The statement “White space devices must comply one way or another” is >>> inconsistent with the testing process we have been required to use to get >>> FCC certification (5 WSDs so far), and I suggest that you cannot currently >>> certify a device that does not have the conformance encoded in the >>> firmware. Specifically: In order to certify a White Space Device the device >>> must be certified against the FCC test process ( >>> https://apps.fcc.gov/kdb/GetAttachment.html?id=Rnszbl7%2BTh%2FUqEwk%2FztsOQ%3D%3D >>> ), which consists of two independent parts. Part 1: Radio Frequency (RF) >>> Certification Tests, tests the RF characteristics independent of the >>> database, and includes conformance with channel 37 limits (iv. Measurements >>> in the 602-620 MHz band ( TV channels 36-38)) - which means the behavior >>> has to be encoded in the device. >>> It is only after they have completed the Part 1 test that they run the >>> Part 2 test: Database Interface Certification Tests, which is to validate >>> the behavior of the radio with the database. >>> So to permit constraints to be managed by a WSDB, as you suggest, would >>> require changes to the current TCB process defined by the FCC. >>> Peter S. >>> >>> *From: *Andy Lee <[email protected]> >>> *Date: *Tuesday, October 29, 2013 at 2:23 PM >>> *To: *Ray Bellis <[email protected]> >>> >>> *Cc: *"[email protected]" <[email protected]> >>> *Subject: *Re: [paws] Question: Encode slopes? >>> >>> Hi, >>> >>> A couple of comments: >>> >>> - The constraints on channels 36 and 38 are part of the current FCC >>> rules. White space devices must comply with this requirement one way or >>> another, whether this information comes from the database or if it's >>> somehow encoded into the device firmware. The FCC allows for either kind >>> of implementation, and PAWS should be supportive of this. >>> - PAWS is not limited to the FCC or the TV band. We want to be >>> cognizant of emerging rules in other jurisdictions, in other bands, and >>> with the current state of radio technologies. This is (hopefully) an >>> international standard that is not bound to any one country's rules or >>> any >>> one company's implementation. >>> - All else being equal, why not choose an encoding that is a better >>> match for all currently known rules and radio technologies? >>> >>> >>> Respectfully, >>> >>> >>> Andy Lee | >>> Google Inc. | >>> [email protected] | >>> 408-230-0522 >>> >>> >>> On Tue, Oct 29, 2013 at 9:57 AM, Ray Bellis <[email protected]> >>> wrote: >>> >>> >>> On 29 Oct 2013, at 15:57, Vincent Chen <[email protected]> wrote: >>> >>> > Just to make it more concrete, I've included the proposed change to >>> the text and examples: >>> I do NOT support this change. All of the observations I made in my >>> message of 9th October still apply. >>> >>> The only potentially valid use case I've seen for non-zero slopes are >>> the FCC limits for channels 36 and 38, and we've heard from Spectrum Bridge >>> that this isn't an issue. >>> >>> Ray >>> >>> _______________________________________________ >>> paws mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/paws >>> >>> >>> >>> >> >> > <image001.png>_______________________________________________ > 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
