Network Configuration Protocol (NETCONF)
draft-ietf-netconf-4741bis-10

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.

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


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


8.6.4.1.  <validate>

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

Would it be OK to fail validation for some other reason?


8.8.5.3.  <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).

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

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

  Please add a sentence to the Abstract that indicates that this
  document obsoletes RFC 4741.

(1)

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).
Suggest:

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

(2)

3.1.  Namespace

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

(3)

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

(4)

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

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.

(5)

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.
Suggest:

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