Subject: Re: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06

From: Vincent Chen <[email-masked]>
Date: Mon, 15 Jul 2013 14:56:27 -0700

Sungjin,

Sorry for the long delay (vacation). Answers inline.

On Sun, Jun 30, 2013 at 10:30 PM, 유성진 <[email-masked]> wrote:

> Hi All,
>
> I have found two typos.
>
> At example "getSpectrum" JSON-RPC in 6.4.1. :
>         "id": "xxxxxx",     --> Comma should be deleted.
> At example "getSpectrumBatch" JSON-RPC in 6.5.1. :
>         "id": "xxxxxx",     --> Comma should be deleted.
>

Thanks!

>
>
> I have a comment about example "getSpectrum" JSON-RPC response in 6.4.2
> and 6.5.2.
> There are two spectrum information parameters  for the same frequency
> range.
> One is for bandwidth 6e6, and the other is for bandwidth 1e5.
> But spectral density of 6e6 is different from that of 1e5 in the same
> frequency range.
> It will be more nice if the spectral density of the same frequency range
> is same.
> Or it will be also nice if frequency ranges are modified to be different
> from each other.
>

This is intended to represent the permissible maximum power in which
"wide-band" and "narrow-band" operations are permitted.
The available frequencies do not change (hence, the same start/stop
frequencies), just the permissible power.

Does that make sense?

-vince

> Thank you.
>
> BR,
> Sungjin
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, June 20, 2013 2:18 AM
> To: [email-masked]
> Subject: [paws] WGLC on
> http://tools.ietf.org/html/draft-ietf-paws-protocol-06
>
>
> All,
>
> The Editor of the document posted a new version and indicated that all
> open issues raised on the list were resolved, and that there are no more
> open issues he is aware of.
> Therefore, I'd like to issue a wg last call on the document. We need
> reviews and feedback in order to be able to progress the document.
>
> Please read through the draft and send any comments you may have to the
> list in the next 2-3 weeks.
> 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-masked]
> https://www.ietf.org/mailman/listinfo/paws
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>

-- 
-vince

---

From: Sungjin <[email-masked]>
Date: Tue, 16 Jul 2013 10:02:22 +0900

Vince,

I understand "bandwidth" parameter is just for defining permissible 
power or spectral density and
it dose not represent the operation bandwidth. (see 4.4.5. 
SPECTRUC_USE_NOTIFY, 'spectra' parameter description)
If I misunderstand, please correct me.

And I found another typos.
"jsonrpc": "2.0", should be added to all examples.

Regards,
Sungjin

On 07/16/2013 06:56 AM, Vincent Chen wrote:
> On Sun, Jun 30, 2013 at 10:30 PM, 유성진 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi All,
>
>     I have found two typos.
>
>     I have a comment about example "getSpectrum" JSON-RPC response in
>     6.4.2 and 6.5.2.
>     There are two spectrum information parameters  for the same
>     frequency range.
>     But spectral density of 6e6 is different from that of 1e5 in the
>     same frequency range.
>     It will be more nice if the spectral density of the same frequency
>     range is same.
>     Or it will be also nice if frequency ranges are modified to be
>     different from each other.
>
>
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf Of [email-masked] <mailto:[email-masked]>
>     To: [email-masked] <mailto:[email-masked]>
>     Subject: [paws] WGLC on
>     The Editor of the document posted a new version and indicated that
>     all open issues raised on the list were resolved, and that there
>     are no more open issues he is aware of.
>     Therefore, I'd like to issue a wg last call on the document. We
>     need reviews and feedback in order to be able to progress the
>     document.
>
>     Please read through the draft and send any comments you may have
>     to the list in the next 2-3 weeks.
>     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
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Thu, 18 Jul 2013 22:37:47 +0000

Here are some comments to the draft:

You may want to define the ruleset, listing service, listing server in the terminology section.

Section 3.1, bullet 2 says that "The Database may use the rule-set list to determine its response", which I think is not right. The Database uses the location of the master device to determine its response, and the required parameters and ruleset to be supported are sent back to the master device based on the device's location.

Section 4 starts with listing the components of paws. Spectrum use notify is missing from that list.

Section 4.1 has this sentence: " A Device SHOULD support operation in any regulatory environment." It must be some leftover which I think should be deleted.

Section 4.1, configuration update:
s/SHOULD be able to update/SHOULD update, 2 instances
when the URI changes, the inclusion of the DbUpdateSpec should be a MUST instead of SHOULD. Same comment for the next sentence (s/SHOULD/MUST)

Section 5.1
Both point and region are listed as optional for the Geolocation element. But one of them has to be present.
The Note below the figure says " Note: point and polygon are mutually exclusive", while it should say " Note: point and region are mutually exclusive"
In several places you have 'depends'; expand what does it depend on.

" If present, it indicates that the GeoLocation represents a
      region.  Database support for regions is OPTIONAL."
I would delete the second sentence, and instead state in 4.4.3 that the support for this request is optional.

"   center:  The center refers to the location of a GeoLocation point and
      is represented as the center of an ellipse.  REQUIRED."
What does the REQUIRED word mean here? That the parameter center must always be present? That doesn't seem to be right as the ellipse shape may not be present (instead the polygon may be present).

Throughout section 6, where you define the schemas, the description field is broken up into multiple lines and you have quotation marks and + signs in all lines. It would improve the readability of the document if you removed those quotation marks and + signs. 

- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Wednesday, June 19, 2013 10:18 AM
To: [email-masked]
Subject: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06

All,

The Editor of the document posted a new version and indicated that all open issues raised on the list were resolved, and that there are no more open issues he is aware of.
Therefore, I'd like to issue a wg last call on the document. We need reviews and feedback in order to be able to progress the document.

Please read through the draft and send any comments you may have to the list in the next 2-3 weeks.
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

---

From: Vincent Chen <[email-masked]>
Date: Thu, 18 Jul 2013 18:13:18 -0700

Gabor,

Thanks for the suggestions. I'll incorporate them into a new draft.

-vince

On Thu, Jul 18, 2013 at 3:37 PM, <[email-masked]> wrote:

> Section 3.1, bullet 2 says that "The Database may use the rule-set list to
> determine its response", which I think is not right. The Database uses the
> location of the master device to determine its response, and the required
> parameters and ruleset to be supported are sent back to the master device
> based on the device's location.
>
> Section 4.1 has this sentence: " A Device SHOULD support operation in any
> regulatory environment." It must be some leftover which I think should be
> deleted.
>
> when the URI changes, the inclusion of the DbUpdateSpec should be a MUST
> instead of SHOULD. Same comment for the next sentence (s/SHOULD/MUST)
>
> Section 5.1
> The Note below the figure says " Note: point and polygon are mutually
> exclusive", while it should say " Note: point and region are mutually
> exclusive"
> What does the REQUIRED word mean here? That the parameter center must
> always be present? That doesn't seem to be right as the ellipse shape may
> not be present (instead the polygon may be present).
>
> Throughout section 6, where you define the schemas, the description field
> is broken up into multiple lines and you have quotation marks and + signs
> in all lines. It would improve the readability of the document if you
> removed those quotation marks and + signs.
>
> - Gabor
>
>
> Bajko Gabor (Nokia-CIC/SiliconValley)

-- 
-vince

---

From: Vincent Chen <[email-masked]>
Date: Thu, 18 Jul 2013 18:16:37 -0700

Sungjin,

On Mon, Jul 15, 2013 at 6:02 PM, Sungjin <[email-masked]> wrote:

>  Vince,
>
> I understand "bandwidth" parameter is just for defining permissible power
> or spectral density and

Oh, I understand what you're saying. The example does not make sure the
math works out to be equivalent.
I thought, though, some regulators actually wants different power spectral
density for narrow band, so it's not always
guaranteed to be the same.

> "jsonrpc": "2.0", should be added to all examples.

Thanks. I will incorporate this.

>> 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

-- 
-vince

---

From: Sungjin Yoo <[email-masked]>
Date: Fri, 19 Jul 2013 13:49:22 +0900

Vince,

Comment is in line.

On 07/19/2013 10:16 AM, Vincent Chen wrote:
> Sungjin,
>
>
> On Mon, Jul 15, 2013 at 6:02 PM, Sungjin <[email-masked] 
>     I understand "bandwidth" parameter is just for defining
>     permissible power or spectral density and
> Oh, I understand what you're saying. The example does not make sure 
> the math works out to be equivalent.
> I thought, though, some regulators actually wants different power 
> spectral density for narrow band, so it's not always

If master device receive the message in the example, it will be 
confused. Assume the master device decides to use the spectrum from 
5.18e8 Hz to 5.24e8 Hz(6MHz bandwidth) after receiving this message. 
Then the master device may be confused to interpret permissible maximum 
power. First one in the example represents 30.0 dBm, but second one 
represents about 44.78 dBm(=27dBm + 17.78dB). The master device don't 
know which one is correct.
So I think it will be clear if "frequencyRanges" in the second one(for 
"bandwidth" : 1e5) is modified to different frequency from first one(for 
"bandwidth" : 1e5)

>>         I have a comment about example "getSpectrum" JSON-RPC
>>         response in 6.4.2 and 6.5.2.
>>         But spectral density of 6e6 is different from that of 1e5 in
>>         the same frequency range.
>>         It will be more nice if the spectral density of the same
>>         frequency range is same.
>>         Or it will be also nice if frequency ranges are modified to
>>         be different from each other.
>>
>>
>>     This is intended to represent the permissible maximum power in
>>     which "wide-band" and "narrow-band" operations are permitted.
>>     The available frequencies do not change (hence, the same
>>     start/stop frequencies), just the permissible power.
>>
>>     Does that make sense?
>>
>>     -vince
>>
>>
>>
>>         Thank you.
>>
>>         BR,
>>         Sungjin
>>
>>
>>         [mailto:[email-masked] <mailto:[email-masked]>]
>>         On Behalf Of [email-masked] <mailto:[email-masked]>
>>         The Editor of the document posted a new version and indicated
>>         that all open issues raised on the list were resolved, and
>>         that there are no more open issues he is aware of.
>>         Therefore, I'd like to issue a wg last call on the document.
>>         We need reviews and feedback in order to be able to progress
>>         the document.
>>
>>         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

Regards,
Sungjin

---

From: Vincent Chen <[email-masked]>
Date: Thu, 18 Jul 2013 22:17:05 -0700

Sunglin,

Some clarification: The maxPowerDbm is total power. It is not a spectral
density.

Thus, if a 6MHz channel is available, the Device may choose to put, say,
ten 100kHz sub-channels within that channel.
The total power summed over those 10 sub-channels cannot exceed 27dBm.

So here is one way the Device may use the response.
 - The Device determines first if it wants to be a narrow band (1e5) or
wideband (6e6) device
 - It selects the Spectrum specification, based on its mode

-vince

On Thu, Jul 18, 2013 at 9:49 PM, Sungjin Yoo <[email-masked]> wrote:

> If master device receive the message in the example, it will be confused.
> Assume the master device decides to use the spectrum from 5.18e8 Hz to
> 5.24e8 Hz(6MHz bandwidth) after receiving this message. Then the master
> device may be confused to interpret permissible maximum power. First one in
> the example represents 30.0 dBm, but second one represents about 44.78
> dBm(=27dBm + 17.78dB). The master device don't know which one is correct.

-- 
-vince

---

From: Sungjin Yoo <[email-masked]>
Date: Fri, 19 Jul 2013 15:02:02 +0900

Vince,

Comment is in line.

On 07/19/2013 02:17 PM, Vincent Chen wrote:
> Sunglin,
>
> Some clarification: The maxPowerDbm is total power. It is not a 
> spectral density.
>
I agree. But (maxPowerDBm / bandwidth) defines the spectral density.

> Thus, if a 6MHz channel is available, the Device may choose to put, 
> say, ten 100kHz sub-channels within that channel.
>  - The Device determines first if it wants to be a narrow band (1e5) 
> or wideband (6e6) device
I think "bandwidth" parameter does not limit the operation bandwidth of 
the device, it is just reference bandwidth to define permissible power 
levels and that is equivalent to define spectral density. I think 
"maxContiguousBwHz" parameter(4.4.2)  limit the operation bandwidth, and 
"bandwidth" parameter does not.

I understand the "bandwidth" parameter from following paragraphs.

4.4.5. SPECTRUM_USE_NOTIFY, "The actual bandwidth to be used (as 
computed from the start and stop frequencies) MAY be different from 
the"bandwidth" value.

5.4. FrequencyRange, "NOTE: (maxPowerDBm / bandwidth) defines the 
maximum permitted EIRP spectral density."

4.4.2. AVAIL_SPECTRUM_RESP, "maxContiguousBwHz: The Database MAY return 
a constraint on the maximum contiguous bandwidth (in Hertz) allowed."

>
> -vince
>
>
> On Thu, Jul 18, 2013 at 9:49 PM, Sungjin Yoo <[email-masked] 
>>     Oh, I understand what you're saying. The example does not make
>>     sure the math works out to be equivalent.
>     confused. Assume the master device decides to use the spectrum
>     from 5.18e8 Hz to 5.24e8 Hz(6MHz bandwidth) after receiving this
>     message. Then the master device may be confused to interpret
>     permissible maximum power. First one in the example represents
>     30.0 dBm, but second one represents about 44.78 dBm(=27dBm +
>     17.78dB). The master device don't know which one is correct.
>     So I think it will be clear if "frequencyRanges" in the second
>     one(for "bandwidth" : 1e5) is modified to different frequency from
>     first one(for "bandwidth" : 1e5)
>
>
>>>             There are two spectrum information parameters  for the
>>>             same frequency range.
>>>             But spectral density of 6e6 is different from that of
>>>             1e5 in the same frequency range.
>>>             Or it will be also nice if frequency ranges are modified
>>>             to be different from each other.
>>>
>>>
>>>         This is intended to represent the permissible maximum power
>>>         in which "wide-band" and "narrow-band" operations are permitted.
>>>             [mailto:[email-masked]
>>>             <mailto:[email-masked]>] On Behalf Of
>>>             [email-masked] <mailto:[email-masked]>
>>>             The Editor of the document posted a new version and
>>>             indicated that all open issues raised on the list were
>>>             resolved, and that there are no more open issues he is
>>>             aware of.
>>>             Therefore, I'd like to issue a wg last call on the
>>>             document. We need reviews and feedback in order to be
>>>             able to progress the document.
>>>
>>>             Please read through the draft and send any comments you
>>>             may have to the list in the next 2-3 weeks.
>>>             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

---

From: Vincent Chen <[email-masked]>
Date: Tue, 23 Jul 2013 19:14:37 -0700

Sungjin,

Sorry for the delay and the confusion.

Assuming we have the response that contains:

       "spectra": [
         {
          "bandwidth": 6e6,
          "frequencyRanges": [
            {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":30.0},
            ...
          ]
         },
         {
          "bandwidth": 1e5,
          "frequencyRanges": [
            {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":27.0},
            ...
          ]
         }

This specifies that the frequencies in the range [518MHz, 536MHz) are
available, and the device must satisfy two conditions:

 - Within any 6MHz in that range, total power may not exceed 30.0 dBm
AND
 - Within any 100kHz in that range, total power may not exceed 27 dBm

In this example, it means that the device may fit two 100kHz "sub-channels"
at 27dBm within any 6MHz channel.

(There are many other possibilities.)

Does this make sense? If so, I'll update the draft to make this more clear.

Thanks.

-vince

On Thu, Jul 18, 2013 at 11:02 PM, Sungjin Yoo <[email-masked]> wrote:

> 4.4.5. SPECTRUM_USE_NOTIFY, "The actual bandwidth to be used (as computed
> from the start and stop frequencies) MAY be different from the"bandwidth"
> value.
>
> 5.4. FrequencyRange, "NOTE: (maxPowerDBm / bandwidth) defines the maximum
> permitted EIRP spectral density."
>
> 4.4.2. AVAIL_SPECTRUM_RESP, "maxContiguousBwHz: The Database MAY return a
> constraint on the maximum contiguous bandwidth (in Hertz) allowed."
>
>
>
>
>  -vince
>
>
>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>> Of [email-masked]

-- 
-vince

---

From: Sungjin Yoo <[email-masked]>
Date: Wed, 24 Jul 2013 16:24:45 +0900

Vince and all,

Thanks for the explanation.
I understand what you mean.

I think current encoding format may cause a misunderstanding. Because 
maximum power informations for the same frequency may be distributed to 
multiple object. I think it's clearer if "bandwidth" is coupled with 
"maxPowerDBm".

How about the following format?

        "spectra": [
          {
           "maxPower":[
	    {"bandwidthHz":6e6, "maxPowerDBm":30.0},
             {"bandwidthHz":1e5, "maxPowerDBm":27.0}
           ]
           "frequencyRanges": [
             {"startHz":5.18e8, "stopHz":5.36e8},
             ...
           ]

Regards,
Sungjin

On 07/24/2013 11:14 AM, Vincent Chen wrote:
> In this example, it means that the device may fit two 100kHz 
> "sub-channels" at 27dBm within any 6MHz channel.
>
> On Thu, Jul 18, 2013 at 11:02 PM, Sungjin Yoo <[email-masked] 
>>     Thus, if a 6MHz channel is available, the Device may choose to
>>     put, say, ten 100kHz sub-channels within that channel.
>>      - The Device determines first if it wants to be a narrow band
>>     (1e5) or wideband (6e6) device
>     I think "bandwidth" parameter does not limit the operation
>     bandwidth of the device, it is just reference bandwidth to define
>     permissible power levels and that is equivalent to define spectral
>     density. I think "maxContiguousBwHz" parameter(4.4.2)  limit the
>     operation bandwidth, and "bandwidth" parameter does not.
>
>     computed from the start and stop frequencies) MAY be different
>     from the"bandwidth" value.
>
>     4.4.2. AVAIL_SPECTRUM_RESP, "maxContiguousBwHz: The Database MAY
>     return a constraint on the maximum contiguous bandwidth (in Hertz)
>     allowed."
>
>
>
>>
>>     -vince
>>
>>
>>>             it dose not represent the operation bandwidth. (see
>>>             4.4.5. SPECTRUC_USE_NOTIFY, 'spectra' parameter description)
>>>         Oh, I understand what you're saying. The example does not
>>>         make sure the math works out to be equivalent.
>>>         I thought, though, some regulators actually wants different
>>>         power spectral density for narrow band, so it's not always
>>         If master device receive the message in the example, it will
>>         be confused. Assume the master device decides to use the
>>         spectrum from 5.18e8 Hz to 5.24e8 Hz(6MHz bandwidth) after
>>         receiving this message. Then the master device may be
>>         confused to interpret permissible maximum power. First one in
>>         the example represents 30.0 dBm, but second one represents
>>         about 44.78 dBm(=27dBm + 17.78dB). The master device don't
>>         So I think it will be clear if "frequencyRanges" in the
>>         second one(for "bandwidth" : 1e5) is modified to different
>>         frequency from first one(for "bandwidth" : 1e5)
>>
>>
>>>>             On Sun, Jun 30, 2013 at 10:30 PM, 유성진
>>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>                 Hi All,
>>>>
>>>>                 I have found two typos.
>>>>
>>>>                 I have a comment about example "getSpectrum"
>>>>                 JSON-RPC response in 6.4.2 and 6.5.2.
>>>>                 There are two spectrum information parameters  for
>>>>                 But spectral density of 6e6 is different from that
>>>>                 of 1e5 in the same frequency range.
>>>>                 It will be more nice if the spectral density of the
>>>>                 same frequency range is same.
>>>>                 Or it will be also nice if frequency ranges are
>>>>                 modified to be different from each other.
>>>>
>>>>
>>>>             This is intended to represent the permissible maximum
>>>>             power in which "wide-band" and "narrow-band" operations
>>>>             are permitted.
>>>>             The available frequencies do not change (hence, the
>>>>             same start/stop frequencies), just the permissible power.
>>>>
>>>>             Does that make sense?
>>>>
>>>>             -vince
>>>>
>>>>
>>>>
>>>>                 Thank you.
>>>>
>>>>                 BR,
>>>>                 Sungjin
>>>>
>>>>
>>>>                 indicated that all open issues raised on the list
>>>>                 were resolved, and that there are no more open
>>>>                 issues he is aware of.
>>>>                 document. We need reviews and feedback in order to
>>>>                 be able to progress the document.
>>>>
>>>>                 Please read through the draft and send any comments
>>>>                 you may have to the list in the next 2-3 weeks.
>>>>                 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

---

From: Vincent Chen <[email-masked]>
Date: Wed, 24 Jul 2013 08:25:20 -0700

Sungjin, All,

Actually, the max power must be associated with each available-frequency
range, since it can be different
for different ranges.

The list of {startHz, stopHz, maxPowerDBm} "roughly" defines a spectral
mask. So there might be one
for wide-band and a different mask for narrow band operations.

There was a question, though, of whether the "mask" should be encoded
differently, e.g.,

Option 1: List of {startHz, maxStartPowerDBm, stopHz, maxStopPowerDBm}

Option 2: List of {frequencyHz, maxPowerDBm} sorted by frequencyHz

Does anyone have any thoughts on this?

-vince

On Wed, Jul 24, 2013 at 12:24 AM, Sungjin Yoo <[email-masked]> wrote:

>>    I think "bandwidth" parameter does not limit the operation bandwidth
>> of the device, it is just reference bandwidth to define permissible power
>>> confused. Assume the master device decides to use the spectrum from 5.18e8
>>> Hz to 5.24e8 Hz(6MHz bandwidth) after receiving this message. Then the
>>> master device may be confused to interpret permissible maximum power. First
>>> one in the example represents 30.0 dBm, but second one represents about
>>> 44.78 dBm(=27dBm + 17.78dB). The master device don't know which one is
>>> correct.

-- 
-vince

---

From: Peter McCann <[email-masked]>
Date: Wed, 24 Jul 2013 18:20:03 +0000

Do we need to talk about the slope of the filter mask that caps the
out-of-band emissions?

-Pete

Vincent Chen wrote:
> AND - Within any 100kHz in that range, total power may not exceed 27 
> dBm In this example, it means that the device may fit two 100kHz "sub- 
> channels" at 27dBm within any 6MHz channel.
> 
> say, ten 100kHz sub-channels within that channel. 		The total power
> summed over those 10 sub-channels cannot exceed 27dBm.
> 
> 
> of the device, it is just reference bandwidth to define permissible 
> power levels and that is equivalent to define spectral density. I 
> think "maxContiguousBwHz" parameter(4.4.2)  limit the operation 
> bandwidth, and "bandwidth" parameter does not.
> 
> return a constraint on the maximum contiguous bandwidth (in Hertz) allowed."
> 
> 
> 
> 
> 
> 		-vince
> 
> 
> Then the master device may be confused to interpret permissible 
> maximum power. First one in the example represents 30.0 dBm, but 
> second one represents about 44.78 dBm(=27dBm + 17.78dB). The master 
> device don't know which one is correct.
> 							I have a comment about
> example "getSpectrum" JSON-RPC response in 6.4.2 and 6.5.2.
> 							There are two spectrum
> information parameters  for the same frequency range.
> 							But spectral density of 6e6
> is different from that of 1e5 in the same frequency range.
> 							It will be more nice if the
> spectral density of the same frequency range is same.
> 							Or it will be also nice if
> frequency ranges are modified to be different from each other.
> 
> 
> 
> 							-----Original Message----- 							From: [email-masked]
> [mailto:[email-masked]] On Behalf Of [email-masked]
> 							Sent: Thursday, June 20, 2013 2:18 AM 							To: [email-masked]
> 							Subject: [paws] WGLC on
> that all open issues raised on the list were resolved, and that there
> are no more open issues he is aware of. 							Therefore, I'd like to
> issue a wg last call on the document. We need reviews and feedback in 
> order to be able to progress the document.
> 
> 							Please read through the draft
> and send any comments you may have to the list in the next 2-3 weeks.
> 							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
>

---

From: Vincent Chen <[email-masked]>
Date: Wed, 24 Jul 2013 13:29:40 -0700

Peter,

That's what makes the Option 2, perhaps, more generic:

  List of [frequencyHz, maxPowerDBm]

in that you can start to build piece-wise linear shapes....

It would make the protocol more future-proof, even if we don't use it
initially to capture such shapes.

I guess the trade-off is, at what point the protocol becomes too
complex.....

-vince

On Wed, Jul 24, 2013 at 11:20 AM, Peter McCann <[email-masked]>wrote:

> bandwidth
> >                                       On 07/16/2013 06:56 AM, Vincent
> Chen
> > wrote:
> >
> >
> >                                               Sungjin,
> >
> >                                               Sorry for the long delay
> >                                                       I have found two
> typos.
> >                                                       At example
> "getSpectrum"
> > JSON-RPC in 6.4.1. :
> >                                                               "id":
> "xxxxxx",     -
> > -> Comma should be deleted.
> >                                                       At example
> "getSpectrumBatch"
> > JSON-RPC in 6.5.1. :
> >                                                               "id":
> "xxxxxx",     -
> > -> Comma should be deleted.
> >
> >
> >
> >                                               Thanks!
> >
> >
> >
> >
> >                                                       I have a comment
> about
> >                                                       There are two
> spectrum
> >                                                       One is for
> bandwidth 6e6, and
> > the other is for bandwidth 1e5.
> >                                                       But spectral
> density of 6e6
> >                                               This is intended to
> represent the permissible maximum power in
> >                                                       -----Original
> Message-----                                                      From:
> [email-masked]
> >                                                       Sent: Thursday,
> June 20, 2013 2:18 AM                                                   To:
> [email-masked]
> >                                                       Subject: [paws]
> WGLC on
> >                                                       The Editor of the
> document posted a new version and indicated
>                       Therefore, I'd like to

-- 
-vince