RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 14 records.

Status: Verified (4)

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: 5790
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Mahesh Jethanandani
Date Reported: 2019-07-23
Verifier Name: Ignas Bagdonas
Date Verified: 2019-08-20

In Sections 7.8, 7.9, and 8.4.1

OLD:

7.8.  <close-session>

   Description:  Request graceful termination of a NETCONF session.

      When a NETCONF server receives a <close-session> request, it will
      gracefully close the session.  The server will release any locks
      and resources associated with the session and gracefully close
      any associated connections.  Any NETCONF requests received after
      a <close-session> request will be ignored.

   Positive Response:  If the device was able to satisfy the request, an
      <rpc-reply> is sent that includes an <ok> element.

   Negative Response:  An <rpc-error> element is included in the
      <rpc-reply> if the request cannot be completed for any reason.

   Example:

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

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

NEW

7.8.  <close-session>

   Description:  Request graceful termination of a NETCONF session.

      When a NETCONF server receives a <close-session> request, it will
      gracefully close the session.  The server will release any locks
      and resources associated with the session and gracefully close any
      associated connections.  Any NETCONF requests received after a
      <close-session> request will be ignored.

      For details on what happens if a NETCONF server receives a 
      <close-session> request while processing a confirmed commit,
      please refer to Section 8.4.

   Positive Response:  If the device was able to satisfy the request, an
      <rpc-reply> is sent that includes an <ok> element.

   Negative Response:  An <rpc-error> element is included in the
      <rpc-reply> if the request cannot be completed for any reason.

   Example:

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

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

OLD

7.9.  <kill-session>

   Description:  Force the termination of a NETCONF session.

      When a NETCONF entity receives a <kill-session> request for an
      open session, it will abort any operations currently in process,
      release any locks and resources associated with the session, and
      close any associated connections.

      If a NETCONF server receives a <kill-session> request while
      processing a confirmed commit (Section 8.4), it MUST restore the
      configuration to its state before the confirmed commit was issued.

      Otherwise, the <kill-session> operation does not roll back
      configuration or other device state modifications made by the
      entity holding the lock.

   Parameters:

      session-id:  Session identifier of the NETCONF session to be
         terminated.  If this value is equal to the current session ID,
         an "invalid-value" error is returned.

   Positive Response:  If the device was able to satisfy the request, an
      <rpc-reply> is sent that includes an <ok> element.

   Negative Response:  An <rpc-error> element is included in the
      <rpc-reply> if the request cannot be completed for any reason.


   Example:

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

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

NEW

7.9.  <kill-session>

   Description:  Force the termination of a NETCONF session.

      When a NETCONF entity receives a <kill-session> request for an
      open session, it will abort any operations currently in process,
      release any locks and resources associated with the session, and
      close any associated connections.

      For details on what happens if a NETCONF server receives a 
      <kill-session> request while processing a confirmed commit,
      please refer to Section 8.4.

      Otherwise, the <kill-session> operation does not roll back
      configuration or other device state modifications made by the
      entity holding the lock.

   Parameters:

      session-id:  Session identifier of the NETCONF session to be
         terminated.  If this value is equal to the current session ID,
         an "invalid-value" error is returned.

   Positive Response:  If the device was able to satisfy the request, an
      <rpc-reply> is sent that includes an <ok> element.

   Negative Response:  An <rpc-error> element is included in the
      <rpc-reply> if the request cannot be completed for any reason.


   Example:

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

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


Section 8.4.1

OLD:

   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.

NEW:

   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, unless the confirmed commit 
   also included a <persist> element, in which case the server MAY
   continue the confirmed commit procedure.

Notes:

This Errata modifies three different sections, Sections 7.8, 7.9 and 8.4.1. The changes in Section 7.8 and 7.9 defer the description of the behavior of confirmed commit to Section 8.4.1.

Errata ID: 3980
Status: Verified
Type: Technical
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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

Errata ID: 5388
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Jonathan Hansford
Date Reported: 2018-06-11
Verifier Name: Ignas Bagdonas
Date Verified: 2019-10-18

Section 8.3.4.2 says:

8.3.4.2.  <discard-changes>

   If the client decides that the candidate configuration is not to be
   committed, the <discard-changes> operation can be used to revert the
   candidate configuration to the current running configuration.

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

   This operation discards any uncommitted changes by resetting the
   candidate configuration with the content of the running
   configuration.

It should say:

8.3.4.2.  <discard-changes>

   Description:

         If the client decides that the candidate configuration is not
         to be committed, the <discard-changes> operation can be used to
         revert the candidate configuration to the current running
         configuration.

         This operation discards any uncommitted changes by resetting
         the candidate configuration with the content of the running
         configuration.

   Positive Response:

         If the device was able to satisfy the request, an <rpc-reply>
         is sent that contains an <ok> element.

   Negative Response:

         An <rpc-error> element is included in the <rpc-reply> if the
         request cannot be completed for any reason.

   Example:

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

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

Notes:

RFC 6241 section 1.1 includes the following two definitions:

o protocol operation: A specific remote procedure call, as used
within the NETCONF protocol.

o remote procedure call (RPC): Realized by exchanging <rpc> and
<rpc-reply> messages.

Positive and negative responses are detailed for all instances of an operation within the RFC with the exception of <discard-changes>.

Section 8.3.4.2 identifies <discard-changes> as an operation, and appendices A and C identify "rollback-failed" as an error-tag to be used when the "Request to roll back some configuration change (via rollback-on-error or <discard-changes> operations) was not completed for some reason."

This change clarifies that <discard-changes> requires an <rpc-reply>.

Status: Held for Document Update (5)

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: 5401
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Rohit R Ranade
Date Reported: 2018-06-21
Held for Document Update by: Ignas Bagdonas
Date Held: 2019-10-18

Section 8.9.1 says:

   The XPath expression MUST return a node set.  If it does not return a
   node set, the operation fails with an "invalid-value" error.

It should say:

   The XPath expression MUST return a node set.  If it does not return a
   node set, the operation fails with an <error-tag> value of 
   "invalid-value".

Notes:

It is unclear what is the meaning of "invalid-value" "error". Since the xpath will be part of "select" attribute, we can assume that a server can return a "bad-attribute" error-tag and having error-message indicating invalid-value for the attribute. This clarifies the <error-tag> to be used in such cases.
In other places, where error-tag has been mentioned, it is clear that "invalid-value" <error-tag> must be used.

Errata ID: 3569
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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> or <persist-id>
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, unless the last
confirmed commit also included a <persist> or <persist-id> element.
 
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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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 (5)

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.

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

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.

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

Reported By: Jernej Tuljak
Date Reported: 2023-08-31
Rejected by: Mahesh Jethanandani
Date Rejected: 2024-05-10

Section 4.3. says:

     <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <rpc-error>
         <error-type>rpc</error-type>
         <error-tag>missing-attribute</error-tag>
         <error-severity>error</error-severity>
         <error-info>
           <bad-attribute>message-id</bad-attribute>
           <bad-element>rpc</bad-element>
         </error-info>
       </rpc-error>
     </rpc-reply>

It should say:

     <nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <nc:rpc-error>
         <nc:error-type>rpc</nc:error-type>
         <nc:error-tag>missing-attribute</nc:error-tag>
         <nc:error-severity>error</nc:error-severity>
         <nc:error-info>
           <nc:bad-attribute>message-id</nc:bad-attribute>
           <nc:bad-element>nc:rpc</nc:bad-element>
         </nc:error-info>
       </nc:rpc-error>
     </nc:rpc-reply>

Notes:

The original error response is referring to the NETCONF messages layer attribute "message-id", which does not belong to any XML namespace. The response is not properly encoding xs:QName values of elements "bad-attribute" and "bad-element" by placing them both into the default XML namespace. Proposed new text (while verbose) ensures that the values are placed into their respective proper XML namespaces.
--VERIFIER NOTES--
The original error response is valid when validated against netconf XSD defined in RFC 4741.

Errata ID: 5443
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Jonathan Natale
Date Reported: 2018-07-27
Rejected by: Ignas Bagdonas
Date Rejected: 2019-10-18

Section 4.4 says:

The <ok> element is sent in <rpc-reply> messages if no errors or
warnings occurred during the processing of an <rpc> request, and no
data was returned from the operation.

It should say:

The <ok> element is sent in <rpc-reply> messages if
and only if
no errors or
warnings occurred during the processing of an <rpc> request, and no
data was returned from the operation.

Notes:

I have been informed that an <ok> element should not include any errors or warnings, even in the event of the associated operation completing because the error's severity was only at warning level).
--VERIFIER NOTES--
Rejected based on WG mailing list discussion: https://mailarchive.ietf.org/arch/msg/netconf/nQYVm8sm5pZamtRAIhbcB9cOuos

Errata ID: 5596
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Jonathan Hansford
Date Reported: 2019-01-09
Rejected by: Ignas Bagdonas
Date Rejected: 2019-10-19

Section 7.5 says:

      The duration of the lock is defined as beginning when the lock is
      acquired and lasting until either the lock is released or the
      NETCONF session closes.  The session closure can be explicitly
      performed by the client, or implicitly performed by the server
      based on criteria such as failure of the underlying transport,
      simple inactivity timeout, or detection of abusive behavior on the
      part of the client.  These criteria are dependent on the
      implementation and the underlying transport.

It should say:

      The duration of the lock is defined as beginning when the lock is
      acquired and lasting until either the lock is released or the
      NETCONF session closes.  The session closure can be explicitly
      performed by the client, or implicitly performed by the server
      based on criteria such as failure of the underlying transport,
      simple inactivity timeout, or detection of abusive behavior on the
      part of the client.  These criteria are dependent on the
      implementation and the underlying transport. Note that a lock
      associated with a persistent confirmed commit will be released if
      the NETCONF session closes and, if required, a new lock will have
      to be acquired.

Notes:

A persistent confirmed commit can survive a session termination, however any lock on that same session cannot. If a new session is established between the client and server, the client will need to acquire new locks if it wishes to protect the ongoing persistent confirmed commit.
--VERIFIER NOTES--
Rejected based on WG mailing list discussion: https://mailarchive.ietf.org/arch/msg/netconf/lNr91W5aK-abxDaqzadftjoE2Pg

Report New Errata



Advanced Search