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



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]
https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws

Reply via email to