Thanks for the comments Don. Answers inline, marked with [V]
Gabor,**** > > ** ** > > I agree on possible renaming, if we want to specify unavailable channels.* > *** > > ** ** > > Please see comments inline. **** > > ** ** > > On Mon, Sep 23, 2013 at 12:56 PM, <[email protected]> wrote:**** > > Vince,**** > > This proposal of yours below could potentially become very confusing. The > message itself is named Available Spectrum Request, and you propose the > Available Spectrum Response to include a bunch of channels with unspecified > power levels, which are btw, not available channels. **** > > So far, we have 4 proposed ways to indicate unavailable channels:**** > > a) Not listing it, implicit unavailability**** > > This has the drawback of not distinguishing between being silent about a > channel that is within the database's purview (channel off), and being > silent about a channel that is outside the database's purview (out of scope > for given ruleset).**** > > ** ** > > [DJ – Why should the database care about channels that are outside the > scope of the ruleset specified by the radio? For example, if the specified > ruleset is FCC-related, then why would I need to include Ofcom-related > channels in the response? Am I missing something?] > [V] In my latest proposal, frequencies mentioned, but with no power is interpreted to be "within purview, but you should not use it". Gaps in the frequency (unmentioned) means "out of scope". My comment simply says that using a), you cannot distinguish between the two cases, not that we propose to say something about the "out of scope" frequencies. **** > > **** > > b) List unavailable channels and specify the power limit, eg -56dbm** > ** > > Since the protocol should stand on its own, independent of any particular > regulatory rule, do we really want to rule this out? In our interpretations > of the FCC rules, for example, a Database is not prevented from doing this. > **** > > ** ** > > [DJ – I’m still in favor of just using the implicit unavailability method > described above in a). What value is there in providing a power level for > an unavailable channel? If I’m the radio, I can’t use the channel, and I’m > not going to intentionally transmit in that channel. This comment also > applies to c) and d).] > See Paul's comment....from the perspective of a radio :) > **** > > **** > > c) List unavailable channels and specify –inf as power limit**** > > ** ** > > "-Inf" is not really workable, because JSON does not allow Infinity or > NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.**** > > ** ** > > d) List unavailable channels and do not specify any power limit **** > > **** > > So far, we have majority in favour of a), few people who could live or > prefer c) and sort of consensus to strike out option b) from the list above. > **** > > **** > > We’ll wait for more input on the list before declaring rough consensus for > the question above; then we’ll go back to the original question on whether > the encoding of spectrum profile should be option 1 or option 2.**** > > **** > > p.s. It looks to me, that if we want to specify unavailable channels, we > may need to modify the names of the paws messages to ‘Spectrum schedule’ or > sg along these lines.**** > > **** > > - Gabor**** > > **** > > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
