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

From: [email-masked]
Date: Wed, 05 Mar 2014 07:09:48 -0800

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/

---

From: Vincent Chen <[email-masked]>
Date: Wed, 5 Mar 2014 07:17:26 -0800

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-masked]> wrote:

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

-- 
-vince

---

From: Andy Lee <[email-masked]>
Date: Wed, 5 Mar 2014 16:17:25 -0800

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-masked] | 408-230-0522

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Wed, 5 Mar 2014 18:34:53 -0800

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 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-masked] 
> <mailto:[email-masked]> | 	 408-230-0522
>
>
>
> On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     PAWS,
>
>      - 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.
>
>     On Wed, Mar 5, 2014 at 7:09 AM, <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>         until the htmlized version and diff are available at
>         tools.ietf.org <http://tools.ietf.org>.
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Vincent Chen <[email-masked]>
Date: Wed, 5 Mar 2014 18:50:45 -0800

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-masked]>wrote:

> produce an observable change in the devices behavior. So if I have figured
> it out correctly the requirement being stated  is:
>
> 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.
>
>
>
>
>
> paws mailing [email-masked]://www.ietf.org/mailman/listinfo/paws
>
>
>

-- 
-vince

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Wed, 5 Mar 2014 19:26:10 -0800

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 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.
>
> On Wed, Mar 5, 2014 at 6:34 PM, Benjamin A. Rolfe <[email-masked] 
> <mailto:[email-masked]>> 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:
>
>     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:
>
>     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
>
>>     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.
>>
>>
>>
>>
>>
>>     <mailto:[email-masked]> | 	408-230-0522 <tel:408-230-0522>
>>
>>
>>
>>          - 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:

---

From: Andy Lee <[email-masked]>
Date: Wed, 5 Mar 2014 21:18:38 -0800

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.

On Wed, Mar 5, 2014 at 7:26 PM, Benjamin A. Rolfe <[email-masked]>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.
>
>
>> 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:
>>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 6 Mar 2014 10:11:06 +0000

Note that we could eliminate the text in this doc and rely on the relevant regulations to force devices to use the parameter.  As long as the protocol can carry the value, then the regs can control what the device must do.

I suspect the concern about not understanding a value is probably covered by the same solution.  If the device is licensed for a particular regulatory domain, then it will have to be able to handle all the values defined for that domain.  The protocol needs a statement to cover it however.  The usual advice is “ignore it”.

Brian

On Mar 6, 2014, at 5:18 AM, Andy Lee <[email-masked]<mailto:[email-masked]>> wrote:

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. |   [email-masked]<mailto:[email-masked]> |   408-230-0522

On Wed, Mar 5, 2014 at 7:26 PM, Benjamin A. Rolfe <[email-masked]<mailto:[email-masked]>> 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.

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

-vince

On Wed, Mar 5, 2014 at 6:34 PM, Benjamin A. Rolfe <[email-masked]<mailto:[email-masked]>> 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:

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-masked]<mailto:[email-masked]> |   408-230-0522<tel:408-230-0522>

On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> wrote:

Abstract:

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

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

--
-vince

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

--
-vince

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

---

From: Vincent Chen <[email-masked]>
Date: Tue, 11 Mar 2014 07:03:47 -0700

Andy, Brian,

I've been stewing on this for a while. I guess at issue are really 2 things:

 1. Whether or not the Device understands the parameter name

 2. Whether or not the Device understands the parameter value

Currently, "must not ignore parameter" is focused on 1. Whether or not the
device
understands the value and what it should do with unrecognized values
is defined by the regulatory domain.

Of course, we can back off and say both 1 and 2, as Brian suggests, are
left up to the regulatory domain. But note that the language here is
specifically in the ETSI section.

 - Will different countries that adopt the ETSI rules have different
requirements?

Thoughts?

-vince

On Thu, Mar 6, 2014 at 2:11 AM, Rosen, Brian <[email-masked]>wrote:

>  Note that we could eliminate the text in this doc and rely on the
> relevant regulations to force devices to use the parameter.  As long as the
> protocol can carry the value, then the regs can control what the device
> must do.
>
>  I suspect the concern about not understanding a value is probably
> covered by the same solution.  If the device is licensed for a particular
> regulatory domain, then it will have to be able to handle all the values
> defined for that domain.  The protocol needs a statement to cover it
> however.  The usual advice is “ignore it”.
>
>  Brian
>
>  On Mar 6, 2014, at 5:18 AM, Andy Lee <[email-masked]> wrote:
>
>  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.
>
> etsiEnSimultaneousChannelOperationRestriction="1", it must follow the
> ETSI power constraint rules.  Any other statements about defaulting to
> "0" and "must not ignore" seem superfluous.
>
>
>>> 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.
>>>
>>>
>>>
>>>
>>>

-- 
-vince

---

From: Cesar Gutierrez <[email-masked]>
Date: Wed, 12 Mar 2014 12:21:47 +0000

Vince and all,

For completeness, this what the ETSI standard says:

“Simultaneous channel operation power restriction (see note 2): Can take values of 0 or 1. A value of 1 indicates the device that the power restriction in clause 4.2.3.2 applies, a value of 0 indicates that the power restriction does not apply. The default value is 0.
NOTE 2:If the simultaneous channel operation power restriction parameter is not provided, the device shall use the default value of 0.”

I think the PAWS specification should be cover the following two cases:

-       The database does not provide the parameter. The device’s behaviour should be “No power restriction”. This repeats Note 2 in ETSI standard but it is in my view worth capturing in PAWS itself

-       The device receives a value different from 0 or 1. This is a communications error or an error in the database’s implementation of PAWS v11, which should only allow for two values. I think PAWS should clarify that the device behaviour should be the same as above.

Whether or not the device understands the parameter name looks an odd question to me. If a device claims to be PAWS v11 compliant, then I would assume that it can decode all parameters that are defined in the spec. On the other hand, I agree that whether or not the device understands what it must do if it receives a 1 is beyond the scope of PAWS.

Different countries may want to add new possible values to this parameter, but this will require an update of the ETSI standard. Compliance with the current version of the ETSI standard requires support of these two values only.

It was asked in London whether we could know the version number of the ETSI standard that will be published and cited in the Official Journal. The answer is no. Andy mentioned a workaround that would allow to follow the usual IETF approval process and change the ETSI version number at a later stage – we will need to use this.

Regards,
Cesar

From: Vincent Chen [mailto:[email-masked]]
Sent: 11 March 2014 14:04
To: Rosen, Brian
Cc: Andy Lee; [email-masked]; Cesar Gutierrez
Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt

Andy, Brian,

Currently, "must not ignore parameter" is focused on 1. Whether or not the device
understands the value and what it should do with unrecognized values
is defined by the regulatory domain.

 - Will different countries that adopt the ETSI rules have different requirements?

Thoughts?

-vince

On Thu, Mar 6, 2014 at 2:11 AM, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:
Note that we could eliminate the text in this doc and rely on the relevant regulations to force devices to use the parameter.  As long as the protocol can carry the value, then the regs can control what the device must do.

Brian

Andy Lee |

 Google Inc. |

 [email-masked]<mailto:[email-masked]> |

 408-230-0522<tel:408-230-0522>

-vince

Is that right?

-Ben

Andy Lee |

 Google Inc. |

 [email-masked]<mailto:[email-masked]> |

 408-230-0522<tel:408-230-0522>

-vince

Abstract:

--
-vince

paws mailing list

--
-vince

--
-vince

________________________________

******************************************************************************************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use of the addressee only.

If you have received this email in error please notify the originator of the message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments at your own risk.

Any views expressed in this message are those of the individual sender and do not represent the views or opinions of Ofcom unless expressly stated otherwise.
******************************************************************************************************************

---

From: Andy Lee <[email-masked]>
Date: Wed, 12 Mar 2014 13:41:21 -0700

I agree with everyone's comments.

I think the "must not ignore" wording is what started this conversation
because it hints at some kind of behavior that is not in the scope of the
protocol itself.  It would be nice if we could remove or change just this
bit of wording.

I believe that all we are really trying to say is that:

   - etsiEnSimultaneousChannelOperationRestriction is an optional parameter
   - Its value can only be set to "0" or "1"
   - If the parameter is missing or malformed in any way (e.g., not "0" or
   "1"), it defaults to etsiEnSimultaneousChannelOperationRestriction="0"
   - For details about what to do when this parameter is "0" or "1", refer
   to ETSI-xxx-yyy

If or when the ETSI standard is updated to expand the meaning of this
parameter, the ETSI and PAWS specs need to updated to reflect those
changes.  At that time, there should probably also be consideration given
to legacy devices that won't understand the extended meaning of this
parameter, and what the recommended handling of those cases should be.
 Since we don't know if this scenario will ever happen, we don't need to do
anything about it right now.

On Wed, Mar 12, 2014 at 5:21 AM, Cesar Gutierrez <
[email-masked]> wrote:

> “Simultaneous channel operation power restriction (see note 2): Can take
> values of 0 or 1. A value of 1 indicates the device that the power
> restriction in clause 4.2.3.2 applies, a value of 0 indicates that the
> power restriction does not apply. The default value is 0.
>
> NOTE 2:If the simultaneous channel operation power restriction parameter
> is not provided, the device shall use the default value of 0.”
>
>
>
> -       The database does not provide the parameter. The device’s
> behaviour should be “No power restriction”. This repeats Note 2 in ETSI
> standard but it is in my view worth capturing in PAWS itself
>
> -       The device receives a value different from 0 or 1. This is a
> communications error or an error in the database’s implementation of PAWS
> v11, which should only allow for two values. I think PAWS should clarify
> that the device behaviour should be the same as above.
>
>
>
> Whether or not the device understands the parameter name looks an odd
> question to me. If a device claims to be PAWS v11 compliant, then I would
> assume that it can decode all parameters that are defined in the spec. On
> the other hand, I agree that whether or not the device understands what it
> must do if it receives a 1 is beyond the scope of PAWS.
>
>
>
> Different countries may want to add new possible values to this parameter,
> but this will require an update of the ETSI standard. Compliance with the
> current version of the ETSI standard requires support of these two values
> only.
>
>
>
> It was asked in London whether we could know the version number of the
> ETSI standard that will be published and cited in the Official Journal. The
> answer is no. Andy mentioned a workaround that would allow to follow the
> usual IETF approval process and change the ETSI version number at a later
> stage – we will need to use this.
>
>
>
>
>
> Regards,
>
> Cesar
>
>
>
>
>
> *From:* Vincent Chen [mailto:[email-masked]]
> *Sent:* 11 March 2014 14:04
> *To:* Rosen, Brian
> *Cc:* Andy Lee; [email-masked]; Cesar Gutierrez
> *Subject:* Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt
>
>
>
> Andy, Brian,
>
>
>
> Note that we could eliminate the text in this doc and rely on the relevant
> regulations to force devices to use the parameter.  As long as the protocol
> can carry the value, then the regs can control what the device must do.
>
>
>
> I suspect the concern about not understanding a value is probably covered
> by the same solution.  If the device is licensed for a particular
> 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. |
>
>  [email-masked] |
>
>  408-230-0522
>
>
>
> 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
>
>  [email-masked] |
>  408-230-0522
> ------------------------------
>
>
> If you have received this email in error please notify the originator of
> the message and delete it from your system.
>
> Any views expressed in this message are those of the individual sender and
> do not represent the views or opinions of Ofcom unless expressly stated
> otherwise.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 12 Mar 2014 20:47:58 +0000

I’ve think you have it pretty well.

The PROTOCOL need not mandate paying attention to the parameter.  The regulations (and the ETSI standard) do that.  The protocol merely transports the parameter.

So just delete the “must not ignore” part.  You might even look at the doc and see if we have any other similar wording we could delete.  We need to make sure MUST, SHOULD, MAY are used appropriately to make sure the protocol itself works.  How the device uses the data transported by the protocol is specified by the regulator and standards like ETSI.  You can use lower case must/should/may language to illustrate what the parameters are and how they might be used, but MUST/SHOULD/MAY 2119 language should be reserved for protocol mechanisms.

Brian

From: Andy Lee <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 12, 2014 at 8:41 PM
To: Cesar Gutierrez <[email-masked]<mailto:[email-masked]>>
Cc: Vincent Chen <[email-masked]<mailto:[email-masked]>>, Brian Rosen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt

I think the "must not ignore" wording is what started this conversation because it hints at some kind of behavior that is not in the scope of the protocol itself.  It would be nice if we could remove or change just this bit of wording.

  *   etsiEnSimultaneousChannelOperationRestriction is an optional parameter
  *   Its value can only be set to "0" or "1"
  *   If the parameter is missing or malformed in any way (e.g., not "0" or "1"), it defaults to etsiEnSimultaneousChannelOperationRestriction="0"
  *   For details about what to do when this parameter is "0" or "1", refer to ETSI-xxx-yyy

If or when the ETSI standard is updated to expand the meaning of this parameter, the ETSI and PAWS specs need to updated to reflect those changes.  At that time, there should probably also be consideration given to legacy devices that won't understand the extended meaning of this parameter, and what the recommended handling of those cases should be.  Since we don't know if this scenario will ever happen, we don't need to do anything about it right now.

On Wed, Mar 12, 2014 at 5:21 AM, Cesar Gutierrez <[email-masked]<mailto:[email-masked]>> wrote:
Vince and all,

Regards,
Cesar

From: Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 11 March 2014 14:04
To: Rosen, Brian
Cc: Andy Lee; [email-masked]<mailto:[email-masked]>; Cesar Gutierrez
Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt

Andy, Brian,

Thoughts?

-vince

Brian

Andy Lee |

 Google Inc. |

-vince

Is that right?

-Ben

Andy Lee |

 Google Inc. |

-vince

Abstract:

--
-vince

paws mailing list

--
-vince

--
-vince

******************************************************************************************************************
For more information visit www.ofcom.org.uk<http://www.ofcom.org.uk>