Subject: [Netconf] Clarification about additional attributes at Messages(RPC) layer

From: Shiva Kumar Pathori <[email-masked]>
Date: Tue, 30 Jan 2018 01:47:02 +0530

Hi,
Can somebody clarify below <rpc-reply> sent by the NETCONF server will
break the NETCONF client functionality. Additional attribute information is
shown in RED color.

<rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <top xmlns="http://example.com/schema/1.2/config">
             <interface>
               <name>Ethernet0/0</name>
               <mtu>1500</mtu>
             </interface>
           </top>
         </config>
       </edit-config>
     </rpc>

<rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"

          *xmlns:nc-ext="http://sample.com/netconf/ext
<http://sample.com/netconf/ext>" nc-ext:config-id="1"*>
       <ok/>
     </rpc-reply>

I have just tried with MG SOFT NETCONF browser and worked fine, I think MG
SOFT browser ignored these attributes.

---

From: Kent Watsen <[email-masked]>
Date: Tue, 30 Jan 2018 14:54:35 +0000

I believe that this is allowed by [1], but worry about interoperability due to the "config-id" attribute being a proprietary extension.

[1] https://tools.ietf.org/html/rfc6241#section-4.2

Kent  // contributor

Assuming the namespace prefix is there to support

On 1/29/18, 3:17 PM, "Netconf on behalf of Shiva Kumar Pathori" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi,
Can somebody clarify below <rpc-reply> sent by the NETCONF server will break the NETCONF client functionality. Additional attribute information is shown in RED color.

<rpc message-id="101"

       <edit-config>

         <target>

           <running/>

         </target>

         <config>

           <top xmlns="http://example.com/schema/1.2/config<https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_schema_1.2_config&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nAjM7pDWG7HS1viFkN6mWV_1Ii2GVce-FvEqf3h0gfo&s=LQjMxXfz35-ysUajs_4pgqhw9Cmbna4-0672JlBXzNI&e=>">

             <interface>

               <name>Ethernet0/0</name>

               <mtu>1500</mtu>

             </interface>

           </top>

         </config>

       </edit-config>

     </rpc>

          xmlns:nc-ext="http://sample.com/netconf/ext<https://urldefense.proofpoint.com/v2/url?u=http-3A__sample.com_netconf_ext&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nAjM7pDWG7HS1viFkN6mWV_1Ii2GVce-FvEqf3h0gfo&s=H__4DCa9XJZJTIQ_Ewl7nAey_4XKXSKLAh-48KhPxMI&e=>" nc-ext:config-id="1">

       <ok/>

     </rpc-reply>

I have just tried with MG SOFT NETCONF browser and worked fine, I think MG SOFT browser ignored these attributes.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 30 Jan 2018 10:25:15 -0800

[As contributor]

> On Jan 30, 2018, at 6:54 AM, Kent Watsen <[email-masked]> wrote:
> 
>  
> [1] https://tools.ietf.org/html/rfc6241#section-4.2 <https://tools.ietf.org/html/rfc6241#section-4.2>
Per that section, what is returned is what was originally in the request. The nc-ext is something that has been added in the response, and was not existing in the request.

To Shiva’s question, it is not clear how the clients will react to additional data in the <rpc-reply>. Will they just ignore it, or barf at it?

> On 1/29/18, 3:17 PM, "Netconf on behalf of Shiva Kumar Pathori" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi, 
>            <top xmlns="http://example.com/schema/1.2/config <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_schema_1.2_config&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nAjM7pDWG7HS1viFkN6mWV_1Ii2GVce-FvEqf3h0gfo&s=LQjMxXfz35-ysUajs_4pgqhw9Cmbna4-0672JlBXzNI&e=>">
>              <interface>
>                <name>Ethernet0/0</name>
>                <mtu>1500</mtu>
>              </interface>
>            </top>
>          </config>
>        </edit-config>
>      </rpc>
>  
>           xmlns:nc-ext="http://sample.com/netconf/ext <https://urldefense.proofpoint.com/v2/url?u=http-3A__sample.com_netconf_ext&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nAjM7pDWG7HS1viFkN6mWV_1Ii2GVce-FvEqf3h0gfo&s=H__4DCa9XJZJTIQ_Ewl7nAey_4XKXSKLAh-48KhPxMI&e=>" nc-ext:config-id="1">
>        <ok/>
>      </rpc-reply>
>  
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
[email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Tue, 30 Jan 2018 18:53:45 +0000

Section 4.2 says that "message-id" is mandatory, and that the server MUST
return any additional attributes included in the <rpc> element.  But it doesn't
say anything that limits a server returning even more.

My assumption is that it is allowed.  Specifically, from an XML document
encoding perspective, it is always valid to move "xmlns" prefix declarations
to ancestor elements…

K.  // contributor

On 1/30/18, 1:25 PM, "Mahesh Jethanandani" <[email-masked]<mailto:[email-masked]>> wrote:

[As contributor]

On Jan 30, 2018, at 6:54 AM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

[1] https://tools.ietf.org/html/rfc6241#section-4.2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6241-23section-2D4.2&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=iT-5cpJaklJMJbEVRv4fgPBCu63AMMak0WbYDDMdYts&s=0FHMPEAKMzcNdQB20gJvvoJinRvDVVr13531hZJHbtY&e=>

Kent  // contributor

Hi,

<rpc message-id="101"

       <edit-config>

         <target>

           <running/>

         </target>

         <config>

             <interface>

               <name>Ethernet0/0</name>

               <mtu>1500</mtu>

             </interface>

           </top>

         </config>

       </edit-config>

     </rpc>

       <ok/>

     </rpc-reply>

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=iT-5cpJaklJMJbEVRv4fgPBCu63AMMak0WbYDDMdYts&s=rw5qXFv9bAYyUmvp0t9QdGF7ogdxJrQJWUEdpRzAE4A&e=>

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Shiva Kumar Pathori <[email-masked]>
Date: Wed, 31 Jan 2018 10:46:09 +0530

Do we need to have some mechanism like ietf-yanag-metadata.yang that allows
defining the attributes at data instances so that the clients are aware of
the additional attributes. So that if the client is interested will process
otherwise ignores it.

On 31-Jan-2018 12:23 AM, "Kent Watsen" <[email-masked]> wrote:

> On 1/30/18, 1:25 PM, "Mahesh Jethanandani" <[email-masked]>
> wrote:
>
>
>
> [As contributor]
>
>
>
> I believe that this is allowed by [1], but worry about interoperability
> due to the "config-id" attribute being a proprietary extension.
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6241-23section-2D4.2&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=iT-5cpJaklJMJbEVRv4fgPBCu63AMMak0WbYDDMdYts&s=0FHMPEAKMzcNdQB20gJvvoJinRvDVVr13531hZJHbtY&e=>
>
>
>
> Per that section, what is returned is what was originally in the request.
> The nc-ext is something that has been added in the response, and was not
> existing in the request.
>
>
>
> To Shiva’s question, it is not clear how the clients will react to
> additional data in the <rpc-reply>. Will they just ignore it, or barf at it?
>
>
>
>
>
> Kent  // contributor
>
>
>
>
>
> On 1/29/18, 3:17 PM, "Netconf on behalf of Shiva Kumar Pathori" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
> Hi,
>
>           *xmlns:nc-ext="http://sample.com/netconf/ext <https://urldefense.proofpoint.com/v2/url?u=http-3A__sample.com_netconf_ext&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=nAjM7pDWG7HS1viFkN6mWV_1Ii2GVce-FvEqf3h0gfo&s=H__4DCa9XJZJTIQ_Ewl7nAey_4XKXSKLAh-48KhPxMI&e=>" nc-ext:config-id="1"*>
>
>        <ok/>
>
>      </rpc-reply>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=iT-5cpJaklJMJbEVRv4fgPBCu63AMMak0WbYDDMdYts&s=rw5qXFv9bAYyUmvp0t9QdGF7ogdxJrQJWUEdpRzAE4A&e=>
>
>
>
> Mahesh Jethanandani
>
> [email-masked]
>
>
>
>

---

From: Shiva Kumar Pathori <[email-masked]>
Date: Wed, 31 Jan 2018 10:57:08 +0530

I mentioned the module name wrongly,  it is ietf-yang-metadata

On 31-Jan-2018 10:46 AM, "Shiva Kumar Pathori" <[email-masked]> wrote:

> Do we need to have some mechanism like ietf-yanag-metadata.yang that
> allows defining the attributes at data instances so that the clients are
> aware of the additional attributes. So that if the client is interested
> will process otherwise ignores it.
>
>> I have just tried with MG SOFT NETCONF browser and worked fine, I think
>> MG SOFT browser ignored these attributes.
>>
>>
>>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 31 Jan 2018 08:55:56 +0100 (CET)

> encoding perspective, it is always valid to move "xmlns" prefix declarations

Yes, but not necessarily other attributes, like in this case.

However, the XSD in RFC 6241 has:

     <xs:complexType name="rpcReplyType">
       ...
       <xs:anyAttribute processContents="lax"/>
     </xs:complexType>

which means that in the XML layer, any attribute in any namespace can
be sent.  This does not necessarily mean that the higher layers will
accept such attributes, but I would be very surprised if an
implementation somehow rejected a rpc-reply b/c it didn't understand
all attributes.

/martin