Subject: [Netconf] Fw: Jari Arkko's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSSand COMMENT)

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Thu, 3 Mar 2011 19:35:19 +0100

FYI and comments

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: "The IESG" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Thursday, March 03, 2011 6:05 PM
Subject: Jari Arkko's Discuss on draft-ietf-netconf-4741bis-09: (with DISCUSSand 
COMMENT)

Jari Arkko has entered the following ballot position for
draft-ietf-netconf-4741bis-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The document does not seem to specify who is allowed kill sessions. Shouldn't 
that be specified?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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