Network Configuration Protocol (NETCONF)
RFC 6241

Note: This ballot was opened for revision 10 and is now closed.

(Ron Bonica) Yes

Comment (2011-03-01 for -)
Rob Enns has left Juniper Networks. We need an updated affiliation for him.

(David Harrington) (was Discuss) Yes

Comment (2011-03-01)
1) copyright in yang module needs updating.

2) appendix F doesn't mention dropping the local file requirement for URLs, 

3) terminology should probably define username, not user. It is doubtful username is commonly referred, since it did not exist in 1.0.

4) I found the use of RFC2119 laniguage rather inconsistent. Some uses of "can" probbaly should have been MAY. Some uses of "are" probbaly should have been MUST, to ensure interoperability.

5) I support Lars' Discuss. There is no requirement to use a transport protocol that provides congestion control. If a transport is used that does not already provide congestion control, then the NC transport should provide congestion control. It is RECOMMENDED to use an existing transprt standard that provides congestion control.

Alexey Melnikov (was Discuss) Yes

Comment (2011-03-05)
1.3.  Capabilities

   A NETCONF capability is a set of functionality that supplements the
   base NETCONF specification.  The capability is identified by a
   uniform resource identifier (URI).

A normative reference ("[5]") is needed here.

3.  XML Considerations

   All NETCONF messages MUST be well-formed XML, encoded in UTF-8.

A Normative reference to UTF-8 is needed here.

4.3.  <rpc-error> Element

   error-tag:  Contains a string identifying the error condition.  See
      Appendix A for allowed values.

Is the list of error conditions extensible? If yes, where can they be found?

7.8.  <close-session>

   Negative Response:

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

How is this possible? What can the client do next if the operation fails?

7.9.  <kill-session>

Comment: I am missing some text here about authorization to kill other sessions.
Is any NETCONF session A can kill any session B?

I think this is covered by the Security Considerations, but a reader wouldn't
find this information until much later in the document.

8.1.  Capabilities Exchange

   A server receiving a <session-id> element MUST close the NETCONF
   session.  Similarly, a client that does not receive a <session-id>
   element in the server's <hello> message MUST close the NETCONF

Do you mean by sending <close-session>?

I am also agreeing with David's DISCUSS points # 1 and # 2, and I also think that Peter's Comment point # 1 is worth being DISCUSS level.

(Dan Romascanu) Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2011-03-03)
Some comments from Ari Keränen:

4.3.  <rpc-error> Element

Shouldn't the "t" namespace be defined in the error-path examples?

7.9.  <kill-session>

There is no discussion on who is allowed to kill whose sessions. I'd assume user is allowed to kills his own sessions (i.e., sessions associated with the same NETCONF username), but how about other sessions? If this is out of scope for this document, could at least say that it "depends on local policy".  <get-config>, <edit-config>, <copy-config>, and <validate>

       <get-config> <!-- any NETCONF operation -->

Is really *any* operation (including ones defined in future documents) allowed here, or just one of the operations mentioned in the title? The text seems to imply the latter, but the example the former.

8.4.1.  Description

The confirmed-commit functionality is unclear. One paragraph (before the current 2nd paragraph) really explaining how this works would be helpful. That is, when/why would one send confirmed commit and what kind of messages/parameters you need at each stage.  <validate>

         A validate operation can fail for any of the following reasons:

Would it be OK to fail validation for some other reason?  <delete-config>

   The :url capability modifies the <delete-config> operation to accept
   the <url> element as the value of the <target> parameters.

What should the server do if it gets URL in the delete-config? Delete the (local copy of the) config retrieved from the address pointed by the URL? Delete the file pointed by the URL?

Appendix C.  YANG Module for NETCONF Protocol Operations

      reference "RFC XXXX, section YYY";

Should add the correct section number (multiple times in the Appendix C).

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Lars Eggert) (was Discuss) No Objection

(Adrian Farrel) No Objection

Comment (2011-03-02 for -)
I am entering a No Objection position on the basis of the Yes ballots fromt the Ops ADs.

Appendix C seems to claim that "this value is pre-determined by RFC 4741" but since 4741 is now obsoleted (by this document) you should find some new text.

(Russ Housley) No Objection

Comment (2011-03-01 for -)
  Please add a sentence to the Abstract that indicates that this
  document obsoletes RFC 4741.

(Tim Polk) No Objection

Comment (2011-03-02 for -)

2.2.  paragraph 1 - last sentence is awkward.   In general connections are
encrypted "in" an algorithm (e.g., AES) or "using" a protocol (e.g., TLS).

s/encrypted in TLS [16] or SSH [14]/encrypted using TLS [16] or SSH [14]/


3.1.  Namespace

Should this text reference the namespace base:1.1 instead of base:1.0 ??


The example in 6.2.2 Attribute Match Expressions references containment nodes
and selection nodes, which are described in 6.2.3 and 6.2.4, respectively.

It might be cleaner to reorder as 6.2.2 Containment Nodes, 6.2.3 Selection Nodes,
and 6.2.4 Attribute Match Expressions so that concepts are introduced sequentially


Section 8.1  The following sentence implies that clients can attack other sessions
by guessing session-ids:

A server receiving a <session-id> element MUST close the NETCONF

I believe the intent was as follows:

A server receiving a <hello> element that includes a <session-id> element
MUST ignore the session-id and close the NETCONF session.

If that is the intent, I suggest the latter wording.


Section 9.  Security Considerations, paragraph five states:

   Configuration information is by its very nature sensitive.  Its
   transmission in the clear and without integrity checking leaves
   devices open to classic eavesdropping attacks.  Configuration
   information often contains passwords, user names, service
   descriptions, and topological information, all of which are
   sensitive.  Because of this, this protocol SHOULD be implemented
   carefully with adequate attention to all manner of attack one might
   expect to experience with other management interfaces.

The clause "and without integrity checking" is not relevant to eavesdropping attacks.

s/classic eavesdropping attacks/classic eavesdropping and false data injection attacks/

(Peter Saint-Andre) No Objection

Comment (2011-03-02 for -)
1. DTDs are forbidden (presumably you mean internal or external DTD subsets in accordance with section 2.8 of the XML specification). What about comments, processing instructions, and internal or external entity references?

2. In Section 6.2.5, 'for which the <name> element is equal to "fred"' is more precisely expressed as 'for which XML character data of the <name> element is equal to "fred"'. (The same text occurs in Section 6.4.5.)

3. Section 6.4.3 states:

   In a real data model, the <company-info> would not
   likely be returned with the list of users for a particular host or

Why not?

4. In Section 7.5, is the server allowed to terminate a lock for reasons other than session closure? If not, it appears than an entity could maintain a lock indefinitely.

5. In Appendix B, it seems that some of the enumerated datatypes could be changed from xs:string to something more restrictive, such as xs:NMTOKEN (e.g., error types, error tags, error severity, edit operation type).

(Robert Sparks) No Objection

(Sean Turner) No Objection