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

From: Tomasz Mikolajczyk <[email-masked]>
Date: Wed, 03 Dec 2008 17:49:10 +0100

Andy Bierman wrote:
> Tomasz Mikolajczyk wrote:
>> 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:
>>
> 
> 
> Using the NETCONF standard means accepting the limitations
> of the standard, which in this case is imposed by 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">
>>             <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>
>>
> 
> 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.

I noticed, that similar "double abstraction" is used in the model for notification event streams and in the examples of the notification filters
(section 5.1 RFC 5277).

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

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: Tomasz Mikolajczyk <[email-masked]>
Date: Wed, 03 Dec 2008 17:49:10 +0100

Tomasz