Subject: Re: [Netconf] handling invalid XML tag name

From: "Tomasz Mikolajczyk" <[email-masked]>
Date: Mon, 1 Dec 2008 12:03:18 -0000 (GMT)

Phil Shafer wrote:
> "Tomasz Mikolajczyk" writes:
>>However, in spite of this there is also a possibility that a wrong value
>>may be passed as an "xml-name", but I think this case should be correctly
>>handled by the reader of such data.
>
> If we speak in xml and you send me bad xml, the correct thing would
> be to flag it as bad xml and either let you know or kill the session
> and let someone else know (syslog).
>
> Thanks,
>  Phil

IMO, killing the session is not a good way to react on invalid XML. Client
may send valid XML, for example:

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

and as a result, if XML response has invalid structure, a session is
closed. It may be a little surprise for the client.

Regards,
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: Mon, 1 Dec 2008 12:03:18 -0000 (GMT)

Regards,
Tomasz

---

From: Phil Shafer <[email-masked]>
Date: Mon, 1 Dec 2008 08:23:55 -0500

>closed. It may be a little surprise for the client.

If a client has a protocol issue, one would expect the session to
be terminated.  If a client has a content issue, one would expect
to receive an error.

The question is: which case does invalid XML belong in.  Since the
protocol is encoded in XML, I see invalid XML as a serious client
side issue from which the server cannot reasonable recover.

So I would consider this a protocol error and terminate the session.
This allows the application developer to notice the error and fix
it, without expecting the server to divine the client's intent.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 1 Dec 2008 08:23:55 -0500

Thanks,
 Phil

---

From: "Tomasz Mikolajczyk" <[email-masked]>
Date: Mon, 1 Dec 2008 23:12:29 -0000 (GMT)

> it, without expecting the server to divine the client's intent.

Handling invalid XML sent by a client is no a big deal. The XML parser
automatically detects it and the rpc-error describing exactly a reason
(pointing to the error position in the request) may be enough to notice
the client. Worse if server sends invalid XML, and it may be treated as a
bug in the server and means for example wrong translation of the cli names
into xml names (that you mentioned in your post earlier).

Tomasz

---

From: "Tomasz Mikolajczyk" <[email-masked]>
Date: Mon, 1 Dec 2008 23:12:29 -0000 (GMT)

Tomasz

---

From: "James Balestriere (jbalestr)" <[email-masked]>
Date: Tue, 2 Dec 2008 12:00:28 +0800

Going back and re-reading RFC4741, section 4, I would have to agree with
Phil;
however, like a few others, I have used the ]]>]]> for my framing. 
It allows me  to decouple my SSH layer from my Netconf layer and get
better
performance and modularity, and allows my sessions to survive a bad XML
request.

If we use the XML tags for framing we will end up with a more complex
state machine
handling the SSH character interrupts. At a minimum you would have to
handle the tags
{</rpc>, <rpc ...../> </rpc-reply>, <rpc-reply ... /> } as well as the
nesting.
It is the nesting which is the problem 
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <rpc xmlns="rpc.com" rpc="rpc"><rpc:rpc xmlns:rpc="rpc-reply.com"
rpc:rpc="rpc">rpc</rpc:rpc></rpc>
</rpc>
unlikely, but possible inside some data model we carry, 
which requires a fairly complex state machine to determine the framing.
Should we reserve "rpc" and "rpc-reply" so they can't be embedded inside
the message ?

It also requires session hangup on bad XML, which would surprise me if I
were a user.
I would rather the Netconf server give me an error response to indicate
bad XML and where/why
the XML is bad rather than just hangup. It would be a real pain for my
users to have to
turn on debuging on their network boxes to diagnose XML framing errors.

James.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Phil Shafer
> Sent: Tuesday, 2 December 2008 12:24 AM
> To: Tomasz Mikolajczyk
> Cc: NETCONF
> Subject: Re: [Netconf] handling invalid XML tag name
> 

[email-masked]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Errors-To: [email-masked]

Going back and re-reading RFC4741, section 4, I would have to agree with
Phil;
however, like a few others, I have used the ]]>]]> for my framing. 
It allows me  to decouple my SSH layer from my Netconf layer and get
better
performance and modularity, and allows my sessions to survive a bad XML
request.

If we use the XML tags for framing we will end up with a more complex
state machine
handling the SSH character interrupts. At a minimum you would have to
handle the tags
{</rpc>, <rpc ...../> </rpc-reply>, <rpc-reply ... /> } as well as the
nesting.
It is the nesting which is the problem 
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <rpc xmlns="rpc.com" rpc="rpc"><rpc:rpc xmlns:rpc="rpc-reply.com"
rpc:rpc="rpc">rpc</rpc:rpc></rpc>
</rpc>
unlikely, but possible inside some data model we carry, 
which requires a fairly complex state machine to determine the framing.
Should we reserve "rpc" and "rpc-reply" so they can't be embedded inside
the message ?

It also requires session hangup on bad XML, which would surprise me if I
were a user.
I would rather the Netconf server give me an error response to indicate
bad XML and where/why
the XML is bad rather than just hangup. It would be a real pain for my
users to have to
turn on debuging on their network boxes to diagnose XML framing errors.

James.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Phil Shafer
> Sent: Tuesday, 2 December 2008 12:24 AM
> To: Tomasz Mikolajczyk
> Cc: NETCONF
> Subject: Re: [Netconf] handling invalid XML tag name
>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Dec 2008 08:38:06 +0100 (CET)

Hi James,

> Going back and re-reading RFC4741, section 4, I would have to agree with

Which words in section 4 are you referring to?

One sentence that I guess can be interpreted this way is

   The <rpc-reply> message is sent in response to an <rpc> operation.

So what is an "<rpc> operation" - specifically, does it cover broken
XML?  Is this an <rpc> operation:

  ]]>]]>
  <rpc>
    <reboot/>
  ]]>]]>

it's invalid XML obviously, and it doesn't have the message-id
attribute.  What about this:

  ]]>]]>
  <get/>
  ]]>]]>

where the <rpc> element is missing.

Do you expect a <rpc-reply> is this case?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Dec 2008 08:38:06 +0100 (CET)

Hi James,

  ]]>]]>
  <rpc>
    <reboot/>
  ]]>]]>

  ]]>]]>
  <get/>
  ]]>]]>

/martin

---

From: "James Balestriere (jbalestr)" <[email-masked]>
Date: Tue, 2 Dec 2008 17:21:49 +0800

In Section 1.1 we have 
 The RPC layer provides a simple, transport-independent framing
       mechanism for encoding RPCs.  Section 4 documents this protocol.

Section 4 goeson to say,
NETCONF  peers use <rpc> and <rpc-reply> elements to provide transport
   protocol-independent framing of NETCONF requests and responses.

The keyword is "framing"
SSH itself has no framing definition, so from reading all this it
implies 
that NETCONF  must be providing the framing. Nowhere in RFC4741 do I see
 ]]>]]> explicitly called out as the framing delimiter. 

My preference is to have ]]>]]> defined as the explicit framing
delimiter 
in the absence of transport  defined framing.

All your examples are very good and higlight why you would want to use 
]]>]]> instead of relying on the XML framing.
You should add the additional use case
<rpc message-id="101" > 
  <wrong>
</rpc> 
Is it even valid to use the message-id when the XML is badly framed ?

For all these scenarios I would take advantage of the ]]>]]> and send
and <rpc-reply> to all of them because that is the only container for
rpc-error. 
If message-id can be extracted from the original XML then it can be
used. 
The example on page 14 shows that message-id is optional in a response.

The issue I have with using XML and a schema to define your framing
means that
if your XML does not comply with the schema then you can't properly
frame the 
message and you can't even have the sequence in the example on page 14
because
the rpc is not framed properly. The only <rpc-reply>'s would be
operational errors.

Take your examples and strip out the ]]>]]> as was suggested earlier in
this thread.
What happens with this

   <rpc>
     <reboot/>

In the absence of the </rpc>, When do you decide to stop waiting for
more characters ?
You would eventually have to timeout SSH and  hang up the session.  

What about
   <rpc>
     <reboot/>

<rpc message-id="101" > 
  <wrong>
</rpc> 

What exactly would we receive ? This is why I agree with Phil in that if
we strictly
use <rpc> as the framing we really would be better off just hanging up
the session
when the XML goes bad.

However, what I actually do is use the ]]>]]> for my framing delimter
and and send
rpc-error on unknown XML. (This NETCONF server perspective) I let the
client work
out what to do with the rpc-error. If it is a human user pasting XML
into an SSH
session then they get useful info.

James.

> From: Martin Bjorklund [mailto:[email-masked]] 
> Sent: Tuesday, 2 December 2008 6:38 PM
> To: James Balestriere (jbalestr)
> Cc: [email-masked]; [email-masked]

---

From: "James Balestriere (jbalestr)" <[email-masked]>
Date: Tue, 2 Dec 2008 17:21:49 +0800

In Section 1.1 we have 

Section 4 goeson to say,

The keyword is "framing"

   <rpc>
     <reboot/>

What about
   <rpc>
     <reboot/>

<rpc message-id="101" > 
  <wrong>
</rpc> 

James.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Dec 2008 11:32:00 +0100

On Tue, Dec 02, 2008 at 05:21:49PM +0800, James Balestriere (jbalestr) wrote:
 
> delimiter in the absence of transport defined framing.

The sequence ]]>]]> is an SSH specific framing delimiter and there is
no need to make this a feature for all transports. It espcapes me why
anymore would use ]]>]]> in the SOAP mapping or the BEEP mapping or in
other future transport mappings that preserve application layer
message boundaries.

For me, if I were to change something, I would raise the question
whether ]]>]]> can be removed from the SSH transport mapping. There
are event driven implementations that do not really need it and on the
other hand there are implementations that screw up if ]]>]]> is
received somewhere in the payload due to a lack of proper quoting
mechanisms. But strictly speaking, this should be discussed once RFC
4742 is up for revision, which is not the case yet as far as I know.
 
> This is why I agree with Phil in that if we strictly use <rpc> as
> the framing we really would be better off just hanging up the
> session when the XML goes bad.

If an implementation receives garbage but can recover framing
synchronization, an error should be generated. If an implementation
can't recover framing or attempts to recover framing fail, there is
nothing one can do other than closing the transport.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Dec 2008 11:32:00 +0100

/js