RE: is a warning really an error?

["Kent Watsen" <kwatsen@juniper.net>]

> warnings cannot be returned with <ok/>,
> but they can be returned with <data>

true, but my issue is with the <rpc-error> 




> > 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:

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




> > 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:

	"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"




> 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


Thanks,
Kent


--
Kent Watsen
Software Architect
Juniper Networks

--
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/>