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