RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 6241, "Network Configuration Protocol (NETCONF)", June 2011

Note: This RFC has been updated by RFC 7803, RFC 8526

Source of RFC: netconf (ops)

Errata ID: 4544
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Keshava Bhat
Date Reported: 2015-11-24
Rejected by: Benoit Claise
Date Rejected: 2015-12-01

Section 6.1 says:

   XML subtree filtering is a mechanism that allows an application to
   select particular XML subtrees to include in the <rpc-reply> for a
   <get> or <get-config> operation.  A small set of filters for
   inclusion, simple content exact-match, and selection is provided,
   which allows some useful, but also very limited, selection
   mechanisms.  The server does not need to utilize any data-model-
   specific semantics during processing, allowing for simple and
   centralized implementation strategies.

   Conceptually, a subtree filter is comprised of zero or more element
   subtrees, which represent the filter selection criteria.  At each
   containment level within a subtree, the set of sibling nodes is
   logically processed by the server to determine if its subtree and
   path of elements to the root are included in the filter output.

   Each node specified in a subtree filter represents an inclusive
   filter.  Only associated nodes in underlying data model(s) within the
   specified datastore on the server are selected by the filter.  A node
   is selected if it matches the selection criteria and hierarchy of
   elements given in the filter data, except that the filter absolute
   path name is adjusted to start from the layer below <filter>.

   Response messages contain only the subtrees selected by the filter.
   Any selection criteria that were present in the request, within a
   particular selected subtree, are also included in the response.  Note
   that some elements expressed in the filter as leaf nodes will be
   expanded (i.e., subtrees included) in the filter output.  Specific
   data instances are not duplicated in the response in the event that
   the request contains multiple filter subtree expressions that select
   the same data.

It should say:

   XML subtree filtering is a mechanism that allows an application to
   select particular XML subtrees to include in the <rpc-reply> for a
   <get> or <get-config> operation.  A small set of filters for
   inclusion, simple content exact-match, and selection is provided,
   which allows some useful, but also very limited, selection
   mechanisms.  The server does not need to utilize any data-model-
   specific semantics during processing, allowing for simple and
   centralized implementation strategies.

   Conceptually, a subtree filter is comprised of zero or more element
   subtrees, which represent the filter selection criteria.  At each
   containment level within a subtree, the set of sibling nodes is
   logically processed by the server to determine if its subtree and
   path of elements to the root are included in the filter output.

   Each node specified in a subtree filter represents an inclusive
   filter.  Only associated nodes in underlying data model(s) within the
   specified datastore on the server are selected by the filter.  A node
   is selected if it matches the selection criteria and hierarchy of
   elements given in the filter data, except that the filter absolute
   path name is adjusted to start from the layer below <filter>.

   Response messages contain only the subtrees selected by the filter.
   Any selection criteria that were present in the request, within a
   particular selected subtree, are also included in the response.  Note
   that some elements expressed in the filter as leaf nodes will be
   expanded (i.e., subtrees included) in the filter output.  Specific
   data instances are not duplicated in the response in the event that
   the request contains multiple filter subtree expressions that select
   the same data.

   When a node in the subtree filter is unknown, the server sends a 
   <rpc-error> as reply with "unknown-element" error-tag. In case of
   <get-config> RPC, if the subtree filter contains a node that is
   not a configuration node, the server sends <rpc-error> as reply
   with "bad-element" error-tag. 

Notes:

It is not clear in the RFC what a netconf server should do when
it encounters invalid nodes in a subtree filter in case of
get/get-config RPC.
--VERIFIER NOTES--
I think the text is clear - it says that if the element "exactly
matches a corresponding portion of the supported data model" it is
included. If it is not even in the server's schema, it doesn't match
the "supported data model".

XPath filtering works the same way; elements that are not part of the
data model simply won't match, without producing an error.

Report New Errata



Advanced Search