RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 8 records.

Status: Verified (2)

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

Source of RFC: netconf (ops)

Errata ID: 3980

Status: Verified
Type: Technical

Reported By: Klement Sekera
Date Reported: 2014-05-05
Verifier Name: Benoit Claise
Date Verified: 2015-01-23

Sections 6.2.5 and 6.3

In section 6.3:

OLD:
   The
   algorithm continues until all sibling sets in all subtrees specified
   in the filter have been processed.

In section 6.2.5

OLD:
  o  If any sibling nodes of the selection node are instance identifier
      components for a conceptual data structure (e.g., list key leaf),
      then they MAY also be included in the filter output.

It should say:

In section 6.3:

NEW:

   The 
   algorithm continues until all sibling sets in all subtrees specified
   in the filter have been processed. If any sibling nodes of a node
   are instance identifier components for a conceptual data structure
   (e.g., list key leaf), then they MAY also be included in the filter 
   output.

In section 6.2.5

NEW:

Notes:

The intent is to allow the server to always include the key node values and the wording accidentally does not cover this case.

Here is the OLD/NEW in a more intuitive way:
In section 6.3:

OLD:

The algorithm continues until all sibling sets in all subtrees specified
in the filter have been processed.
NEW:

The algorithm continues until all sibling sets in all subtrees specified
in the filter have been processed. If any sibling nodes of a node
are instance identifier components for a conceptual data structure
(e.g., list key leaf), then they MAY also be included in the filter output.

Implicitly in section 6.2.5 to delete the moved text:

OLD:

If any sibling nodes of the selection node are instance identifier
components for a conceptual data structure (e.g., list key leaf),
then they MAY also be included in the filter output.

NEW:
<void>

Errata ID: 4066

Status: Verified
Type: Technical

Reported By: Andy Bierman
Date Reported: 2014-07-30
Verifier Name: Benoit Claise
Date Verified: 2014-09-22

Section 7.2 says:

If the "operation" attribute is not specified, the
configuration is merged into the configuration datastore.

It should say:

If the "operation" attribute is not specified, then the 
operation applied to the parent data node of the configuration
is used. If no parent data node is available, then the value of 
the <default-operation> parameter is used.  If the 
<default-operation> parameter is not given, the configuration 
is merged into the configuration datastore.

Notes:

sentence in para 6 is not correct.
The default-operation value is used, not the value "merge".

Discussion on the NETCONF mailing list. See http://www.ietf.org/mail-archive/web/netconf/current/msg09169.html

Status: Held for Document Update (4)

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

Source of RFC: netconf (ops)

Errata ID: 3569

Status: Held for Document Update
Type: Editorial

Reported By: Xiang Li
Date Reported: 2013-03-27
Held for Document Update by: Benoit Claise

Section 1.2 says:

   (2)  The Messages layer provides a simple, transport-independent
        framing mechanism for encoding RPCs and notifications.
        Section 4 documents the RPC messages, and [RFC5717] documents
        notifications

It should say:

   (2)  The Messages layer provides a simple, transport-independent
        framing mechanism for encoding RPCs and notifications.
        Section 4 documents the RPC messages, and [RFC5277] documents
        notifications

Notes:

RFC5717 Partial Lock Remote Procedure Call (RPC) for NETCONF
RFC5277 NETCONF Event Notifications

Errata ID: 3821

Status: Held for Document Update
Type: Editorial

Reported By: Jonathan Hansford
Date Reported: 2013-12-06
Held for Document Update by: Benoit Claise
Date Held: 2014-01-13

Section 8.4.1 says:

8.4.1.  Description

The :confirmed-commit:1.1 capability indicates that the server will
support the <cancel-commit> operation and the <confirmed>,
<confirm-timeout>, <persist>, and <persist-id> parameters for the
<commit> operation.  See Section 8.3 for further details on the
<commit> operation.

A confirmed <commit> operation MUST be reverted if a confirming
commit is not issued within the timeout period (by default 600
seconds = 10 minutes).  The confirming commit is a <commit> operation
without the <confirmed> parameter.  The timeout period can be
adjusted with the <confirm-timeout> parameter.  If a follow-up
confirmed <commit> operation is issued before the timer expires, the
timer is reset to the new value (600 seconds by default).  Both the
confirming commit and a follow-up confirmed <commit> operation MAY
introduce additional changes to the configuration.

If the <persist> element is not given in the confirmed commit
operation, any follow-up commit and the confirming commit MUST be
issued on the same session that issued the confirmed commit.  If the
<persist> element is given in the confirmed <commit> operation, a
follow-up commit and the confirming commit can be given on any
session, and they MUST include a <persist-id> element with a value
equal to the given value of the <persist> element.

If the server also advertises the :startup capability, a
<copy-config> from running to startup is also necessary to save the
changes to startup.

If the session issuing the confirmed commit is terminated for any
reason before the confirm timeout expires, the server MUST restore
the configuration to its state before the confirmed commit was
issued, unless the confirmed commit also included a <persist>
element.

If the device reboots for any reason before the confirm timeout
expires, the server MUST restore the configuration to its state
before the confirmed commit was issued.

If a confirming commit is not issued, the device will revert its
configuration to the state prior to the issuance of the confirmed
commit.  To cancel a confirmed commit and revert changes without
waiting for the confirm timeout to expire, the client can explicitly
restore the configuration to its state before the confirmed commit
was issued, by using the <cancel-commit> operation.

It should say:

8.4.1.  Description

The :confirmed-commit:1.1 capability indicates that the server will
support the <cancel-commit> operation, the <confirmed>, <confirm-
timeout>, <persist>, and <persist-id> parameters for the <commit>
operation, and differentiate between a “to be confirmed” <commit>
operation (a “confirmed commit”) and a confirming <commit>
operation. See Section 8.3 for further details on the <commit>
operation.

A confirmed <commit> operation MUST be reverted if a confirming
commit is not issued within the timeout period (by default 600
seconds = 10 minutes). The confirming commit is a <commit> operation
without the <confirmed> parameter and, if successful, cannot be
reverted. The timeout period can be adjusted with the <confirm-
timeout> parameter. If a follow-up confirmed <commit> operation is
issued before the timer expires, the timer is reset to the new value
(600 seconds by default). Both the confirming commit and a follow-up
confirmed <commit> operation MAY introduce additional changes to the
configuration.

If the <persist> element is not given in the confirmed commit
operation, any follow-up commit and the confirming commit MUST be
issued on the same session that issued the confirmed commit. If the
<persist> element is given in the confirmed <commit> operation, a
follow-up commit and the confirming commit can be given on any
session, and they MUST include a <persist-id> element with a value
equal to the given value of the <persist> element.

If the server also advertises the :startup capability, a <copy-
config> from running to startup is also necessary to save the
changes to startup. If the session issuing a sequence of one or more
confirmed commits is terminated for any reason before the confirm
timeout expires, the server MUST restore the configuration to its
state before the sequence of confirmed commits was issued, unless
the last confirmed commit also included a <persist> element.

If the device reboots for any reason before the confirm timeout
expires, the server MUST restore the configuration to its state
before the sequence of confirmed commits was issued.

If a confirming commit is not issued, the device will revert its
configuration to the state prior to the issuance of the first in the
current sequence of confirmed commits. To cancel the current
sequence of confirmed commits and revert changes without waiting for
the confirm timeout to expire, the client can explicitly restore the
configuration to its state before the sequence of confirmed commits
was issued, by using the <cancel-commit> operation.

Notes:

This erratum seeks to clarify the meaning of the term "confirmed commit" for those not familiar with the use of the term within JUNOS. In particular, that the use of "confirmed" is not in the sense of the adjective (meaning "firmly established") but rather that the commit needs to be confirmed. It also emphasises that a "confirming commit" cannot be reverted. Finally it identifies that it is possible to have a sequence of "confirmed commits" prior to a "confirming commit" and that, should no "confirming commit" be received, the configuration will revert to the state prior to the first "confirmed commit" in the sequence.

Errata ID: 3822

Status: Held for Document Update
Type: Editorial

Reported By: Jonathan Hansford
Date Reported: 2013-12-06
Held for Document Update by: Benoit Claise
Date Held: 2014-01-13

Section 8.4.4.1 says:

Description:

      Cancels an ongoing confirmed commit.  If the <persist-id>
      parameter is not given, the <cancel-commit> operation MUST be
      issued on the same session that issued the confirmed commit.

Parameters:

   persist-id:

         Cancels a persistent confirmed commit.  The value MUST be
         equal to the value given in the <persist> parameter to the
         <commit> operation.  If the value does not match, the
         operation fails with an "invalid-value" error.

It should say:

Description:

      Cancels an ongoing sequence of confirmed commits. If the
      <persist-id> parameter is not given, the <cancel-commit>
      operation MUST be issued on the same session that issued the
      sequence of confirmed commits.

Parameters:

   persist-id:

         Cancels a persistent sequence of confirmed commits. The
         value MUST be equal to the value given in the <persist>
         parameter to the <commit> operation. If the value does not
         match, the operation fails with an "invalid-value" error.

Notes:

This erratum seeks to clarify that <cancel-commit> will cancel all configuration changes arising from a sequence of "confirmed commits".

Errata ID: 3823

Status: Held for Document Update
Type: Editorial

Reported By: Jonathan Hansford
Date Reported: 2013-12-06
Held for Document Update by: Benoit Claise
Date Held: 2014-01-13

Section 8.4.5.1 says:

   persist:

         Make the confirmed commit survive a session termination, and
         set a token on the ongoing confirmed commit.

It should say:

   persist:

         Make the confirmed commit survive a session termination,
         and set a token on the ongoing sequence of confirmed
         commits.

Notes:

This erratum seeks to clarify that the use of the "persist" parameter will persist all configuration changes arising from a sequence of "confirmed commits".

Status: Rejected (2)

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

Source of RFC: netconf (ops)

Errata ID: 4544

Status: Rejected
Type: Technical

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.

Errata ID: 4856

Status: Rejected
Type: Technical

Reported By: frank feng
Date Reported: 2016-11-08
Rejected by: Benoit Claise
Date Rejected: 2016-12-20

Section 7.2 says:

config:  A hierarchy of configuration data as defined by one of
         the device's data models.  The contents MUST be placed in an
         appropriate namespace, to allow the device to detect the
         appropriate data model, and the contents MUST follow the
         constraints of that data model, as defined by its capability
         definition.  Capabilities are discussed in Section 8.

It should say:

config:  A hierarchy of configuration data as defined by one or more of
         the device's data models.  The contents MUST be placed in an
         appropriate namespace, to allow the device to detect the
         appropriate data model, and the contents MUST follow the
         constraints of that data model, as defined by its capability
         definition.  Capabilities are discussed in Section 8.

Notes:


--VERIFIER NOTES--
As discussed on the NETCONF mailing list.

Report New Errata



Search RFCs
Advanced Search
×