Subject: Re: [Netconf] filtering notification streams

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

Martin Bjorklund wrote:
> Tomasz Mikolajczyk <[email-masked]> wrote:
>> Hi,
>>
>> Section 3.4 from the RFC 5277 shows in the XSD schema that the <streams>
>> element MUST appear always once and the <stream> element MUST appear at
>> least once, because NETCONF server has to define always at least
>> "NETCONF"
>> stream. What in your opinion a server should return as a response for
>> the following request:
>>
>> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>     <get>
>>         <filter type="subtree">
>>             <netconf xmlns="urn:ietf:params:xml:ns:netmod:notification">
>>                 <streams/>
>>                 <streams/>
>>             </netconf>
>>         </filter>
>>     </get>
>> </rpc>]]>]]>
>
> The server should return the streams subtree, either once or twice.
> It is a bit unlcear if the "filter output" is supposed to be a proFrom [email-masked]  Mon Dec  1 14:51:15 2008
Date: Mon, 1 Dec 2008 22:51:03 -0000 (GMT)
From: "Tomasz Mikolajczyk" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Importance: Normal
Cc: [email-masked]
Subject: Re: [Netconf] filtering notification streams
Sender: [email-masked]

Martin Bjorklund wrote:
> Tomasz Mikolajczyk <[email-masked]> wrote:
>> Hi,
>>
>> Section 3.4 from the RFC 5277 shows in the XSD schema that the <streams>
>> element MUST appear always once and the <stream> element MUST appear at
>> least once, because NETCONF server has to define always at least
>> "NETCONF"
>> stream. What in your opinion a server should return as a response for
>> the following request:
>>
>> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>     <get>
>>         <filter type="subtree">
>>             <netconf xmlns="urn:ietf:params:xml:ns:netmod:notification">
>>                 <streams/>
>>                 <streams/>
>>             </netconf>
>>         </filter>
>>     </get>
>> </rpc>]]>]]>
>
> The server should return the streams subtree, either once or twice.
> It is a bit unlcear if the "filter output" is supposed to beper
> set or not.  Since it is a subtree filter, it should not return an
> error.

But the rules have to be clear. What in your opinion should return the
server for the following request based on examples from RFC 4741 section
6.4:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get-config>
        <source>
            <running/>
        </source>
        <filter type="subtree">
            <top xmlns="http://example.com/schema/1.2/config">
                <users>
                    <name>root</name>
                    <name/>
                </users>
            </top>
         </filter>
    </get-config>
</rpc>

Is the second occurrence of the "name" should overwrite the first one?

>> Another point. The RFC says in the section 3.2.5.1:
>>
>> "Available event streams for the requesting session are returned in the
>> reply
>> containing the <name> and <description> elements, where the <name>
>> element is mandatory, and its value is unique within the scope of a
>> NETCONF
>> server.  An empty reply is returned if there are no available event
>> streams, due to user-specified filters on the <get> operation."
>>
>> My comments to this:
>> 1) The "replaySupport" node is also mandatory according to the schema
>> 2) Seems that the empty reply doesn't match the schema
>
> The schema describes the conceptual data store, not the PUDs.

It's obvious that is impossible to describe a NETCONF request and response
PDUs, that always differ one another, using the same schema. But it's not
a problem with the XSD limitations.

> /martin

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

 a proper
> set or not.  Since it is a subtree filter, it should not return an
> error.

But the rules have to be clear. What in your opinion should return the
server for the following request based on examples from RFC 4741 section
6.4:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get-config>
        <source>
            <running/>
        </source>
        <filter type="subtree">
            <top xmlns="http://example.com/schema/1.2/config">
                <users>
                    <name>root</name>
                    <name/>
                </users>
            </top>
         </filter>
    </get-config>
</rpc>

Is the second occurrence of the "name" should overwrite the first one?

>> Another point. The RFC says in the section 3.2.5.1:
>>
>> "Available event streams for the requesting session are returned in the
>> reply
>> containing the <name> and <description> elements, where the <name>
>> element is mandatory, and its value is unique within the scope of a
>> NETCONF
>> server.  An empty reply is returned if there are no available event
>> streams, due to user-specified filters on the <get> operation."
>>
>> My comments to this:
>> 1) The "replaySupport" node is also mandatory according to the schema
>> 2) Seems that the empty reply doesn't match the schema
>
> The schema describes the conceptual data store, not the PUDs.

It's obvious that is impossible to describe a NETCONF request and response
PDUs, that always differ one another, using the same schema. But it's not
a problem with the XSD limitations.

> /martin

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: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Dec 2008 08:27:52 +0100 (CET)

"Tomasz Mikolajczyk" <[email-masked]> wrote:
> > It is a bit unlcear if the "filter output" is supposed to be a proper
> But the rules have to be clear.

Of course.  This should be clarified in 4741bis.

> What in your opinion should return the

I think you meant that the request should be:

  <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <get-config>
          <source>
              <running/>
          </source>
          <filter type="subtree">
              <top xmlns="http://example.com/schema/1.2/config">
                  <users>
                    <user>
                      <name>root</name>
                      <name/>
     From [email-masked]  Mon Dec  1 23:28:01 2008
Date: Tue, 02 Dec 2008 08:27:52 +0100 (CET)
To: [email-masked]
From: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] filtering notification streams
Sender: [email-masked]

"Tomasz Mikolajczyk" <[email-masked]> wrote:
> > It is a bit unlcear if the "filter output" is supposed to be a proper
> But the rules have to be clear.

Of course.  This should be clarified in 4741bis.

> What in your opinion should return the

I think you meant that the request should be:

                    <user>
                      <name>root</name>
                      <name/>               </user>
                  </users>
              </top>
           </filter>
      </get-config>
  </rpc>

The fist "name" is a content match node, which means that the "user"s
with the name "root" are selected.  The second "name" is a selection
node, which means that from the users with the name "root", only the
"name" element is selected (the other siblings are suppressed), so
assuming that there is a user called "root", you'd get:

  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
             message-id="101">
    <data>
      <top xmlns="http://example.com/schema/1.2/config">
        <users>
          <user>
            <name>root</name>
          </user>
        </users>
      </top>
    </data>

/martin

                    </user>
                  </users>
              </top>
           </filter>
      </get-config>
  </rpc>

The fist "name" is a content match node, which means that the "user"s
with the name "root" are selected.  The second "name" is a selection
node, which means that from the users with the name "root", only the
"name" element is selected (the other siblings are suppressed), so
assuming that there is a user called "root", you'd get:

  <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
             message-id="101">
    <data>
      <top xmlns="http://example.com/schema/1.2/config">
        <users>
          <user>
            <name>root</name>
          </user>
        </users>
      </top>
    </data>

/martin

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Wed, 03 Dec 2008 13:32:41 +0100

Martin Bjorklund wrote:
> I think you meant tFrom [email-masked]  Wed Dec  3 04:34:45 2008
Date: Wed, 03 Dec 2008 13:32:41 +0100
From: Tomasz Mikolajczyk <[email-masked]>
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] filtering notification streams
Sender: [email-masked]

Martin Bjorklund wrote:
> I think you meant that thhat the request should be:
> 

Thank you.

The section 6.2.1 from RFC 4741 says:
"If namespaces are used, then the filter output will only include elements from the specified namespace."

What about filter input? Question is, whether the server should analyze unknown elements. Assuming that the server has only NETCONF event stream
defined, how the response should look like if an unknown tag is used (i.e. a tag unspecified in the namespace), for instance:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get>
        <filter type="subtree">
            <netconf xmlns="urn:ietf:params:xml:ns:netmod:notification">
                <streams>
                    <stream>
                        <unknown>NETCONF</unknown>
                        <description/>
                    </stream>
                </streams>
            </netconf>
        </filter>
    </get>
</rpc>]]>]]>

Is it adequate to the following request:

                <streams>
                    <stream>
                        <name>unknown</name>
                        <description/>
                    </stream>
                </streams>
            </netconf>
        </filter>
    </get>
</rpc>]]>]]>

Note that data model used for the event streams has slightly different type. It's kind of static model (xml structure is always constant) and
data models used in RFC 4741 are dynamic (xml structure depends on the content of the managed device). In the dynamic DM the generic NETCONF
server cannot predict how the DM may look like, so such "unknown_tag" at the time of the request parsing cannot be treated as unknown. In the
static model it's obvious which tags are known and unknown.

Tomasz

>       <top xmlns="http://example.com/schema/1.2/config">

Thank you.

The section 6.2.1 from RFC 4741 says:
"If namespaces are used, then the filter output will only include elements from the specified namespace."

What about filter input? Question is, whether the server should analyze unknown elements. Assuming that the server has only NETCONF event stream
defined, how the response should look like if an unknown tag is used (i.e. a tag unspecified in the namespace), for instance:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get>
        <filter type="subtree">
            <netconf xmlns="urn:ietf:params:xml:ns:netmod:notification">
                <streams>
                    <stream>
                        <unknown>NETCONF</unknown>
                        <description/>
                    </stream>
                </streams>
            </netconf>
        </filter>
    </get>
</rpc>]]>]]>

Is it adequate to the following request:

                <streams>
                    <stream>
                        <name>unknown</name>
                        <description/>
                    </stream>
                </streams>
            </netconf>
        </filter>
    </get>
</rpc>]]>]]>

Note that data model used for the event streams has slightly different type. It's kind of static model (xml structure is always constant) and
data models used in RFC 4741 are dynamic (xml structure depends on the content of the managed device). In the dynamic DM the generic NETCONF
server cannot predict how the DM may look like, so such "unknown_tag" at the time of the request parsing cannot be treated as unknown. In the
static model it's obvious which tags are known and unknown.

Tomasz

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Dec 2008 09:38:44 +0100 (CET)

Tomasz Mikolajczyk <[email-masked]> wrote:
> What about filter input? Question is, whether the server should analyze unknown
> elements. Assuming that the server has only NETCONF event stream
> defined, how the response should look like if an unknown tag is used (i.e. a
> tag unspecified in the namespace), for instance:
> 

In this case, there's a content match node for the element "unknown",
which won't match, so the result is empty:

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

>             </netcFrom [email-masked]  Thu Dec  4 00:38:55 2008
Date: Thu, 04 Dec 2008 09:38:44 +0100 (CET)

Tomasz Mikolajczyk <[email-masked]> wrote:
> What about filter input? Question is, whether the server should analyze unknown
> elements. Assuming that the server has only NETCONF event stream
> defined, how the response should look like if an unknown tag is used (i.e. a
> tag unspecified in the namespace), for instance:
> 

In this case, there's a content match node for the element "unknown",
which won't match, so the result is empty:

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

>             onf>

Here's a content match node "name" which matches a stream that does not
exist so you'll get the same empty result.

/martin

</netconf>
> </rpc>]]>]]>

Here's a content match node "name" which matches a stream that does not
exist so you'll get the same empty result.

/martin

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Thu, 04 Dec 2008 09:48:43 +0100

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

OK, so that means, that even if a particular part of the filter doesn't belong to the namespace is processed (not just skipped)
and causes that all possibly response data are always filtered out (in case of the content match node)?
That also means that the following filter returns an empty response:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get>
        <filter type="subtree">
            <netconf xmlns="urn:ietf:params:xml:ns:netmod:notification" xmlns:ns="elsewhere">
                <streams>
                    <stream>
                        <ns:defined_elsewhere>NETCONF</ns:defined_elsewhere>
                        <description/>
                    </stream>
                </streams>
            </netconf>
        </filter>
    </get>
</rpc>]]>]]>

, where "elsewhere" is well known namespace defining another data model.

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Thu, 04 Dec 2008 09:48:43 +0100

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Thu, 11 Dec 2008 13:29:10 +0100

Martin Bjorklund wrote:
>> least once, because NETCONF server has to define always at least "NETCONF"

The section 2.1.1 from RFC 5277 says:

"Subscription requests will fail if a filter with invalid syntaxFrom [email-masked]  Thu Dec 11 04:31:44 2008
Date: Thu, 11 Dec 2008 13:29:10 +0100
From: Tomasz Mikolajczyk <[email-masked]>
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] filtering notification streams
Sender: [email-masked]

Martin Bjorklund wrote:
>> least once, because NETCONF server has to define always at least "NETCONF"

The section 2.1.1 from RFC 5277 says:

"Subscription requests will fail if a filter with invalid  is provided or if the
name of a non-existent stream is provided."

What does it mean invalid syntax? If not such syntax that causes XML parser error, this means that it's possible that a filter may be invalid.
Is it coherent with the filtering mechanism in get operation? In the get type operations not matching data are just skipped according to the
known filtering rules.
The above example with the double <streams/> element may be treated as the request with an invalid syntax and returning an error in this case is
acceptable.

>> "Available event streams for the requesting session are returned in the reply
>> element is mandatory, and its value is unique within the scope of a NETCONF

Tomasz

syntax is provided or if the
name of a non-existent stream is provided."

What does it mean invalid syntax? If not such syntax that causes XML parser error, this means that it's possible that a filter may be invalid.
Is it coherent with the filtering mechanism in get operation? In the get type operations not matching data are just skipped according to the
known filtering rules.
The above example with the double <streams/> element may be treated as the request with an invalid syntax and returning an error in this case is
acceptable.

>> "Available event streams for the requesting session are returned in the reply
>> element is mandatory, and its value is unique within the scope of a NETCONF

Tomasz