Thanks Vincent.
I was attempting to capture what you just explained. I think that is
what I captured - reference the ETSI spec for what to do when the value
is not zero.
I had guessed that the intent of adding this param was to provide a way
to signal that an additional constraint is applied to the channels being
used.
On 3/5/2014 6:50 PM, Vincent Chen wrote:
Ben, Andy,
From what I understood, the request is to add a parameter to the
protocol with
numeric string values, with a default value of "0". It does not limit
the valid values
to "0" or "1", and does not associate meaning to the values. The
device behavior,
upon receipt of the value, is defined by the ETSI specs, not the
protocol doc.
The "MUST NOT ignore" is intended to indicate that the device must
understand
the value, if present. The risk of not processing the value is that,
if ETSI were to add
another value that is more restrictive, the hard-coded device would be
out of
compliance.
I believe the intent is to prevent hard-coding in devices.
-vince
On Wed, Mar 5, 2014 at 6:34 PM, Benjamin A. Rolfe <[email protected]
<mailto:[email protected]>> wrote:
I too was struggling with this wording. "Must not" is often
problematic for me, and I was struggling to figure out how we
verify that device has not ignored a parameter when the value of
the paramter has a value that produces no observable behavior,
such as the case Andy sites or the case where the value is zero.
The logic should be:
If (etsiEnSimultaneousChannelOperationRestriction == 0)
Do what you were going to do anyway;
else if (etsiEnSimultaneousChannelOperationRestriction == 1)
Do not exceed the lower limit;
The first condition looks to me pretty much the definition of
"ignore" (based on my experience as a parent :-). Only the second
condition can produce an observable change in the devices
behavior. So if I have figured it out correctly the requirement
being stated is:
If the etsiEnSimultaneousChannelOperationRestriction paramter is
provided and the value is 1, the Device MUST comply with the
additional power restrictions when simultaneous transmission on
multiple channel operation defined in [reference].
Is that right?
-Ben
On 3/5/2014 4:17 PM, Andy Lee wrote:
I have a question about the new parameter
etsiEnSimultaneousChannelOperationRestriction and the phrase "If
it is provided, the Device MUST NOT ignore it."
I can understand that if this parameter is provided and is set to
"1", that the device must honor it (reduce output power when
using multiple channels).
But what if there is a device that "hard coded" to always apply
the power restriction when using multiple channels? This
"conservative" approach would always remain below the permitted
emission limits regardless of whether this flag is set to "1" or "0".
Are we saying that if this parameter is provided and is set to
"0" that the device must not apply the multi-channel power
restrictions? What does it mean to say "MUST NOT ignore it" in
such a case.
Andy Lee | Google Inc. | [email protected]
<mailto:[email protected]> | 408-230-0522 <tel:408-230-0522>
On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen <[email protected]
<mailto:[email protected]>> wrote:
PAWS,
Draft 11 contains the following changes:
- Separation of protocol and regulatory requirements. In
essence, MAY, MUST , SHOULD has been replaced where the text
describes regulatory requirements and device behavior. They
are replaced with just explanatory text.
- Added the new ETSI parameter for simultaneous
channel-operation restrictions
Diff:
http://www.ietf.org/rfcdiff?url1=draft-ietf-paws-protocol-10&difftype=--html&submit=Go%21&url2=draft-ietf-paws-protocol-11
-vince
On Wed, Mar 5, 2014 at 7:09 AM, <[email protected]
<mailto:[email protected]>> wrote:
A New Internet-Draft is available from the on-line
Internet-Drafts directories.
This draft is a work item of the Protocol to Access WS
database Working Group of the IETF.
Title : Protocol to Access White-Space
(PAWS) Databases
Authors : Vincent Chen
Subir Das
Lei Zhu
John Malyar
Peter J. McCann
Filename : draft-ietf-paws-protocol-11.txt
Pages : 108
Date : 2014-03-05
Abstract:
Portions of the radio spectrum that are allocated to
licensees are
available for non-interfering use. This available
spectrum is called
"White Space." Allowing secondary users access to
available spectrum
"unlocks" existing spectrum to maximize its
utilization and to
provide opportunities for innovation, resulting in
greater overall
spectrum utilization.
One approach to manage spectrum sharing uses databases
to report
spectrum availability to devices. To achieve
interoperability among
multiple devices and databases, a standardized
protocol must be
defined and implemented. This document defines such a
protocol, the
"Protocol to Access White Space (PAWS) Databases".
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-paws-protocol-11
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-11
Please note that it may take a couple of minutes from the
time of submission
until the htmlized version and diff are available at
tools.ietf.org <http://tools.ietf.org>.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
paws mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/paws
--
-vince
_______________________________________________
paws mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/paws
--
-vince
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
