Subject: [netmod] E.1 <rpc-error> details

From: Andy Bierman <[email-masked]>
Date: Mon, 25 Aug 2008 07:04:55 -0700

Hi,

E.1.  Error Message for Data that Violates a YANG unique Statement:

    If a NETCONF operation would result in configuration data where a
    unique constraint is invalidated, the following error is returned:

      Tag:            operation-failed
      Error-app-tag:  data-not-unique
      Error-info:     <non-unique>: Contains an instance identifier which
                      points to a leaf which invalidates the unique
                      constraint. This element is present once for each
                      leaf invalidating the unique constraint.

                      The <non-unique> element is in the YANG
                      namespace ("urn:ietf:params:xml:ns:yang:1"
                      [XXX IANA]).

1) Why is a new <error-info> element needed?
    The existing <bad-element> in the NETCONF NS should be used instead.
    The application knows from the error-app-tag what to expect.

2) One <rpc-error> is generated for each unique-stmt within
    the list which has non-unique leafs.  This is not that clear
    from the Error-info last sentence.

3) There is no way to identify which uniq-stmt failed when a
    list has more than 1 of them defined.  In my implementation,
    I have a <bad-value> element, and I'm stuffing the line number
    of the unique-stmt in there.  (Not that elegant ;-)
    There are no CLRs on unique-stmts.  The same leafs or
    even the same statements can appear any number of times.

4) Identifying the leaf(s) that are not unique is not really
    good enough, and it could be a lot of redundant data.
    What you really want here are the instance identifiers
    of all the list entries which are involved in the
    'duplication collision'.  There will be at least 2 of them.

5) The error-path is problematic.  Does it identify the
    parent of the list entries (may not be any), or
    one of the list entries, or just an object identifier
    (not an instance identifier) of the list definition?

Andy

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Aug 2008 21:17:38 +0200 (CEST)

>     The application knows from the error-app-tag what to expect.

<bad-element> is just a QName.  The <non-unique> is an instance
identifier.  But see below.

>     from the Error-info last sentence.

Yes, but rfc4741 says that an implementation can choose to report the
first error only, and I don't think we should change that here.

>     good enough, and it could be a lot of redundant data.

Since all leafs are identified, you know which unique statement was
invalidated, except if there are more than one exactly equal.  But if
they are equal it doesn't really matter which one of them it was...

Again, see below.

>     'duplication collision'.  There will be at least 2 of them.

You are right.  It is probably better and easier if the error could
contain the two (or more) list instance identifiers, and a reference
to the unique statement.  But as you noted there is no such way
currently.   We would need something like

  unique address {             // address is the identifier
    leafs "a/ip a/port";
  }

If we do this, or something similar, we should also change the
corresponding error.

>     (not an instance identifier) of the list definition?

IMO, error-path is often problematic.  Some time ago you clarified
that the error-path is supposed to start with the '/rpc' node.  So you
might get /nc:rpc/nc:edit-config/nc:config/foo:servers/foo:server.

But what if the operation that made the unique error was <validate>:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <validate>
         <source>
           <candidate/>
         </source>
       </validate>
     </rpc>

If the error-path starts w/ rpc, what would it contain?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 25 Aug 2008 12:33:26 -0700

Martin Bjorklund wrote:
>..

You are right about <bad-element>.  Too bad.
I want as few of these 'extra bits' as possible.

> might get /nc:rpc/nc:edit-config/nc:config/foo:servers/foo:server.

No, actually you would get the instance identifiers for list 'server'

     /nc:rpc/nc:edit-config/nc:config/foo:servers/foo:server[name='fred']

     /nc:rpc/nc:edit-config/nc:config/foo:servers/foo:server[name='barney']

If I just get back 1 leaf ID (foo:knob), I don't know what clashed:

/nc:rpc/nc:edit-config/nc:config/foo:servers/foo:server[name='fred']/foo:knob

> If the error-path starts w/ rpc, what would it contain?

You are right.
For the <validate> operation, the eror-path values
should start at a top-level node in a config-db namespace.
For <edit-config> on 'running' you can include the
path back to 'rpc'.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 26 Aug 2008 19:49:15 +0200

> If the error-path starts w/ rpc, what would it contain?
Why does the error-path start with the RPC? From the message ID we anyway know what the RPC 
was. What additional info do we get?

Let's say I define a custom RPC

rpc reset-interface-config ;

without any input or output. This may change the configuration in a way that violates a "must".
Now error-path should start with /xx:reset-interface-config but should point to a list with a 
must that never appeared in the rpc. Strange.

I always thought error-path points into the datastore independent of the rpc that caused the 
problem.

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Aug 2008 11:36:00 -0700

>> If the error-path starts w/ rpc, what would it contain?

It's really simple.
If the element causing the error is within the
input PDU, then the error-path needs to identify
that element.

It doesn't for this special case, where the error is
not actually contained in the input.

> Why does the error-path start with the RPC? From the message ID we 
> anyway know what the RPC was. What additional info do we get?
> 
> Now error-path should start with /xx:reset-interface-config but should 
> point to a list with a must that never appeared in the rpc. Strange.
> 

No -- it the error is just in the config then
you have to start the error-path from the top
of the config.  Applications should handle either form.

> I always thought error-path points into the datastore independent of the 
> rpc that caused the problem.
> 

No -- not if the element that caused the error
can be identified in the input PDU.

Andy