Subject: is a warning really an error?

From: "Kent Watsen" <[email-masked]>
Date: Thu, 23 Aug 2007 14:19:35 -0700

All,

The spec specifies that an <rpc-error> can be returned to report a
warning, but warnings generally do not terminate processing while errors
do and <rpc-error> are returned whenever a "request cannot be completed
for any reason"

To highlight the conflict, consider:

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

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?

Given this ambiguity, should "warning" should be removed from the spec?

Thanks,
Kent

--
Kent Watsen
Software Architect
Juniper Networks

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 23 Aug 2007 14:59:56 -0700

> do and <rpc-error> are returned whenever a "request cannot be completed

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

The spec is sort of silent on the use of warnings,
mostly because none are defined in the RFC.

But the XSD for <rpc-reply> is correct, and there is no
restriction on the setting of the error-severity field.
I think it is okay to use 'warning' instead of 'error'
for a pre-defined error condition, especially if the
agent is ignoring or correcting for the error.

It is not really okay to define new error-tag values,
because the error-app-tag should be used instead,
added to existing errors.

> without signaling that the transaction failed?

If the reply contains only warnings and no errors,
then it succeeded, but maybe not as intended.

> Given this ambiguity, should "warning" should be removed from the spec?

no -- it is not compliant to RFC 4741 to ignore the error-option parameter.
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.

> Kent

Andy

---

From: "Kent Watsen" <[email-masked]>
Date: Fri, 24 Aug 2007 15:27:12 -0700

> but they can be returned with <data>

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

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

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

> 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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Aug 2007 16:01:45 -0700

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

> Response section the following:

I think you are reading the document too literally.

> 	 the client should assume that the target datastore was

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

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

> 	 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 ;-)

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

Andy

---

From: "Kent Watsen" <[email-masked]>
Date: Fri, 24 Aug 2007 16:50:08 -0700

> I think you are reading the document too literally.

Yes, I tend to read specifications that way  ;^)

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

I will add all of these items to the issue tracker

> This is partly by design, and partly because NETCONF data modeling

I don't see this as being dependent on the data-model as I'm only caring
if the target datastore was modified on not

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

Ever so subtle!  ;)

Best,
Kent

--
Kent Watsen
Software Architect
Juniper Networks

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Aug 2007 17:00:52 -0700

> if the target datastore was modified on not

The partial-operation error-tag is intended to provide this information.
if any <ok-element> values are returned, then the target was modified.
Partial-operation is intended to be included in addition to the primary
error-tag report(s).

Andy