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> Wed, 06 October 2010 12:23 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 D26863A6EE6 for <netconf@core3.amsl.com>; Wed, 6 Oct 2010 05:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.386
X-Spam-Level:
X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.214, 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 YN5Y-2NKGveE for <netconf@core3.amsl.com>; Wed, 6 Oct 2010 05:23:30 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 8E8B03A6EBC for <netconf@ietf.org>; Wed, 6 Oct 2010 05:23:30 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o96CORVM018759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Oct 2010 14:24:27 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o96COPW0020718; Wed, 6 Oct 2010 14:24:27 +0200
Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 14:24:26 +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: Wed, 06 Oct 2010 14:24:23 +0200
Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64010A8B49@DEMUEXC006.nsn-intra.net>
In-Reply-To: <20101006.133730.41786057.mbj@tail-f.com>
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: ActlSt/oZ7ylvL5ARfe01eAIj47TPwAAncFg
References: <CB69B162C87647AE97AB749466633F54@BertLaptop><4C9B3E60.5030000@bwijnen.net><80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <20101006.133730.41786057.mbj@tail-f.com>
From: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
To: ext Martin Bjorklund <mbj@tail-f.com>
X-OriginalArrivalTime: 06 Oct 2010 12:24:26.0051 (UTC) FILETIME=[6A4F0130:01CB6551]
Cc: netconf@ietf.org
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: Wed, 06 Oct 2010 12:23:31 -0000

Hi Martin,

> > 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).
> 
> I agree with my co-editors that we should stick to the client/server
> terminology.  There are a couple of places in the document where we
> should change the terminology from e.g. application to client.

The text I proposed may be a bit misleading but this is 
what I want too. 

I just propose to bring the terms into relation as early 
as possible in the terminology section. Then we can use 
only client/server.
 
> > 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.
> 
> Why is the new text better?

Clear and direct? Anyway, I can go with both.
 
> > Section 5.2. Data Modeling
> >
> > "Devices and managers may support multiple data models, ..."
> >
> > s/managers/applications/
> 
> I'd prefer "Clients and servers may support...".

Fine.
 
> > 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.
> 
> I think the text in 7.5 gives useful information.  I am not sure why
> you think it needs to be removed.

I agree that the text in quotations marks above gives useful 
information.  However it is not self-explaining. The questions
coming up are: How and whether a client is allowed to kill "any" 
session. 
 
> > 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.
> 
> If the filter parameter is present, the 'type' attribute specifies if
> it is a subtree filter or xpath filter.  If no 'type' attribute is
> present, it defaults to subtree filtering.  Section 6 describes this
> algorithm, and specificially 6.4.2 specifies how an empty subtree
> filter works.  I don't think we should say anything about special
> filter values in 7.7.

Agree.

 
> > Section 12.2. Informative References
> >
> > Add draft-ietf-netmod-yang-usage-11 as informative reference.
> 
> Why?  That document is intended for YANG module writers.

Appendix C includes a normative YANG module and IANA considerations 
include namespace registration, etc., which follow the guidelines 
in draft-ietf-netmod-yang-usage. 
I think people who read the YANG module in 4741bis should be also
pointed to the guidelines document.

> /martin

Mehmet/>