Sajeev,
On Fri, Jul 26, 2013 at 9:33 AM, <[email protected]> wrote: > 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. > 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,**** > > 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 **** > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
