Re: [Netconf] We NEED RESPONSES: WG Last Call ended for:draft-ietf-netconf-4741bis-04.txt
Andy Bierman <ietf@andybierman.com> Thu, 07 October 2010 16:11 UTC
Return-Path: <ietf@andybierman.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 CE4593A6E6D for <netconf@core3.amsl.com>; Thu, 7 Oct 2010 09:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.619
X-Spam-Level:
X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96]
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 4K3ClK5QNu8o for <netconf@core3.amsl.com>; Thu, 7 Oct 2010 09:11:44 -0700 (PDT)
Received: from nm4-vm0.bullet.mail.ne1.yahoo.com (nm4-vm0.bullet.mail.ne1.yahoo.com [98.138.90.253]) by core3.amsl.com (Postfix) with SMTP id 428A43A6CE4 for <netconf@ietf.org>; Thu, 7 Oct 2010 09:11:44 -0700 (PDT)
Received: from [98.138.90.52] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 07 Oct 2010 16:12:46 -0000
Received: from [98.138.89.164] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 07 Oct 2010 16:12:46 -0000
Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 07 Oct 2010 16:12:46 -0000
X-Yahoo-Newman-Id: 279209.89080.bm@omp1020.mail.ne1.yahoo.com
Received: (qmail 13663 invoked from network); 7 Oct 2010 16:12:46 -0000
Received: from [192.168.0.14] (ietf@75.84.164.152 with plain) by smtp102.sbc.mail.ne1.yahoo.com with SMTP; 07 Oct 2010 09:12:45 -0700 PDT
X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o-
X-YMail-OSG: 8zLyR0cVM1lWLRrQ5sxMoBYugObh7mP6kdZWLZLKQB.aumH 4o9vtzy8hFN3Cyk3QUdHn9yO6w.G8tZvJ.wdmA2.ZwScIXTJiJ32SQdwrPQr GJeHOOOgzYvDMUmArmszC6kyYdeOqnK.kJ.ita1q.2jIhg5dgJsOVS8GarIk UEGj54k4fkf6bqrFEihgMNcmK1kU1N8ZwuCj8C27cAWnQXB68BJkJibfs4l6 OCUJ34mhosJQ64JGH5oAK_JU5Jj7uM.haPwgx.7VJDrPmvIeUyzsNbU3Nyn3 yD0A2qZ_O2g.Rtcr6U_s9tJF9Xtpm.Krf2EXK
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4CADF17D.4030207@andybierman.com>
Date: Thu, 07 Oct 2010 09:12:45 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: Andrew Stone <stone@openclovis.com>
References: <CB69B162C87647AE97AB749466633F54@BertLaptop> <4C9B3E60.5030000@bwijnen.net> <80A0822C5E9A4440A5117C2F4CD36A640106532D@DEMUEXC006.nsn-intra.net> <AANLkTi=NTVZD9AsgPdGKNWZnwk4Z=xmYyigKd6S-JGna@mail.gmail.com>
In-Reply-To: <AANLkTi=NTVZD9AsgPdGKNWZnwk4Z=xmYyigKd6S-JGna@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Netconf <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: Thu, 07 Oct 2010 16:11:46 -0000
On 10/07/2010 08:45 AM, Andrew Stone wrote: > "A NETCONF message MAY begin with an XML declaration (see section 2.8 of [1 <http://tools.ietf.org/html/draft-ietf-netconf-4741bis-04#ref-1>])." > > > Since the XML declaration is optional, shall we clarify which version of > XML must be used if the declaration is NOT included? > > And perhaps require that servers handle all XML versions (1.0 and 1.1) > following the protocol design philosophy that "receivers" should be > generous in what they accept? If we do not require this, we could get > clients that can't communicate with servers because the client sends XML > ver 1.1 (say) and the server only accepts 1.0. > > Or just keep it simple and require that all NETCONF messages be XML > version 1.1. I sort of object to this change. (3/4 objection?) It would be OK to say a server MUST support 1.0 and SHOULD or MAY support 1.1. It seems like the version MUST be present if a server is required to support multiple versions of XML. > > Regards, > Andrew Andy > > > On Sun, Oct 3, 2010 at 1:15 PM, Ersue, Mehmet (NSN - DE/Munich) > <mehmet.ersue@nsn.com <mailto:mehmet.ersue@nsn.com>> wrote: > > 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> > [mailto: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 <mailto:Internet-Drafts@ietf.org>> > > > To:<i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>> > > > Cc:<netconf@ietf.org <mailto: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 <mailto:Netconf@ietf.org> > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org <mailto:Netconf@ietf.org> > > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org <mailto:Netconf@ietf.org> > https://www.ietf.org/mailman/listinfo/netconf > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf
- [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