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.

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

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.

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."

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>
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>

It should say:

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.
If a NETCONF server receives a <close-session> request while
processing a confirmed commit (Section 8.4) for that session,
regardless of whether the confirmed commit included a <persist>
element, it MUST restore the configuration to its state before the
confirmed commit was issued.
Otherwise, the <close-session> operation does not roll back
configuration or other device state modifications made by the
entity holding the lock.
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>
7.9. <kill-session>
Description: Force the termination of a NETCONF session.
When a NETCONF server 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) for that session,
regardless of whether the confirmed commit included a <persist>
element, 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>

Notes:

Clarifies the behaviour for both <close-session> and <kill-session> when that session has an outstanding confirmed commit, regardless of whether the confirmed commit includes a <persist> element.

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.

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.

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".

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.

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.