RFC Errata
Found 5 records.
Status: Reported (2)
RFC 8639, "Subscription to YANG Notifications", September 2019
Source of RFC: netconf (ops)
Errata ID: 8073
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Andy Bierman
Date Reported: 2024-08-11
Section 4 says:
identity configurable-encoding {
description
"If a transport identity derives from this identity, it means
that it supports configurable encodings. An example of a
configurable encoding might be a new identity such as
It should say:
identity configurable-encoding {
base transport;
description
"If a transport identity derives from this identity, it means
that it supports configurable encodings. An example of a
configurable encoding might be a new identity such as
Notes:
This identity is incorrectly located in the section 'identities for encodings'
It is actually an identity for the 'transport' leaf.
The base is missing making it incorrect
(page 44)
Errata ID: 8725
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Roman Janota
Date Reported: 2026-01-30
Section 2.5.1 says:
.........
: start :-.
:.......: |
create .---modify-----.----------------------------------.
| | | |
V V .-------. ....... .---------.
.----[evaluate]--no--->|invalid|-delete->: end :<-delete-|concluded|
| '-------' :.....: '---------'
|-[evaluate]--no-(2). ^ ^ ^
| ^ | | | |
yes | '->unsupportable delete stop-time
| modify (subscription- (subscription- (subscription-
| | terminated*) terminated*) concluded*)
| | | | |
(1) | (3) (4) (5)
| .---------------------------------------------------------------.
'-->| valid |
'---------------------------------------------------------------'
Legend:
Dotted boxes: subscription added or removed via configuration
Dashed boxes: states for a subscription
[evaluate]: decision point on whether the subscription
is supportable
(*): resulting subscription state change notification
Figure 8: Publisher's State Machine for a Configured Subscription
A subscription in the "valid" state may move to the "invalid" state
in one of two ways. First, it may be modified in a way that fails a
re-evaluation. See (2) in the diagram. Second, the publisher might
determine that the subscription is no longer supportable. This could
be because of an unexpected but sustained increase in an event
stream's event records, degraded CPU capacity, a more complex
referenced filter, or other subscriptions that have usurped
resources. See (3) in the diagram. No matter the case, a
"subscription-terminated" notification is sent to any receivers in
the "active" or "suspended" state. A subscription in the
"valid" state may also transition to the "concluded" state via (5) if
a configured stop time has been reached. In this case, a
"subscription-concluded" notification is sent to any receivers in the
"active" or "suspended" state. Finally, a subscription may be
deleted by configuration (4).
It should say:
.........
: start :-.
:.......: |
create .---modify-----.----------------------------------.
| | | |
V V .-------. ....... .---------.
.----[evaluate]--no--->|invalid|-delete->: end :<-delete-|concluded|
| '-------' :.....: '---------'
|-[evaluate]--no-(2). ^ ^ ^
| ^ | | | |
yes | '->unsupportable delete stop-time
| modify (subscription- (subscription- (subscription-
| | terminated*) terminated*) completed*)
| | | | |
(1) | (3) (4) (5)
| .---------------------------------------------------------------.
'-->| valid |
'---------------------------------------------------------------'
Legend:
Dotted boxes: subscription added or removed via configuration
Dashed boxes: states for a subscription
[evaluate]: decision point on whether the subscription
is supportable
(*): resulting subscription state change notification
Figure 8: Publisher's State Machine for a Configured Subscription
A subscription in the "valid" state may move to the "invalid" state
in one of two ways. First, it may be modified in a way that fails a
re-evaluation. See (2) in the diagram. Second, the publisher might
determine that the subscription is no longer supportable. This could
be because of an unexpected but sustained increase in an event
stream's event records, degraded CPU capacity, a more complex
referenced filter, or other subscriptions that have usurped
resources. See (3) in the diagram. No matter the case, a
"subscription-terminated" notification is sent to any receivers in
the "active" or "suspended" state. A subscription in the
"valid" state may also transition to the "concluded" state via (5) if
a configured stop time has been reached. In this case, a
"subscription-completed" notification is sent to any receivers in the
"active" or "suspended" state. Finally, a subscription may be
deleted by configuration (4).
Notes:
Figure 8 and the accompanying text incorrectly refer to a notification named "subscription-concluded". This notification is not defined in the document.
The correct notification name is "subscription-completed", as formally defined in the YANG module (Section 4) and described in Section 2.7.6 ("subscription-completed"). The text and diagram in Section 2.5.1 are updated to match the YANG definition.
Status: Held for Document Update (2)
RFC 8639, "Subscription to YANG Notifications", September 2019
Source of RFC: netconf (ops)
Errata ID: 6211
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: kent watsen
Date Reported: 2020-06-22
Held for Document Update by: Robert Wilton
Date Held: 2024-01-12
Section 7 says:
A specification for a transport MUST identify any encodings that are supported. If a configured subscription's transport allows different encodings, the specification MUST identify the default encoding.
It should say:
A specification for a transport MUST identify any encodings that are supported. If a configured subscription's transport allows different encodings, the specification MUST identify the default encoding, or provide a mechanism whereby supported encodings can be discovered.
Notes:
https://mailarchive.ietf.org/arch/msg/netconf/XBpoFqtRynfc0zaRggMEiEMBW2M/
Errata ID: 8427
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alex Huang Feng
Date Reported: 2025-05-22
Held for Document Update by: Mahesh Jethanandani
Date Held: 2025-07-29
Section 4 says:
uses subscription-policy-modifiable {
augment "target/stream" {
description
"Adds additional objects that can be modified by an RPC.";
leaf stream {
type stream-ref {
require-instance false;
}
mandatory true;
description
"Indicates the event stream to be considered for
this subscription.";
}
It should say:
uses subscription-policy-modifiable {
augment "target/stream" {
description
"Adds additional objects that can be modified by an RPC.";
leaf stream {
when "/sn:streams/sn:stream";
type stream-ref {
require-instance false;
}
mandatory true;
description
"Indicates the event stream to be considered for
this subscription.";
}
Notes:
The mandatory leaf "stream" is an augmentation on "target/stream".
Section 7.17 of RFC7950 states that any augmentation of mandatory leaves need a "when" statement:
If the augmentation adds mandatory nodes (see Section 3) that
represent configuration to a target node in another module, the
augmentation MUST be made conditional with a "when" statement. Care
must be taken when defining the "when" expression so that clients
that do not know about the augmenting module do not break.
Or else, the "mandatory" statement needs to be removed.
No objections received from the WG to mark it for "Held for Document Update". In addition Andy wrote:
"I am not sure this augment-when rule from RFC 7950 really applies here.
The augmenting leaf is in the same module, and all the objects were produced as a first release.
The added when-stmt is needed if the mandatory node is added in a new release of the same module
or if it is defined in a separate module.
IMO this should be held for document update for clarification."
Status: Rejected (1)
RFC 8639, "Subscription to YANG Notifications", September 2019
Source of RFC: netconf (ops)
Errata ID: 6366
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Muly Ilan
Date Reported: 2020-12-24
Rejected by: RFC Editor
Date Rejected: 2021-01-19
Section 4. says:
feature subtree {
description
"This feature indicates support for YANG subtree filtering.";
reference
"RFC 6241: Network Configuration Protocol (NETCONF),
Section 6";
}
feature supports-vrf {
description
"This feature indicates that a publisher supports VRF
configuration for configured subscriptions. VRF support for
dynamic subscriptions does not require this feature.";
reference
"RFC 8529: YANG Data Model for Network Instances,
Section 6";
}
It should say:
feature subtree {
description
"This feature indicates support for YANG subtree filtering.";
reference
"RFC 6241: Network Configuration Protocol (NETCONF),
Section 6";
}
feature supports-vrf {
description
"This feature indicates that a publisher supports VRF
configuration for configured subscriptions. VRF support for
dynamic subscriptions does not require this feature.";
reference
"RFC 8529: YANG Data Model for Network Instances,
Section 6";
}
Notes:
In the HTML version the two hyperlinks "Section 6" (for 'subtree' feature and for 'supports-vrf' feature) point to wrong RFCs.
--VERIFIER NOTES--
This is regarding the link generated in the rfc2html output, not the RFC itself (https://www.rfc-editor.org/rfc/rfc8639.txt).