Subject: [Netconf] handling invalid XML tag name

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 28 Nov 2008 16:10:58 +0100

Hi,

Did you consider how a NETCONF server should handle a invalid name of the XML tag. For instance how to handle a parameter called "1port" of the
"interface" class that is defined in a managed device? The following hypothetical response is an invalid XML:

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data>
        <top xmlns="http://example.com/schema/1.2/config">
            <interface>
                <name>eth0</name>
                <1port>1234</1port>    <!-- here -->
            </interface>
        </top>
    </data>
</rpc>

Such parameter's name is valid from the CLI point of view. It means that this kind of "dynamic-like" model may introduce limitations in the
device modeling if someone wants to use NETCONF. The following "static-like" model can solve this problem:

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data>
        <top xmlns="http://example.com/schema/1.2/config">
            <managed_object>
                <name>interface</name>
                <object_instances>
                    <unique_id>eth0</unique_id>
                    <parameters>
                        <param_name>1port</param_name>
                        <param_value>1234</param_value>
                    </parameters>
                </object_instances>
            </managed_object>
        </top>
    </data>
</rpc>

The "dynamic-like" object has limited functionality, because it can show only a dynamic data (instances and parameters with valid values) and
it's hard to show another kind of data like static information about managed_object type.

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: Andy Bierman <[email-masked]>
Date: Fri, 28 Nov 2008 12:08:12 -0800

> device modeling if someone wants to use NETCONF. The following "static-like" model can solve this problem:

Using the NETCONF standard means accepting the limitations
of the standard, which in this case is imposed by XML.

>  From [email-masked]  Fri Nov 28 12:08:21 2008
Date: Fri, 28 Nov 2008 12:08:12 -0800
From: Andy Bierman <[email-masked]>
To: Tomasz Mikolajczyk <[email-masked]>
Cc: NETCONF <[email-masked]>
Subject: Re: [Netconf] handling invalid XML tag name
Sender: [email-masked]

> device modeling if someone wants to use NETCONF. The following "static-like" model can solve this problem:

Using the NETCONF standard means accepting the limitations
of the standard, which in this case is imposed by XML.

>                         <param_value>1234</param_value>

You could internally map the CLI name to some valid XML name,
instead of this sort of double abstraction, but it is just a
DM design choice.

> it's hard to show another kind of data like static information about managed_object type.

Andy

             <parameters>
>                         <param_value>1234</param_value>

You could internally map the CLI name to some valid XML name,
instead of this sort of double abstraction, but it is just a
DM design choice.

> it's hard to show another kind of data like static information about managed_object type.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 28 Nov 2008 16:06:46 -0500

Tomasz Mikolajczyk writes:
>Did you consider how a NETCONF server should handle a invalid name of the XML 
>tag.

Invalid XML is a protocol error.  IIRC this causes the connection
to be terminated.

>For instance how to handle a parameter called "1port" of the
>"interface" class that is defined in a managed device?

In our DDL (the JUNOS DDL is more CLI oriented), we have a property
called "xml-name" for translating CLI into XML.  For example, the
"1port" element could have an xml-name of "one-port".

    attribute 1port {
        xml-name "one-port";
        ...
    }

In YANG, this would work backwards, with your "one-port" leaf having
a "cli-name" property telling the CLI the term to use:

    leaf one-port {
        my:cli-name "1port";
        ...
    }

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Fri, 28 Nov 2008 16:06:46 -0500

attribute 1port {
        xml-name "one-port";
        ...
    }

    leaf one-port {
        my:cli-name "1port";
        ...
    }

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Nov 2008 13:32:34 -0800

> Invalid XML is a protocol error.  IIRC this causes the connection

Why not just an operation-failed error?
I thought we put the SSH EOM marker in the protocol
to maintain message framing and avoid dropping the
session if invalid XML was received.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Nov 2008 13:32:34 -0800

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 29 Nov 2008 11:32:57 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> >> Did you consider how a NETCONF server should handle a invalid name of the
> >> XML tag.

This would be an issue for a 4742bis...  What exactly is the intention
of the EOM marker?  Is it for the reason Andy states, so that the
server can resync if it receives broken XML?  Or is it there for
implementations that have a simple dispatcher so that they can split
the stream into messages easier?

IMO, the EOM is a mistake.  It can occur in valid XML, and it's easy
enough to write a primitive dispatcher for valid XML.  So the only use
case left is the use case that Andy mentions.  But is it really a use
case that needs to be supported?  Why is it important for a server to
resync with a client that sends invalid XML?

Anyway, it's too late to change this, but I think we should at least
agree on how the EOM should be handled.

FWIW, my implementation uses the EOM marker to maintain message
framing.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 29 Nov 2008 11:32:57 +0100 (CET)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Nov 2008 02:41:09 -0800

> FWIW, my implementation uses the EOM marker to maintain message

mine too...

We were told at the time by the XML experts that "]]>" was not
allowed to appear twice in a row in valid XML, because this
is the end CDATA tag.  How is it valid to include this char sequence
without a preceding start CDATA tag?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Nov 2008 02:41:09 -0800

mine too...

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 29 Nov 2008 11:43:23 +0100 (CET)

> without a preceding start CDATA tag?

It's ok in attributes (and comments).  So w/ YANG it's no big deal at
all, since we don't use XML atributes.   And for other DMLs we just
need a CLR - don't ever use this sequence in any attribute value.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 29 Nov 2008 11:43:23 +0100 (CET)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Nov 2008 07:25:46 -0800

> need a CLR - don't ever use this sequence in any attribute value.

That is not what we were told by the XML Directorate.
I don't understand how all those experts could get
something so basic, so completely wrong.

We have attributes in the <rpc> element so we
need a CLR that says "]]>]]>" is not allowed
to appear anywhere inside a NETCONF PDU.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Nov 2008 07:25:46 -0800

Andy

---

From: "Tomasz Mikolajczyk" <[email-masked]>
Date: Sun, 30 Nov 2008 22:47:25 -0000 (GMT)

Andy Bierman wrote:
>> Did you consider how a NETCONF server should handle a invalid name of
>> the XML tag. For instance how to handle a parameter called "1port" of
>> the
>> <rpc-reply message-id="101"
>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>     <data>
>> Such parameter's name is valid from the CLI point of view. It means that
>> this kind of "dynamic-like" model may introduce limitations in the
>> device modeling if someone wants to use NETCONF. The foFrom [email-masked]  Sun Nov 30 14:47:37 2008
Date: Sun, 30 Nov 2008 22:47:25 -0000 (GMT)
From: "Tomasz Mikolajczyk" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Importance: Normal
Cc: NETCONF <[email-masked]>
Subject: Re: [Netconf] handling invalid XML tag name
Sender: [email-masked]

Andy Bierman wrote:
>> Did you consider how a NETCONF server should handle a invalid name of
>> the XML tag. For instance how to handle a parameter called "1port" of
>> the
>> <rpc-reply message-id="101"
>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>     <data>
>> Such parameter's name is valid from the CLI point of view. It means that
>> this kind of "dynamic-like" model may introduce limitations in the
>> device modeling if someone wants to use NETCONF. The followinllowing
>> "static-like" model can solve this problem:
>>
>
>
>> <rpc-reply message-id="101"
>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>     <data>

I agree. In our product we are very flexible in such naming. In spite of
this, there is always a chance that integrator may use a wrong value.

>>
>> The "dynamic-like" object has limited functionality, because it can show
>> only a dynamic data (instances and parameters with valid values) and

By the static data I mean kind of descriptions of the objects, attributes,
etc. Managed resources may have defined different descriptive data, for
instance like these presented via CLI:

> ospf area 10.10.10.10 stub ?
  default-metric     Metric for the default route advertised...
  send-summaries     Propagates summary LSAs into this stub area
  as-boundary        Configures the CSS as an ASB router

In the above command "Configures the CSS as an ASB router" may be treated
as a description of the "as-boundary" attribute and displayed as a
help-hint in a NETCONF client.
Data models used in RFC 4741 don't mention about such data at all. Do you
present them via your Data Models?

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

g
>> "static-like" model can solve this problem:
>>
>
>
>> <rpc-reply message-id="101"
>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>     <data>

I agree. In our product we are very flexible in such naming. In spite of
this, there is always a chance that integrator may use a wrong value.

>>
>> The "dynamic-like" object has limited functionality, because it can show
>> only a dynamic data (instances and parameters with valid values) and

By the static data I mean kind of descriptions of the objects, attributes,
etc. Managed resources may have defined different descriptive data, for
instance like these presented via CLI:

> ospf area 10.10.10.10 stub ?
  default-metric     Metric for the default route advertised...
  send-summaries     Propagates summary LSAs into this stub area
  as-boundary        Configures the CSS as an ASB router

In the above command "Configures the CSS as an ASB router" may be treated
as a description of the "as-boundary" attribute and displayed as a
help-hint in a NETCONF client.
Data models used in RFC 4741 don't mention about such data at all. Do you
present them via your Data Models?

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: Sun, 30 Nov 2008 22:55:02 -0000 (GMT)

Phil Shafer wrote:
>> XML

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.

---

From: "Tomasz Mikolajczyk" <[email-masked]>
Date: Sun, 30 Nov 2008 22:55:02 -0000 (GMT)

---

From: Phil Shafer <[email-masked]>
Date: Sun, 30 Nov 2008 21:13:02 -0500

>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

---

From: Phil Shafer <[email-masked]>
Date: Sun, 30 Nov 2008 21:13:02 -0500

Thanks,
 Phil