Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt

"Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com> Sun, 03 October 2010 17:15 UTC

Return-Path: <mehmet.ersue@nsn.com>
X-Original-To: netconf@core3.amsl.com
Delivered-To: netconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27CBA3A6DEE for <netconf@core3.amsl.com>; Sun, 3 Oct 2010 10:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.368
X-Spam-Level:
X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eo7-DarJtdKA for <netconf@core3.amsl.com>; Sun, 3 Oct 2010 10:15:05 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 0CD4E3A6DE8 for <netconf@ietf.org>; Sun, 3 Oct 2010 10:15:04 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o93HFthU015552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <netconf@ietf.org>; Sun, 3 Oct 2010 19:15:55 +0200
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o93HFt4F002088 for <netconf@ietf.org>; Sun, 3 Oct 2010 19:15:55 +0200
Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Oct 2010 19:15:55 +0200
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 03 Oct 2010 19:15:52 +0200
Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net>
In-Reply-To: <4C9B3E60.5030000@bwijnen.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt
Thread-Index: ActbFSvYCBJBrtm7Thm8gWdvPWBPSAIAqwCQ
References: <CB69B162C87647AE97AB749466633F54@BertLaptop> <4C9B3E60.5030000@bwijnen.net>
From: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
To: Netconf <netconf@ietf.org>
X-OriginalArrivalTime: 03 Oct 2010 17:15:55.0210 (UTC) FILETIME=[A36BA2A0:01CB631E]
Subject: Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Oct 2010 17:15:07 -0000

Dear NETCONF Members,

I hope this mail motivates the Netconf community to 
comment or raises at least some discussion on the 
content of 4741bis. 

As you know 4741bis is the base protocol document 
for NETCONF. Please comment on the 4741bis draft.
It would be actually sufficient to say: "I read it 
and it is ready to ship."


[Co-chair hat off]

I had read the document but read again. 
I couldn't find any serious issues and I think it is 
ready for publication though I have a few suggestions
to make it more consistent and to improve the clarity 
as a standard-track document.


Section 1.1. Terminology

I would suggest to bring the terms client/manager/
application vs. agent/server/device as early as 
possible into relation. The document mainly avoids 
the usage of the terms manager and agent though 
there are some leftovers.

OLD: 
   client: A client invokes protocol operations on a server.
NEW: 
   client: A client (manager, application) invokes 
   protocol operations on a server (agent, device).

OLD: 
   server: A server executes protocol operations invoked by a client.
NEW: 
   server: A server (agent, device) executes protocol 
   operations invoked by a client (manager, application).


Section 1.2. Protocol Overview

To get it consistent with the rest of the document it would 
be good to use only singular for layer titles.

s/Operations/Operation/
s/Messages/Message/
s/Secure Transports/Secure Transport/
s/The Messages layer/The Message layer/
s/The Operations layer/The Operation layer/


Section 1.4. Separation of Configuration and State Data

OLD:
   For example, if a local database of user authentication data is
   stored on the device, it is an implementation-dependent matter
   whether it is included in configuration data.
NEW:
   For example, if a local database of user authentication data is
   stored on the device, it is implementation-dependent, whether 
   it is included in configuration data.


Section 3. XML Considerations

Concerning the mail-thread on "how to handle XML parse 
errors" I agree with the last proposed text.

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

NEW:
   All NETCONF messages MUST be well-formed XML, encoded in UTF-8.  
   If a server receives a message that is not well-formed XML, it MUST
   reply with an 'operation-failed' error.

A few sentences on this issue should be added to 
the security considerations section (see below).


Section 3.2. No Document Type Declarations

The title sounds like a command.
Change to "Document Type Declarations".


Section 4.3. <rpc-error> Element

s/layer: Messages/layer: Message/
s/layer: Operations/layer: Operation/


Section 5.2. Data Modeling

"Devices and managers may support multiple data models, ..."

s/managers/applications/


Section 7.5. <lock>

To differentiate from Partial Lock RFC clearly, I would 
underline that the operation is on the entire configuration 
datastore.

OLD: 
   The lock operation allows the client to lock the configuration
   system of a device.
NEW:
   The lock operation allows the client to lock an entire configuration
   datastore of a server.

I also would suggest to keep using the term "configuration 
datastore" instead of "configuration", which is used in other 
parts of the document to mean a specific part of the 
configuration of a datastore.

E.g.
"An attempt to lock the configuration datastore MUST..."
"The target configuration datastore is <candidate>,..."
"The target parameter names the configuration datastore that will be
locked."

Sec. 1.1. says: 
"session: Client and server exchange messages using a secure, 
connection-oriented session."

Sec. 2.1. Connection-Oriented Operation says: 
"For example, when a lock is acquired by a client, the lock 
persists until either it is explicitly released or the server 
determines that the connection has been terminated."

Sec. 2.3. Authentication says: 
"The access permissions of a given client, identified by its 
NETCONF username, are part of the configuration of the NETCONF 
server. These permissions MUST be enforced during the remainder 
of the NETCONF session."

Sec. 7.5 says:
"The <kill-session> operation can be used to force the 
release of a lock owned by another NETCONF session."

How a client can release a lock which is owned by another 
session needs to be elaborated. E.g. Partial Lock RFC says: 
"If needed, the returned session-id may be used to <kill-session> the
NETCONF session holding the lock."

I actually would suggest to delete this sentence in section 7.5. 
and stick to the statement in section 2.1. 


Section 7.7. <get>

"filter:
   This parameter specifies the portion of the system
   configuration and state data to retrieve.  If this parameter is
   not present, all the device configuration and state information
   is returned."

For the sake of completeness I would add what happens 
if the filter parameter is available but empty.


Section 8.4.1. Description

s/configuration, /configuration. /


Section 8.4.1. Description and 8.6.1. Description

OLD:
   The current version is 1.1, and is defined in this document. It
extends...
NEW:
   The version 1.1 is defined in this document and extends...


Section 12.2. Informative References

Add draft-ietf-netmod-yang-usage-11 as informative reference.


Section 9. Security Considerations

I would suggest to add a few sentences for the EOM handling 
and the possible thread concerning section 3. It would be 
interesting to recommend a possible reaction if this happens 
frequently, e.g. to drop the NETCONF session.


Appendix B. XML Schema for NETCONF Messages Layer

s/XML Schema for NETCONF Messages Layer/
XML Schema for NETCONF Message Layer/


Cheers,
Mehmet


> -----Original Message-----
> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On
> Behalf Of ext Bert (IETF) Wijnen
> Sent: Thursday, September 23, 2010 1:48 PM
> To: Netconf
> Subject: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-
> ietf-netconf-4741bis-04.txt
> 
> 
>   It was pointed out to me that we did not get ANY comments to this
> WGLC.
> Well, there was continued discussion on XML parse errors (which is
> related partly to this document) on which we will come back tomorrow.
> 
> But no other comments, Also not any " I read it, go ahead to the next
> step".
> 
> Can the WG chairs assume that people have indeed read the latest
> version
> of this document and are OK with it?
> 
> Can you please ASAP tell us: I read the doc and I am fine with it!!!
> 
> PLEASE
> 
> Bert and Mehmet
> 
> On 9/3/10 12:08 AM, Bert Wijnen (IETF) wrote:
> > WG participants, this email starts a formal WG Last Call for
revision
> 4
> > of the 4741bis document. The document is targeted as Proposed
> Standard
> > to replace the current rfc4741.
> >
> > Please do review and tell us your position and comments.
> > Please do so BEFORE 20 September 2010.
> >
> > Bert and Mehmet
> >
> > ----- Original Message -----
> > From:<Internet-Drafts@ietf.org>
> > To:<i-d-announce@ietf.org>
> > Cc:<netconf@ietf.org>
> > Sent: Monday, August 23, 2010 7:00 PM
> > Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-04.txt
> >
> >
> > 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           : Network Configuration Protocol (NETCONF)
> > Author(s)       : R. Enns, et al.
> > Filename        : draft-ietf-netconf-4741bis-04.txt
> > Pages           : 121
> > Date            : 2010-08-23
> >
> > The Network Configuration Protocol (NETCONF) defined in this
document
> > provides mechanisms to install, manipulate, and delete the
> > configuration of network devices.  It uses an Extensible Markup
> > Language (XML)-based data encoding for the configuration data as
well
> > as the protocol messages.  The NETCONF protocol operations are
> > realized as Remote Procedure Calls (RPC).
> >
> > A URL for this Internet-Draft is:
> >
http://www.ietf.org/internet-drafts/draft-ietf-netconf-4741bis-04.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf