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
