Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt

[Andy Lee <[e-mail]>]

Thank you both for the additional clarifications.

I think this is getting out-of-scope for the PAWS standard, but there is no
future-proofing guidance here either.  If a device built today knows what
to do when etsiEnSimultaneousChannelOperationRestriction="0" and when
etsiEnSimultaneousChannelOperationRestriction="1", what should it do when a
database sends a value it doesn't recognize in the future?

The spec is clear about what to do when the parameter is not sent at all,
but no fallback behavior is defined for when the parameter takes on new
values never seen before.  This seems to be clearly out-of-scope of PAWS
itself, and as Ben suggested, this should defer to the ETSI spec for
details.

However, this still leaves the question of what "must not ignore" means.
 Devices cannot process unknown future values, so how can they possibly
"not ignore" a field that is unrecognizable to them?

At this point, I think all we can say is that if a device encounters
etsiEnSimultaneousChannelOperationRestriction="1", it must follow the ETSI
power constraint rules.  Any other statements about defaulting to "0" and
"must not ignore" seem superfluous.


Andy Lee | Google Inc. | [e-mail] | 408-230-0522


On Wed, Mar 5, 2014 at 7:26 PM, Benjamin A. Rolfe <[e-mail]>wrote:

>  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 <[e-mail]>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. |  [e-mail] |  408-230-0522
>>
>>
>> On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen <[e-mail]> 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, <[e-mail]> 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.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> paws mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>
>>>
>>>
>>>
>>>   --
>>> -vince
>>>
>>> _______________________________________________
>>> paws mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/paws
>>>
>>>
>>
>>
>> _______________________________________________
>> paws mailing [e-mail]://www.ietf.org/mailman/listinfo/paws
>>
>>
>>
>> _______________________________________________
>> paws mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/paws
>>
>>
>
>
>  --
> -vince
>
>
>
> _______________________________________________
> paws mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/paws
>
>