Subject: [paws] response to REGISTRATION_REQ

From: "Harasty, Daniel J" <[email-masked]>
Date: Thu, 25 Jul 2013 15:04:37 +0000

Sanjeev mentioned:

From: [email-masked]
Sent: Thursday, July 25, 2013 10:31 AM
[...]
5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have repsonses like accepted/denied by database?
[...]

As for possible responses to REGISTRATION_REQ, I have been planning to suggest this:  I think we need a new generic error code "REGISTRATION_FAILED".  Perhaps a value -203, or the next available -200-block code.

This should be used by the Database in response to a REGISTRATION_REQ if no other more specific code is applicable.  (For example: if a registration failed due to a missing field in REGISTRATION_REQ, the Database should still send the REQUIRED  error; if a REGISTRATION_REQ failed due to the Device being unauthorized, the Database should still send the UNAUTHORIZED error.)

Sanjeev: does that address your need sentiment for "a denied registration"?

Dan

(I have a separate comment about SPECTRUM_USE_NOTIFY, to follow.)

---

From: "Sajeev Manikkoth" <[email-masked]>
Date: Thu, 25 Jul 2013 21:05:10 +0530

Hi Daniel,

First of all thank you very much for streamlining my comments, and splitting
it into separate email topics. May be I need to take care of it next time..

Yes, the semantic you suggest here also can be the solution. My point was,
an authorized master's request also can fail, because of load at database,
or due to request semantic error. 

As SPECTRUM_USE_NOTIFY also can fall in such a category, I was suggesting a
generic response accepted/denied.

Best Regards,

Sajeev

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Harasty, Daniel J
Sent: Thursday, July 25, 2013 8:35 PM
To: [email-masked]
Subject: [paws] response to REGISTRATION_REQ

Sanjeev mentioned:

[...]

5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have
repsonses like accepted/denied by database?

[...]

As for possible responses to REGISTRATION_REQ, I have been planning to
suggest this:  I think we need a new generic error code
"REGISTRATION_FAILED".  Perhaps a value -203, or the next available
-200-block code.  

This should be used by the Database in response to a REGISTRATION_REQ if no
other more specific code is applicable.  (For example: if a registration
failed due to a missing field in REGISTRATION_REQ, the Database should still
send the REQUIRED  error; if a REGISTRATION_REQ failed due to the Device
being unauthorized, the Database should still send the UNAUTHORIZED error.)

Dan

---

From: Vincent Chen <[email-masked]>
Date: Thu, 25 Jul 2013 09:00:29 -0700

Dan, Sajeev,

I was assuming that general "server errors" would be handled at the HTTP
layer with 5xx codes.

1. For REGISTRATION_REQ, what error conditions should we be capturing?
   - Some internal error, but can try again later?

2. SPECTRUM_USE_NOTIFY. What would the device do differently if it did get
an error?
  I was assuming that this is a async notify, fire-and-forget, from the
perspective of the device

-vince

On Thu, Jul 25, 2013 at 8:35 AM, Sajeev Manikkoth <[email-masked]
> wrote:

>  Hi Daniel,****
>
> ** **
>
> First of all thank you very much for streamlining my comments, and
> splitting it into separate email topics. May be I need to take care of it
> next time..****
>
> ** **
>
> an authorized master’s request also can fail, because of load at database,
> or due to request semantic error. ****
>
> As SPECTRUM_USE_NOTIFY also can fall in such a category, I was suggesting
> a generic response accepted/denied.****
>
> ** **
>
> Best Regards,****
>
> Sajeev****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Harasty, Daniel J
> *Sent:* Thursday, July 25, 2013 8:35 PM
> *To:* [email-masked]
> *Subject:* [paws] response to REGISTRATION_REQ****
>
> ** **
>
> Sanjeev mentioned:****
>
> ** **
>
> Sent: Thursday, July 25, 2013 10:31 AM****
>
> [...]****
>
> repsonses like accepted/denied by database?****
>
> [...]****
>
> ** **
>
> “REGISTRATION_FAILED”.  Perhaps a value -203, or the next available
> -200-block code.  ****
>
> ** **
>
> This should be used by the Database in response to a REGISTRATION_REQ if
> no other more specific code is applicable.  (For example: if a registration
> failed due to a missing field in REGISTRATION_REQ, the Database should
> still send the REQUIRED  error; if a REGISTRATION_REQ failed due to the
> Device being unauthorized, the Database should still send the UNAUTHORIZED
> error.)****
>
> ** **
>
> Sanjeev: does that address your need sentiment for “a denied registration”?
> ****
>
> ** **
>
> Dan****
>
> ** **
>
> (I have a separate comment about SPECTRUM_USE_NOTIFY, to follow.)****
>
> ** **
>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>
>

-- 
-vince

---

From: "Harasty, Daniel J" <[email-masked]>
Date: Thu, 25 Jul 2013 19:24:22 +0000

Vince,

On your "point 1", I thought I had some good examples in mind.  But, now that you ask, I can't yet make the case that my proposed PAWS "REGISTRATION_ERROR" is any better than other existing PAWS error codes, or a generic "server error".

While the Devices certainly must deal with the possible HTTP 5xx error, I suggest the server should attempt to send a JSONRPC "SERVER ERROR" (-32000).  See: http://www.jsonrpc.org/specification#error_object.  I'd like to recommend that the PAWS spec reference these "standard JSONRPC error codes", and add a statement to the effect of this:

When an error condition exists, a Database SHOULD attempt to use the most specific applicable PAWS error.  When an accurate one is not available, it SHOULD fallback to standard JSONRPC error codes as defined in JSONRPC specifications.  As a last result, the Database MAY send a suitable HTTP 5xx response.

Dan

From: Vincent Chen [mailto:[email-masked]]
Sent: Thursday, July 25, 2013 12:00 PM
To: Sajeev Manikkoth
Cc: Harasty, Daniel J; [email-masked]
Subject: Re: [paws] response to REGISTRATION_REQ

Dan, Sajeev,

I was assuming that general "server errors" would be handled at the HTTP layer with 5xx codes.

2. SPECTRUM_USE_NOTIFY. What would the device do differently if it did get an error?
  I was assuming that this is a async notify, fire-and-forget, from the perspective of the device

-vince

On Thu, Jul 25, 2013 at 8:35 AM, Sajeev Manikkoth <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel,

First of all thank you very much for streamlining my comments, and splitting it into separate email topics. May be I need to take care of it next time..

Yes, the semantic you suggest here also can be the solution. My point was, an authorized master's request also can fail, because of load at database, or due to request semantic error.
As SPECTRUM_USE_NOTIFY also can fall in such a category, I was suggesting a generic response accepted/denied.

Best Regards,
Sajeev

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Harasty, Daniel J
Sent: Thursday, July 25, 2013 8:35 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [paws] response to REGISTRATION_REQ

Sanjeev mentioned:

From: [email-masked]<mailto:[email-masked]>
Sent: Thursday, July 25, 2013 10:31 AM
[...]
5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have repsonses like accepted/denied by database?
[...]

Dan

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

--
-vince

---

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

Dan,

Great suggestion. I was also about to propose -32000.

I will update the draft if there are no objects.

-vince

On Thu, Jul 25, 2013 at 12:24 PM, Harasty, Daniel J
<[email-masked]>wrote:

> Vince,****
>
> ** **
>
> On your “point 1”, I thought I had some good examples in mind.  But, now
> that you ask, I can’t yet make the case that my proposed PAWS
> “REGISTRATION_ERROR” is any better than other existing PAWS error codes, or
> a generic “server error”.****
>
> ** **
>
> While the Devices certainly must deal with the possible HTTP 5xx error, I
> suggest the server should attempt to send a JSONRPC “SERVER ERROR”
> (-32000).  See: http://www.jsonrpc.org/specification#error_object.  I’d
> like to recommend that the PAWS spec reference these “standard JSONRPC
> error codes”, and add a statement to the effect of this:****
>
> ** **
>
> When an error condition exists, a Database SHOULD attempt to use the most
> specific applicable PAWS error.  When an accurate one is not available, it
> SHOULD fallback to standard JSONRPC error codes as defined in JSONRPC
> specifications.  As a last result, the Database MAY send a suitable HTTP
> 5xx response.****
>
> ** **
>
> Dan****
>
> ** **
>
> ** **
>
> *From:* Vincent Chen [mailto:[email-masked]]
> *Sent:* Thursday, July 25, 2013 12:00 PM
> *To:* Sajeev Manikkoth
> *Cc:* Harasty, Daniel J; [email-masked]
> *Subject:* Re: [paws] response to REGISTRATION_REQ****
>
> ** **
>
> Dan, Sajeev,****
>
> ** **
>
> layer with 5xx codes.****
>
> ** **
>
> 1. For REGISTRATION_REQ, what error conditions should we be capturing?****
>
>    - Some internal error, but can try again later?****
>
> ** **
>
> an error?****
> perspective of the device****
>
> ** **
>
> -vince****
>
> ** **
>
> On Thu, Jul 25, 2013 at 8:35 AM, Sajeev Manikkoth <
> [email-masked]> wrote:****
>
> Hi Daniel,****
>
>  ****
>
> https://www.ietf.org/mailman/listinfo/paws****
>
>
>
> ****
>
> ** **
>
> --
> -vince ****
>

-- 
-vince

---

From: [email-masked]
Date: Fri, 26 Jul 2013 22:03:08 +0530

Hi Vince,

My point was not HTTP server errors, but errors which arises out of the PAWS
semantics scope.

1.  For REGISTRATION_REQ, I have 2 points. One its response should also
include 'rulesetInfo:RulesetInfo     as  required' parameter. Second, its
response can have accepted/not accepted kind of semantics. It may add some
complexity, if we want to process all the different error conditions, but a
binary semantics may help the Master in its operation.

2. . SPECTRUM_USE_NOTIFY is not mere a fire and forget notification, instead
a request/response transaction was my understanding. A possible case where a
DB can reject the SPECTRU_USE request is: the spectrum which the Master
device intend to use is no longer been available, as the Primary spectrum
user is back on to operation, and DB wanted to mark it as no longer
available. May be rare but it can happen. And if the Master device gets such
an error from DB, it should pick any other available spectrum, and notify
again or sent a fresh AVAIL_SPECTRUM request to the DB. 

Thanks and Regards,

Sajeev

From: Vincent Chen [mailto:[email-masked]] 
Sent: Thursday, July 25, 2013 9:30 PM
To: Sajeev Manikkoth
Cc: Harasty, Daniel J; [email-masked]
Subject: Re: [paws] response to REGISTRATION_REQ

Dan, Sajeev,

-vince

On Thu, Jul 25, 2013 at 8:35 AM, Sajeev Manikkoth
<[email-masked]> wrote:

Hi Daniel,

Best Regards,

Sajeev

Sanjeev mentioned:

[...]

[...]

Dan

 

-- 
-vince

---

From: Vincent Chen <[email-masked]>
Date: Fri, 26 Jul 2013 10:10:59 -0700

Sajeev,

On Fri, Jul 26, 2013 at 9:33 AM, <[email-masked]> wrote:

>  Hi Vince,****
>
> ** **
>
> My point was not HTTP server errors, but errors which arises out of the
> PAWS semantics scope.****
>
> ** **
>
> binary semantics may help the Master in its operation.****
>
> ** **
>
> 2. . SPECTRUM_USE_NOTIFY is not mere a fire and forget notification,
> instead a request/response transaction was my understanding. A possible
> case where a DB can reject the SPECTRU_USE request is: the spectrum which
> the Master device intend to use is no longer been available, as the Primary
> spectrum user is back on to operation, and DB wanted to mark it as no
> longer available. May be rare but it can happen. And if the Master device
> gets such an error from DB, it should pick any other available spectrum,
> and notify again or sent a fresh AVAIL_SPECTRUM request to the DB.
>

The issue is that if the Device picks any other spectrum and notifies
again, it can still get a negative response.

It seems easier for the Device to just have one set of logic that it
implements periodically:

 - Ask for available spectrum, pick one
 - Pick one and Notify

Rather than:

 - Ask for available spectrum
 - Pick one and notify
 ... some time later ..
 - Notify, get negative response
 - Pick another, get negative response
 ...
 - No more to pick, ask for available spectrum

-vince

> Thanks and Regards,****
> *Sent:* Thursday, July 25, 2013 9:30 PM
>
> *To:* Sajeev Manikkoth

-- 
-vince