[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: is a warning really an error?

Kent Watsen wrote:



warnings cannot be returned with <ok/>,
but they can be returned with <data>
true, but my issue is with the <rpc-error> 

The rpc-error element contains the error-severity element.
A 'warning' is just an rpc-error with an error-severity of 'warning'.
There is one report template for errors and warnings.







To highlight the conflict, consider:

1. Is it possible for <commit> to return a warning using <rpc-error>
without signaling that the transaction failed?

If the reply contains only warnings and no errors,
then it succeeded, but maybe not as intended.
Section 8.3.4.1 says: In the Description section: If the device is unable to commit *all of the changes* in the 
	candidate configuration datastore, then the running
configuration
MUST remain unchanged. 
   In the Negative Response section:
	An <rpc-error> element is included in the <rpc-reply> if
the request *cannot be completed* for any reason. 
Thus, I conclude that receiving *any* <rpc-error> means that the request
was not completed and hence the datastore remains unchanged...  Perhaps
this is where the spec can be clarified by adding to the Negative
Response section the following:



I think you are reading the document too literally.




	"However, if all the <rpc-error> element(s) are warnings, then
	 the client should assume that the target datastore was
modified"


You can add this to the issue tracker for RFC 4741 if you want.








2. Is it possible for <edit-config> to return a warning using
<rpc-error> without signaling that the error-options (stop-on-error,
continue-on-error, rollback-on-error) were ignored?


You didn't respond to this one, but I'll go ahead and point out that
section 7.2 says in the Negative Response section:

	An <rpc-error> response is sent if the request cannot be
completed
      for any reason.

Thus, I conclude that if it didn't "complete" then it must have
"stopped" and therefore the specified error-option ("stop-on-error"
being the default) was applied... Perhaps this is where the spec can be
clarified by adding to the Negative Response section the following:


This parameter is for requesting certain error handling behavior.
If an agent receives an unsupported option, then the operation-not-supported
error-tag is returned right away.

The error-option semantics are kind of implementation dependent.
Rather than ramble on about esoteric features of
data modeling frameworks and agent callback architectures,
let's just say that the behavior of continue-on-error
is hard to explain, let alone implement the same way twice.

I interpret this parameter to apply to the 'apply' phase
of the conceptual edit-config operation.
That means the entire PDU has to validate (as much as the
instrumentation checks for) before any of the PDU is applied
for real.  The apply phase can fail due to resource-denied errors
for example.

IMO, the continue-on-error does not require the agent to
accept bad parameter values (i.e., validation phase fails).
You can't get an embedded software engineer to write code
that can knowingly crash the device by allowing certain wrong
parameter values.





	"However, if all the <rpc-error> element(s) are warnings, then
	 the client should assume that the processing did not stop and
	 that the error-option was not applied"



What about continue-on-error?
This is intended to go with the partial operation error report.
IMO, there error-option is always 'applied' if the agent accepts
the operation.  This is probably too simplistic for distributed
or modular agent implementations that only partially support
a given option (like rollback-on-error).

Clearly you have figured out that data-model dependent error handling
for the NETCONF protocol is largely undefined in RFC 4741.
This is partly by design, and partly because NETCONF data modeling
is largely undefined.

(Insert plug here for draft-bierman-ncx-smi-00.txt ;-)








A spec always has room for more clarifications, so I guess it
could be more clear that if all the error-severity values
are 'warning', then the operation did not fail.


Yes, it would also be good to add to section 4.3


It was a mistake for us to put the 'Severity' field into the ad-hoc
template in RFC 4741, Appendix A.  This should have been a dynamic
field, which could be defined for specific RPC methods, like
create-subscription.

This 'feature' should not be used without guidelines of course.
For example, if the parameter was for some resource request, and
the agent granted a lowered resource value instead of rejecting
the entire request, this would be a good use case for a warning.




Thanks,
Kent


Andy

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>