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/>
- [Netconf] 2-week WG Last Call for: draft-ietf-net… Bert Wijnen (IETF)
- [Netconf] We NEED RESPONSES: WG Last Call ended f… Bert (IETF) Wijnen
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Ersue, Mehmet (NSN - DE/Munich)
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Juergen Schoenwaelder
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Andy Bierman
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Ersue, Mehmet (NSN - DE/Munich)
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Ersue, Mehmet (NSN - DE/Munich)
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Juergen Schoenwaelder
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Ladislav Lhotka
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Juergen Schoenwaelder
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Ersue, Mehmet (NSN - DE/Munich)
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Martin Bjorklund
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Ersue, Mehmet (NSN - DE/Munich)
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Juergen Schoenwaelder
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Ersue, Mehmet (NSN - DE/Munich)
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Juergen Schoenwaelder
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Phil Shafer
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Juergen Schoenwaelder
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Ersue, Mehmet (NSN - DE/Munich)
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Ladislav Lhotka
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Juergen Schoenwaelder
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Andy Bierman
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Juergen Schoenwaelder
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Ersue, Mehmet (NSN - DE/Munich)
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Ladislav Lhotka
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Ersue, Mehmet (NSN - DE/Munich)
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Ladislav Lhotka
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Andy Bierman
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Andrew Stone
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Andy Bierman
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Ersue, Mehmet (NSN - DE/Munich)
- Re: [Netconf] We NEED RESPONSES: WG Last Call end… Andrew Stone