Subject: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-01.txt

From: [email-masked]
Date: Tue, 1 Jun 2010 10:30:06 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration Working Group of the IETF.

	Title           : Using the NETCONF Configuration Protocol over Secure Shell (SSH)
	Author(s)       : M. Wasserman, T. Goddard
	Filename        : draft-ietf-netconf-rfc4742bis-01.txt
	Pages           : 10
	Date            : 2010-06-01

This document describes a method for invoking and running the NETCONF
protocol within a Secure Shell (SSH) session as an SSH subsystem.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-rfc4742bis-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 1 Jun 2010 10:35:10 -0700

FYI --

I believe this version contains all of the changes that we have agreed  
to make to rfc4742-bis.  Martin and Juergen, you raised most of the  
issues with the -00 version -- could you check to make sure that you  
are satisfied with the changes I've made to address them?

If I didn't miss anything, I think this document should be ready for  
last call.

Margaret

On Jun 1, 2010, at 10:30 AM, [email-masked] wrote:

> <mime-attachment>_______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 02 Jun 2010 10:11:23 +0200 (CEST)

Hi Margaret,

> are satisfied with the changes I've made to address them?

Most issues are fixed, but I think the change to NETCONF operation was
applied in cases where it shouldn't have been.  My original point was
that the previous version used different terms for the same thing,
"operation", "command", "RPC message" etc.  We should use one term,
"operation", or "NETCONF operation" as you did.  But the term
operation refers to specific rpcs, e.g. edit-config, close-session
etc.  When we refer to the layer below operations, we use the term
"message" (or "NETCONF message").  The new reference figure we agreed
on after long debates will be included in 4741bis:

            Layer                 Example
       +-------------+      +-----------------+      +----------------+
   (4) |   Content   |      |  Configuration  |      |  Notification  |
       |             |      |      data       |      |      data      |
       +-------------+      +-----------------+      +----------------+
              |                       |                      |
       +-------------+      +-----------------+              |
   (3) | Operations  |      |  <edit-config>  |              |
       |             |      |                 |              |
       +-------------+      +-----------------+              |
              |                       |                      |
       +-------------+      +-----------------+      +----------------+
   (2) |  Messages   |      |     <rpc>,      |      | <notification> |
       |             |      |   <rpc-reply>   |      |                |
       +-------------+      +-----------------+      +----------------+
              |                       |                      |
       +-------------+      +-----------------------------------------+
   (1) |   Secure    |      |  SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... |
       | Transports  |      |                                         |
       +-------------+      +-----------------------------------------+

As Juergen pointed out, since this is a transport document, it should
in most cases just refer to the layer above, i.e. "messages".  In some
cases, e.g. in section 5 where you refer to close-session, you need to
use the term operation.

So, each occurance of "operation" needs to be looked at, and either
simply changed to "message", or, in some cases, rewrite the sentence.

An example of the latter is from 3.1:

OLD:

   The following example shows a capability exchange.  Operations sent
   by the NETCONF client are marked with "C:" and operations sent by the
   NETCONF server are marked with "S:".

NEW:

   The following example shows a capability exchange.  Data sent
   by the NETCONF client are marked with "C:" and data sent by the
   NETCONF server are marked with "S:".

----------

Another issue is from section 5, on close-session:

   the NETCONF server
   shall respond and close the SSH session channel.

s/shall/SHALL/   (or MUST)

/martin

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 2 Jun 2010 08:06:55 -0400

Hi Martin,

On Jun 2, 2010, at 4:11 AM, Martin Bjorklund wrote:
> applied in cases where it shouldn't have been.

Could you send me a list of the places where you would prefer that I  
use the term "RPC message", so that we can have a specific proposed  
change to discuss in the WG?

> My original point was
> "message" (or "NETCONF message").

Although I used the term NETCONF command and NETCONF operation  
interchangeably in the last version, this was the distinction I was  
trying to make when I used the term "RPC message". However, your  
previous proposed change (which the WG accepted) included changing RPC  
message to NETCONF operation, as well.  So, if I change all of those  
occurrences back to "RPC message", I doubt that will work for you  
either...  If you can send a specific set of places where you believe  
we should use "RPC message", hopefully we can get agreement in the WG  
on the specific places where that term should be used, instead of  
NETCONF operation.
>   NETCONF server are marked with "S:".

Why "data" instead of "RPC messages"?  I don't see "data" as an option  
in the reference diagram...

>   shall respond and close the SSH session channel.

I will make this change in the next version unless anyone objects.

Margaret

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 02 Jun 2010 15:29:10 +0200 (CEST)

Hi,

> change to discuss in the WG?

Ok.

OLD: 1

   The SSH client initiates the SSH connection and the SSH server
   accepts the connection.  The NETCONF client sends NETCONF
   operations, and the NETCONF server responds to those operations.
   There is no requirement that the NETCONF client reside on the SSH
   client or that the NETCONF server reside on the SSH server.

NEW:

   The NETCONF client sends NETCONF The SSH client initiates the SSH
   connection and the SSH server accepts the connection.  There is no
   requirement that the NETCONF client reside on the SSH client or
   that the NETCONF server reside on the SSH server.

(i.e. just delete the sentence about who sends what -- it is not
relevant for the transport protocol; the alternative would be to say
that each peer sends NETCONF messages)

OLD: 1

   Although this document gives specific examples of how NETCONF
   operations are sent over an SSH connection, use of this transport is
   not restricted to the operations shown in the examples below.  This
   transport can be used for any NETCONF operation.

NEW:

   Although this document gives specific examples of how NETCONF
   messages are sent over an SSH connection, use of this transport is
   not restricted to the messages shown in the examples below.  This
   transport can be used for any NETCONF message.

OLD: 3.1

   The NETCONF server MUST indicate its capabilities by sending an XML
   document containing a <hello> element as soon as the NETCONF session
   is established.  The NETCONF client can parse this operation to
   determine which NETCONF capabilities are supported by the NETCONF
   server.

NEW:

   The NETCONF server MUST indicate its capabilities by sending an XML
   document containing a <hello> element as soon as the NETCONF session
   is established.  The NETCONF client can parse this message to
   determine which NETCONF capabilities are supported by the NETCONF
   server.

OLD: 3.1

NEW:

(The reason is that each line is marked with C: and S: -- this is not
an operation; it is just data)

OLD: 3.1

   Although the example shows the NETCONF server sending a <hello>
   operation followed by the NETCONF client's operation, both sides will
   send the operation as soon as the NETCONF subsystem is initialized,
   perhaps simultaneously.

NEW:

   Although the example shows the NETCONF server sending a <hello>
   message followed by the NETCONF client's <hello> message, both
   sides will send the message as soon as the NETCONF subsystem is
   initialized, perhaps simultaneously.

OLD: 5

   Exiting NETCONF is accomplished using the <close-session> operation.
   A NETCONF server will process NETCONF operations from the NETCONF
   client in the order in which the are received.  When the NETCONF
   server processes a <close-session> operation, the NETCONF server
   shall respond and close the SSH session channel.  The NETCONF server
   MUST NOT process any NETCONF operations received after the <close-
   session> operation.

NEW:

   Exiting NETCONF is accomplished using the <close-session> operation.
   A NETCONF server will process NETCONF messages from the NETCONF
   client in the order in which the are received.  When the NETCONF
   server processes a <close-session> operation, the NETCONF server
   SHALL respond and close the SSH session channel.  The NETCONF server
   MUST NOT process any NETCONF messages received after the <close-
   session> operation.

/martin

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 10 Jun 2010 10:28:40 -0400

Hi Martin,

Thanks for the feedback!

With the exception of your first suggested change, all the suggestions  
you sent look like improvements to me.  I've included them below.   
Does anyone have any objection to making those changes?

I think there is a problem (perhaps a cut-and-paste error?) with your  
first suggestion, though:

>   that the NETCONF server reside on the SSH server.

Clearly that isn't what you meant, but I'm not exactly sure what you  
did mean...  Are you suggesting:

NEW:

The SSH client initiates the SSH connection and the SSH server accepts  
the connection.  There is no requirement that the NETCONF client  
reside on the SSH client, or that the NETCONF server reside on the SSH  
server.

If so, I wonder...  Do you really think it is okay not to define the  
two ends of the NETCONF connection, but that it is necessary to define  
the two ends of an SSH connection?

Maybe we would be better off removing this paragraph altogether?  Or  
just saying:

"There is no requirement that the NETCONF client reside on the SSH  
client or that the NETCONF server reside on the SSH server."

...if we think it is important to state that, rather than just not  
saying anything?

Margaret

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 10 Jun 2010 16:44:04 +0200 (CEST)

Hi,

Margaret Wasserman <[email-masked]> wrote:
> I think there is a problem (perhaps a cut-and-paste error?) with your first
> suggestion, though:

Whoops!

> Clearly that isn't what you meant, but I'm not exactly sure what you did
> mean...  Are you suggesting:
> 
> NEW:
> 
> The SSH client initiates the SSH connection and the SSH server accepts the
> connection.  There is no requirement that the NETCONF client reside on the SSH
> client, or that the NETCONF server reside on the SSH server.

Yes, that's what I meant.

> If so, I wonder...  Do you really think it is okay not to define the two ends
> of the NETCONF connection, but that it is necessary to define the two ends of
> an SSH connection?

Hmm...  The problem with the original text was that it didn't handle
the case that the server can send <notification>.  Since 4741/4741bis
+ 5277 define what kind of messages the NETCONF peers can send, this
document should not try to define that.

> Maybe we would be better off removing this paragraph altogether?

That would be fine with me.

/martin

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 10 Jun 2010 17:12:47 -0400

Hi Martin,

> That would be fine with me.

Okay.  Unless anyone objects, I will make this change and the other  
changes you suggested and resubmit some time next week.

Thanks!
Margaret

---

From: "Bert Wijnen" <[email-masked]>
Date: Fri, 11 Jun 2010 09:38:00 +0200

Speaking as co-chair

This seems fine to me.

If anyone disagrees. PLEASE DO SPEAK UP by 15 June at the latest

Bert
----- Original Message ----- 
From: "Margaret Wasserman" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 10, 2010 11:12 PM
Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-rfc4742bis-01.txt

Hi Martin,

Thanks!
Margaret

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Mon, 28 Jun 2010 13:39:05 +0200

Margareth, pls go ahead andmake thse changes. Nobody has commented, so I 
take
that as agreement Isince had indicated I would do so unless anyone 
objected).

I think we are then done with this document and we can then submit it to our
AD.

Thanks,
Bert and Mehmet