[Nsi-wg] ServiceException needs further details

[Jerry Sobieski]

On 1/3/12 9:15 AM, John MacAuley wrote:
>
> On 2011-12-21, at 5:44 AM, Henrik Thostrup Jensen wrote:
>
> I think we also need a plan with the error codes and their 
> classification. Do we provide the errors in order to tell a user went 
> wrong (in which case a string will suffice), or do we provide error 
> codes so a client can intelligently handle some cases, or both?
>
> The answer is probably the latter, with some semantics for errorId, 
> which can enable the client to automatically classify and potentially 
> recover from the error. The distinction between text and variables are 
> somewhat artifial and only makes sense for missing of invalid 
> parameters. If we assume that the error string is for humans only, the 
> distincition between:
>
> text: Missing parameters: Start time, Dest STP.
>
> and
>
> text: Missing parameters
> variables: ["Start time", "Dest STP"]
>
> Is just unneeded complexity. If a client is missing a parameter, it 
> probably won't be able to change the request and fill it out 
> automatically by looking at the error response. It should just be 
> fixed and send the parameter in the first place.
It seems there are some key "classes" of errors with some relation to 
the stage at which it is generated:
     a) primitive formatting errors (a request primitive is ill-formed),
     b) protocol errors (confuses the state machine/flow chart),
     c) service request processing errors (e.g. Aggregator issues 
between NSAs)
     d) service request resource errors (the uPA/NRM cannot fill the 
request), and
     e) service instance failure errors (an otherwise good service breaks).
Are there other classifications? (I don't recall the details of prior 
discussions on this.)   These classes are listed in order of detection 
...(sort of I think..:-)   So a "service request resource error" 
implicitly means the request was well formed and conformed to protocol, 
and the message was processed to reach an appropriate NSA, but the 
resources required were incorrect or unavailable.   (Note: the order 
above loops - as each message flows from NSA to NSA the gantlet of 
checks repeats)

The order for detecting more detailed error conditions may be less than 
obvious:  If a service resource request is rejected because available 
resources were not available for that user...is this a resource 
unavailable? or unauthorized?  It depends on how you prioritize your 
constraints.   If you prune the constraint based search by authorization 
policy first, and resources remain that are authorized for that user, 
but then the resources needed to reach his particular destination are 
already in use, then this is a "resource unavailable" error - regardless 
of whether other [unauthorized] resources are available and would have 
met the technical requirements for the connection.   Likewise, if the 
technical requirements are used to prune the resources first, and then 
the user fails on authorization of the sole path to his destination, 
then this would generate a "unauthorized" error.   And in either case, 
if the requested time window is blocked, but the path finder failed on 
"resource unavailable" or "unauthorized" then the path finder will 
terminate and the user will not know that his schedule was flawed as 
well.  The request actually had several problems.  (And if you tell a 
path finder to "continue searching" despite missed constraints, your 
search space explodes, and the results (or errors) may not even be 
relevant.)   So we can re-order constraints, but we cannot ignore them.

In general - the universe of possible primitive formulations are 
overwhelmingly "erroneous" in some fashion - only a very few 
intelligently constructed primitives are actually going pass the 
gauntlet to be successful.  So our approach should not be to enumerate 
all possible errors we may encounter, but to classify the errors in some 
broad fashion and communicate that class only.  We can refine some error 
classes to define more specific classes where they may be (a) 
[relatively] frequent/common errors, or (b) expose a key or "critical" 
condition (for the RA or the PA).

just some thoughts...
Jerry