[Nmc-wg] Result codes in MDM RRD MA and LS - action from last conf call

[Michael Bischoff]

clienterror/not_acceptable/ - not further specified means it's a bad
request but we don't know why(not sure if we should allow that)

clienterror/not_acceptable/bad_request/
clienterror/not_acceptable/bad_request/event_type_not_allowed - I'm
using this as an example because it was used before not because I
agree with this error formulation as it tells me nothing?

clienterror/not_acceptable/needs_authorization (perhaps something
better would be information required to do authorization was not
supplied (but thats kinda long ;)
clienterror/not_acceptable/request_too_large

clienterror/too_many_requests - this is when one client(ip?) sends too
many request - hence it being client error, there could also be a
servererror variant which means the server is too busy/being DoS-ed

etc.

My original question was do you or Roman envision these translating
directly to a single result code in the new model, or would these be
encoded as different codes for different situations.

They should probably map - given that they make sense in the first
place - to a single result code _with a common 'base'_(the left size
of / exmple <BASE>/<MORE_SPECIFIC_BASE>/result_code I suppose you
could call it parent too if you view it as a tree of values.

Michael


On Thu, May 13, 2010 at 4:43 PM, romradz at man.poznan.pl
<romradz at man.poznan.pl> wrote:
>
>>
>> Moving to the new model will be difficult because meanings of errors
>> may overlap. Let's take 3 examples mentioned above. We can assign them to
>>
>> clienterror/bed_request, clienterror/event_type_not_allowed,
>> clienterror/not_acceptable
>>
>> but this one:
>>
>> clienterror/bed_request, clienterror/event_type_not_allowed,
>> clienterror/bed_request
>>
>> also provides true info about error situations.
>>
>>
>> I'm thinking that maybe we should say that the first part of result code
>> URL is standard but the second part is not controled by NMC.
>>
>>
>> Standard parts of result codes:
>>   http://perfsonar.net/status/informational/
>>   http://perfsonar.net/status/successful/
>>   http://perfsonar.net/status/redirection/
>>   http://perfsonar.net/status/clienterror/
>>   http://perfsonar.net/status/servererror/
>>
>> Example of complete result code:
>>   http://perfsonar.net/status/informational/something_which_is_proposed_by_service_maintainer_or_owner
>
>
> Still thinking about it :) Pieces in result code like successful,
> clienterror, servererror are not enough for us for automatic
> categorization done by a receiver (e.g. client app)? Second part of result
> code would be just human readable. Do our client apps use detailed result
> code information for automatic actions? If we needed a more detailed
> result code for a specific automatic action we could add it to NMC.
>
> Roman
>
>
>>
>>
>> Cheers,
>> Roman
>>
>> _______________________________________________
>> Nmc-wg mailing list
>> Nmc-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/nmc-wg
>>
> _______________________________________________
> Nmc-wg mailing list
> Nmc-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nmc-wg
>