Subject: Re: [Netconf] rpc-error

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 28 Nov 2008 13:30:11 +0100

Martin Bjorklund wrote:

> 5.  Stream the <data>, and send <rpc-error> inline in the <data>
>       element.  Like this:
> 
>          <data>
>            <interfaces xmlns="http://example.com/interface";>
>              <interface>
>                <name<eth0</name>
>                <mtu>1500</mtu>
>                ...
>              </interface>
>              <interface>
>                <name<eth0</name>
>                <nc:rpc-error>
>                  <nc:error-message>
>                    Could not retrieve interface stats: EIO
>                  </nc:error-message>
>                  ...
>                </nc:rpc-error>
>              </interface>
>              ...
>            </interfaces xmlns="http://example.com/interface";>
>           </data>
> 
>       Clients have to be prepared to parse these errors in the middle
>       of the <data> stream.  It is not obvious from the spec if this
>       is allowed or not.  The XSD seems to indicate that this is not
>       allowed (the group "rpcResponse" could be reused inline in the
>       data, but it is not perfect.)
> 

Putting rpc-errors inline in the <data> would also mean thatFrom [email-masked]  Fri Nov 28 04:32:06 2008
Date: Fri, 28 Nov 2008 13:30:11 +0100
From: Tomasz Mikolajczyk <[email-masked]>
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] rpc-error
Sender: [email-masked]

Martin Bjorklund wrote:

> 5.  Stream the <data>, and send <rpc-error> inline in the <data>
>       element.  Like this:
> 
>          <data>
>            <interfaces xmlns="http://example.com/interface";>
>              <interface>
>                <name<eth0</name>
>                <mtu>1500</mtu>
>                ...
>              </interface>
>              <interface>
>                <name<eth0</name>
>                <nc:rpc-error>
>                  <nc:error-message>
>                    Could not retrieve interface stats: EIO
>                  </nc:error-message>
>                  ...
>                </nc:rpc-error>
>              </interface>
>              ...
>            </interfaces xmlns="http://example.com/interface";>
>           </data>
> 
>       Clients have to be prepared to parse these errors in the middle
>       of the <data> stream.  It is not obvious from the spec if this
>       is allowed or not.  The XSD seems to indicate that this is not
>       allowed (the group "rpcResponse" could be reused inline in the
>       data, but it is not perfect.)
> 

Putting rpc-errors inline in the <data> would also mea the
following request is allowed:

<nc:rpc message-id="101" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
    <nc:get>
        <nc:filter>
            <interfaces xmlns="http://example.com/interface">
                <interface>
                    <name/>
                    <netconfNS:rpc-error
xmlns:netconfNS="urn:ietf:params:xml:ns:netconf:base:1.0">
                        <netconfNS:error-type/>
		    </netconfNS:rpc-error>
                </interface>
            </interfaces>
        </nc:filter>
    </nc:get>
</nc:rpc>

It's an example of the namespace selection. Does it make sense?

Tomasz

The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: [email-masked].
Thank You.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

n that the
following request is allowed:

<nc:rpc message-id="101" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
    <nc:get>
        <nc:filter>
            <interfaces xmlns="http://example.com/interface">
                <interface>
                    <name/>
                    <netconfNS:rpc-error
xmlns:netconfNS="urn:ietf:params:xml:ns:netconf:base:1.0">
                        <netconfNS:error-type/>
		    </netconfNS:rpc-error>
                </interface>
            </interfaces>
        </nc:filter>
    </nc:get>
</nc:rpc>

It's an example of the namespace selection. Does it make sense?

Tomasz

The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: [email-masked].
Thank You.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 28 Nov 2008 17:55:31 +0100

Hello,
We have some devices for which buffering is just not possible, they don't have the memory. An 
50 USD price increase could kill the product I was told.
Balazs

Tomasz Mikolajczyk wrote:
> Putting rpc-errors inline in the <data> would also mean that the

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 28 Nov 2008 17:55:31 +0100

Hello,

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Nov 2008 09:55:35 -0800

> following request is allowed:

Any filter request possible is allowed.
There is no such thing as an error in an
well-formed filter request.  The filter either
returns data or not, but never causes an error.

If there was some agent that actually stored <rpc-error>
elements somewhere in its database, then it is possible
a filter could return it.

However, inline <rpc-error> generation has nothing
to do with <get> filtering, since the operation filters
against the database, and inline errors are generated
in the PDU, not the database.

> It's an example of the namespace selection. Does it make sense?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Nov 2008 09:55:35 -0800

Andy

---

From: "Tomasz Mikolajczyk" <[email-masked]>
Date: Fri, 28 Nov 2008 23:58:54 -0000 (GMT)

Hi,

> 50 USD price increase could kill the product I was told.

I also don't think such buffering is good. I'm just considering advantages
and disadvantages of different possibilities.

>> <nc:rpc message-id="101"
>> xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
>>     <nc:get>
>>         <nc:filter>
>> The information contained in this e-mail and in any attachments is
>> confidential and is designated solely for the attention of the intended
>> recipient(s). If you are not an intended recipient, you must not use,
>> disclose, copy, distribute or retain this e-mail or any part thereof. If
>> you have received this e-mail in error, please notify the sender by
>> return e-mail and delete all copies of this e-mail from your computer
>> system(s).

Tomasz

The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: [email-masked].
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Tomasz Mikolajczyk" <[email-masked]>
Date: Fri, 28 Nov 2008 23:58:54 -0000 (GMT)

Hi,

Tomasz