Subject: Re: [Netconf] [Fwd: I-D Action:draft-ietf-netconf-rfc4742bis-00.txt]

From: Martin Bjorklund <[email-masked]>
Date: Mon, 15 Mar 2010 15:59:08 +0100 (CET)

Hi,

"Bert (IETF) Wijnen" <[email-masked]> wrote:
> pls review and comment on this initial version. Sooner is better than later.

... but later is hopefully better than never :)

Here are some comments:

rfcdiff shows some typos compared with 4742:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc4742bis-00.txt

Section 1 introduces the terms "client / server" and "manager / agent"
and makes a distinction between them.  These terms are not consistent
with how they are used in 4741.  Also, in the document, the term
"user" and "application" is also used instead of "manager".   Would it
be simpler to use only the terms "client" and "server" throughout the
doc?

s/RPC message/RPC operation/
s/command/operation/

Section 4 specifies that the clients sends <rpc> elements and the
server sends <rpc-reply> elements.  It should also mention
<notification> elements.

Clarification in Section 5:

OLD:
   The agent MUST NOT process any RPC commands received on the current
   session after the <close-session> command.

NEW:
   The agent MUST NOT process any RPC operations received on the current
   NETCONF session after the <close-session> command.

/martin

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Wed, 17 Mar 2010 12:35:22 +0100

Off course! thanks Martin.

Margaret, pls note and answer

Bert
  ----- Original Message ----- 
  From: Martin Bjorklund 
  To: [email-masked] 
  Cc: [email-masked] 
  Sent: Monday, March 15, 2010 3:59 PM
  Subject: Re: [Netconf] [Fwd: I-D Action:draft-ietf-netconf-rfc4742bis-00.txt]

  Hi,

  Here are some comments:

  OLD:

  NEW:

  /martin

------------------------------------------------------------------------------

  Geen virus gevonden in het binnenkomende-bericht.
  Gecontroleerd door AVG - www.avg.com 
  Versie: 9.0.790 / Virusdatabase: 271.1.1/2748 - datum van uitgifte: 03/15/10 08:33:00

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 21 Mar 2010 16:46:26 -0700

Hi Martin,

Sorry for the delay in replying, I missed this message last week.

> http://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf- 

I will look at this and attempt to clean up any typos.
> be simpler to use only the terms "client" and "server" throughout the

The distinction being made is between the SSH client and server and  
the NETCONF agent and manager.  At the time the original document was  
written, there was a desire to make it clear that the direction of the  
SSH connection might or might not correspond to the direction of the  
NETCONF direction (i.e. the manager might use SSH to reach the  
client).  I am not sure that this distinction has provided useful in  
practice, but this is a carry-over from the previous version.

In what way is this inconsistent with RFC 4741?  And do you think this  
would cause some sort of confusion that could affect implementations?   
Or is this just an editorial issue?
> s/RPC message/RPC operation/

What are the reasons for proposing these changes?  Does the current  
wording present some sort of problem?
> server sends <rpc-reply> elements.  It should also mention

The SSH specification does not support sending/receiving  
<notification> elements.  Are you suggesting we add support for  
notifications?  Or just that we mention that it isn't supported?
>   NETCONF session after the <close-session> command.

This rewording doesn't change the meaning of the sentence, but if you  
think adding the word NETCONF would make this clearer, and no one else  
objects, I will add it.

Margaret

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 21 Mar 2010 22:15:54 -0700 (PDT)

> Or is this just an editorial issue?

I'd say it is an editorial issue.

> wording present some sort of problem?

Same reason as above; the document is easier to read if the terms are
used consistently.  Or is there a reason for using different terms for
the same thing?  If there is, maybe the terms should be explained.

> notifications?  Or just that we mention that it isn't supported?

RFC 5277 defines how to send notifications over NETCONF.  It
introduces the XML element <notification>, which can be sent over any
of the NETCONF transports, including ssh.  So I think we should
add support for it now that we make a new revision.

> think adding the word NETCONF would make this clearer, and no one else

There are two sessions involved, the SSH session and the NETCONF
session.  I think this rewording makes it clear that it is the NETCONF
session that gets closed, not the SSH session.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Mar 2010 07:12:19 +0100

> the same thing?  If there is, maybe the terms should be explained.

I agree with Martin that consistency in terminology makes things
easier to read/understand.

> add support for it now that we make a new revision.

An even better solution might be to avoid being overly specific about
the other layers of NETCONF. This is a transport document and as such
it should carry any (including future) NETCONF messages.

> session that gets closed, not the SSH session.

And it should be <close-session> operation. ;-) That said, I note that
the sentence talks about operations, not about NETCONF messages. As
such, the text allows the processing of non RPC messages
(e.g. interleaved notifications) after a close-session. Perhaps this
is what was intended?

NEW:
   The NETCONF server MUST NOT process any messages received on the
   current NETCONF session after the <close-session> operation.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>