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 protected]] Sent: Thursday, July 25, 2013 9:30 PM To: Sajeev Manikkoth Cc: Harasty, Daniel J; [email protected] 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. 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 protected]> 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 protected] [mailto:[email protected]] On Behalf Of Harasty, Daniel J Sent: Thursday, July 25, 2013 8:35 PM To: [email protected] Subject: [paws] response to REGISTRATION_REQ Sanjeev mentioned: From: [email protected] 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.) _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
