From andy@yumaworks.com Wed Sep 4 17:03:55 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38FE11E8149 for ; Wed, 4 Sep 2013 17:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.705 X-Spam-Level: X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imkajl9yL-Gu for ; Wed, 4 Sep 2013 17:03:50 -0700 (PDT) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id F1AC211E8145 for ; Wed, 4 Sep 2013 17:03:46 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr4so1017794pbb.6 for ; Wed, 04 Sep 2013 17:03:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=CQzYgbbmPJ0azNiQkQsTMrBgc/XwPmd0QUxkA/9j4UQ=; b=RaKxP2lFXYayw7uVUzPWec0vd9wQt47L7benOIbgnZaGH210YYJ8JfEbp7u6PukFbs CMBAII3sHxtlO2c8/eNSNF6rSKkgsc6yh9FZzCuzMtBBrVKNTG19/gF29SIv4LHo772R T6llp4dNdRUuOzOehEhBcRH0dygRJ6KsBL5+uEw6V9ax0zU8WWLQf+PwRGkr8sMGKiWH hCFqatVi05LG6b3DPm4EWx52QPxzqpP71pQ3X9DVinaSUezu16XnEbrmxs4T36Bhf84l aHahq0rD+oU0subp190e8pwHQpQZEC/reza2z+gw4dbBGlWowjaYIq16+taAeWoOgO8J CG9A== X-Gm-Message-State: ALoCoQmgRZNCHplfIvx9f6jgk4mPgCB5IhTH++YqwYH5kNbmgUOKh44RLb7ahladhGQHbpwCYbRa MIME-Version: 1.0 X-Received: by 10.68.221.167 with SMTP id qf7mr230798pbc.187.1378339426514; Wed, 04 Sep 2013 17:03:46 -0700 (PDT) Received: by 10.70.41.162 with HTTP; Wed, 4 Sep 2013 17:03:46 -0700 (PDT) In-Reply-To: <20130904235917.30173.82970.idtracker@ietfa.amsl.com> References: <20130904235917.30173.82970.idtracker@ietfa.amsl.com> Date: Wed, 4 Sep 2013 17:03:46 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=e89a8ff25032e5cb6104e597a7f2 Subject: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 00:03:55 -0000 --e89a8ff25032e5cb6104e597a7f2 Content-Type: text/plain; charset=ISO-8859-1 FYI, The initial RESTCONF protocol draft has been published. Support for notifications has not been added yet. See the change log for a summary of the updates since the yang-api-01 draft. Andy ---------- Forwarded message ---------- From: Date: Wed, Sep 4, 2013 at 4:59 PM Subject: I-D Action: draft-bierman-netconf-restconf-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RESTCONF Protocol Author(s) : Andy Bierman Martin Bjorklund Kent Watsen Rex Fernando Filename : draft-bierman-netconf-restconf-00.txt Pages : 93 Date : 2013-09-04 Abstract: This document describes a RESTful protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bierman-netconf-restconf There's also a htmlized version available at: http://tools.ietf.org/html/draft-bierman-netconf-restconf-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --e89a8ff25032e5cb6104e597a7f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI,

The initial RESTCONF protocol draf= t has been published.
Support for notifications has not been adde= d yet.
See the change log for a summary of the updates
since the yang-api-01 draft.


Andy


---------- Forwarded message --= --------
From: <= internet-drafts@ietf.org>= ;
Date: Wed, Sep 4, 2013 at 4:59 PM
Subject: I-D Action: draft-bierman-net= conf-restconf-00.txt
To: i-d-an= nounce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : RESTCONF Protocol
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Andy Bierman
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Martin Bjorklund
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kent Watsen
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rex Fernando
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-bierman-netconf-restconf-00= .txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 93
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-09-04

Abstract:
=A0 =A0This document describes a RESTful protocol that provides a
=A0 =A0programmatic interface over HTTP for accessing data defined in YANG,=
=A0 =A0using the datastores defined in NETCONF.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bierman-netconf-r= estconf

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netconf-restconf-0= 0


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--e89a8ff25032e5cb6104e597a7f2-- From j.schoenwaelder@jacobs-university.de Wed Sep 4 22:24:40 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0144A21E809A for ; Wed, 4 Sep 2013 22:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.072 X-Spam-Level: X-Spam-Status: No, score=-102.072 tagged_above=-999 required=5 tests=[AWL=-1.123, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_WRLDWD=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nHK45ILCtX5 for ; Wed, 4 Sep 2013 22:24:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 570A221E80A1 for ; Wed, 4 Sep 2013 22:24:35 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6532B20BF9; Thu, 5 Sep 2013 07:24:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JfI5SZbBqM7G; Thu, 5 Sep 2013 07:24:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 75A5A20BF5; Thu, 5 Sep 2013 07:24:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 91CC52835D3C; Thu, 5 Sep 2013 07:24:26 +0200 (CEST) Date: Thu, 5 Sep 2013 07:24:26 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130905052426.GA56548@elstar.local> Mail-Followup-To: Andy Bierman , Netconf References: <20130904235917.30173.82970.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 05:24:40 -0000 Hi, I am wondering whether the authors did consider approaches that do not require to construct complex URIs. See for example this I-D that provides some warnings: http://tools.ietf.org/html/draft-nottingham-uri-get-off-my-lawn-02 Is .well-known really intended to be the root of a complex URI namespace for applications like RESTCONF? For example, RFC 5785 says: However, in keeping with the Architecture of the World- Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended for general information retrieval or establishment of large URI namespaces on the Web. Does it make sense to run this proposal through some application area experts for early review and comment? /js On Wed, Sep 04, 2013 at 05:03:46PM -0700, Andy Bierman wrote: > FYI, > > The initial RESTCONF protocol draft has been published. > Support for notifications has not been added yet. > See the change log for a summary of the updates > since the yang-api-01 draft. > > > Andy > > > ---------- Forwarded message ---------- > From: > Date: Wed, Sep 4, 2013 at 4:59 PM > Subject: I-D Action: draft-bierman-netconf-restconf-00.txt > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : RESTCONF Protocol > Author(s) : Andy Bierman > Martin Bjorklund > Kent Watsen > Rex Fernando > Filename : draft-bierman-netconf-restconf-00.txt > Pages : 93 > Date : 2013-09-04 > > Abstract: > This document describes a RESTful protocol that provides a > programmatic interface over HTTP for accessing data defined in YANG, > using the datastores defined in NETCONF. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-bierman-netconf-restconf > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-bierman-netconf-restconf-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jonathan@hansfords.net Thu Sep 5 03:56:25 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14A611E8186 for ; Thu, 5 Sep 2013 03:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6L97H3BkDGDE for ; Thu, 5 Sep 2013 03:56:18 -0700 (PDT) Received: from avasout07.plus.net (avasout07.plus.net [84.93.230.235]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF8A11E80E3 for ; Thu, 5 Sep 2013 03:56:17 -0700 (PDT) Received: from webmail.plus.net ([84.93.228.66]) by avasout07 with smtp id MNwF1m0071SbfYc01NwFVv; Thu, 05 Sep 2013 11:56:16 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=bbFSDo/B c=1 sm=1 tr=0 a=C5+YawzV8SR07mwocaP9vA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=lxldWUwtbAkA:10 a=dYCPD3cKDi0A:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=zt0w56kAxm4A:10 a=b15APTt_nPZ_vY4nofQA:9 a=QEXdDO2ut3YA:10 a=WX3gBDEstdfCYqZUuuIA:9 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Thu, 05 Sep 2013 11:56:15 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_801def7ef1bd01dfcc58d5777b00fc63" Date: Thu, 05 Sep 2013 11:56:15 +0100 From: Jonathan Hansford To: Netconf Message-ID: <2c24cc43b916194e3a8e85289297d81f@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] Subject: [Netconf] Confirmed commit timeout X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 10:56:25 -0000 --=_801def7ef1bd01dfcc58d5777b00fc63 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Hi, RFC 6241 appears to be quiet about notifying the client if a confirmed commit times out. Is it a server implementation detail to determine whether to send a notification to the client? I know event notifications are an optional capability and may not be supported by either the client or the server, but its seems odd that the appropriate behaviour is not defined as, if the client is performing a series of confirmed commits, how will it know whether previous confirmed commits have timed out and been reverted? Thanks Jonathan --=_801def7ef1bd01dfcc58d5777b00fc63 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi,

RFC 6241 appears to be quiet about notifying the client if a confirmed c= ommit times out. Is it a server implementation detail to determine whether = to send a notification to the client? I know event notifications are an opt= ional capability and may not be supported by either the client or the serve= r, but its seems odd that the appropriate behaviour is not defined as, if t= he client is performing a series of confirmed commits, how will it know whe= ther previous confirmed commits have timed out and been reverted?

Thanks

Jonathan

--=_801def7ef1bd01dfcc58d5777b00fc63-- From j.schoenwaelder@jacobs-university.de Thu Sep 5 04:02:29 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF45A11E818D for ; Thu, 5 Sep 2013 04:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pc3-VEmMqu4d for ; Thu, 5 Sep 2013 04:02:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C6F2B11E818C for ; Thu, 5 Sep 2013 04:02:18 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89F3720C40; Thu, 5 Sep 2013 13:02:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id C4VJqnK7dKzi; Thu, 5 Sep 2013 13:02:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7DDD120C3C; Thu, 5 Sep 2013 13:02:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3B22B28364FC; Thu, 5 Sep 2013 13:02:10 +0200 (CEST) Date: Thu, 5 Sep 2013 13:02:10 +0200 From: Juergen Schoenwaelder To: Jonathan Hansford Message-ID: <20130905110210.GA57426@elstar.local> Mail-Followup-To: Jonathan Hansford , Netconf References: <2c24cc43b916194e3a8e85289297d81f@imap.plus.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2c24cc43b916194e3a8e85289297d81f@imap.plus.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] Confirmed commit timeout X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 11:02:29 -0000 On Thu, Sep 05, 2013 at 11:56:15AM +0100, Jonathan Hansford wrote: > > > Hi, > > RFC 6241 appears to be quiet about notifying the client if a > confirmed commit times out. Is it a server implementation detail to > determine whether to send a notification to the client? I know event > notifications are an optional capability and may not be supported by > either the client or the server, but its seems odd that the appropriate > behaviour is not defined as, if the client is performing a series of > confirmed commits, how will it know whether previous confirmed commits > have timed out and been reverted? > I think one of the really missing pieces in NETCONF is a config revision number or a timestamp that can uniquely identify a certain configuration. If such a thing would be available (as part of the standards), I guess it would be much easier to address your questions even without having to have notifications. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Sep 5 04:06:59 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD0511E812A for ; Thu, 5 Sep 2013 04:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXlmNs8Wi31E for ; Thu, 5 Sep 2013 04:06:53 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id BE46411E8192 for ; Thu, 5 Sep 2013 04:06:52 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id EB5A912000BF; Thu, 5 Sep 2013 13:06:51 +0200 (CEST) Date: Thu, 05 Sep 2013 13:06:51 +0200 (CEST) Message-Id: <20130905.130651.502380061442059671.mbj@tail-f.com> To: Jonathan@hansfords.net From: Martin Bjorklund In-Reply-To: <2c24cc43b916194e3a8e85289297d81f@imap.plus.net> References: <2c24cc43b916194e3a8e85289297d81f@imap.plus.net> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmed commit timeout X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 11:07:00 -0000 Hi, Jonathan Hansford wrote: > > > Hi, > > RFC 6241 appears to be quiet about notifying the client if a > confirmed commit times out. Is it a server implementation detail to > determine whether to send a notification to the client? I know event > notifications are an optional capability and may not be supported by > either the client or the server, but its seems odd that the appropriate > behaviour is not defined as, if the client is performing a series of > confirmed commits, how will it know whether previous confirmed commits > have timed out and been reverted? The notification "netconf-confirmed-commit" in RFC 6470 does this. This was standardized after 6241, which is the reason it is not mentioned in 6241. If we revise 6241, it would make sense to mention this; even if notifications are still an optional capability. /martin From jonathan@hansfords.net Thu Sep 5 04:13:18 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF70121F9C17 for ; Thu, 5 Sep 2013 04:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78bXsPZjrNiz for ; Thu, 5 Sep 2013 04:13:12 -0700 (PDT) Received: from avasout07.plus.net (avasout07.plus.net [84.93.230.235]) by ietfa.amsl.com (Postfix) with ESMTP id 372FA21F9AED for ; Thu, 5 Sep 2013 04:13:12 -0700 (PDT) Received: from webmail.plus.net ([84.93.228.66]) by avasout07 with smtp id MPDB1m0041SbfYc01PDBar; Thu, 05 Sep 2013 12:13:11 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=bbFSDo/B c=1 sm=1 tr=0 a=C5+YawzV8SR07mwocaP9vA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=lxldWUwtbAkA:10 a=dYCPD3cKDi0A:10 a=MIhP8-6zlYcA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=mwxGBUG95_sA:10 a=kdgCG6oM0ymxARI_Cs0A:9 a=QEXdDO2ut3YA:10 a=1rgnPY4EEFsA:10 a=MIfcft3-TbxCt6AspHgA:9 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Thu, 05 Sep 2013 12:13:11 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a2789913733c8912979d493f6fb71f53" Date: Thu, 05 Sep 2013 12:13:11 +0100 From: Jonathan Hansford To: Martin Bjorklund In-Reply-To: <20130905.130651.502380061442059671.mbj@tail-f.com> References: <2c24cc43b916194e3a8e85289297d81f@imap.plus.net> <20130905.130651.502380061442059671.mbj@tail-f.com> Message-ID: <0749bb21a3770fee57b2a549ee839dda@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmed commit timeout X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 11:13:19 -0000 --=_a2789913733c8912979d493f6fb71f53 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 On 2013-09-05 12:06, Martin Bjorklund wrote: > Hi, > > Jonathan Hansford wrote: > >> Hi, RFC 6241 appears to be quiet about notifying the client if a >> confirmed commit times out. Is it a server implementation detail to >> determine whether to send a notification to the client? I know event >> notifications are an optional capability and may not be supported by >> either the client or the server, but its seems odd that the appropriate >> behaviour is not defined as, if the client is performing a series of >> confirmed commits, how will it know whether previous confirmed commits >> have timed out and been reverted? > > The notification "netconf-confirmed-commit" in RFC 6470 does this. > > This was standardized after 6241, which is the reason it is not > mentioned in 6241. If we revise 6241, it would make sense to mention > this; even if notifications are still an optional capability. > That's exactly what I was looking for; I obviously just hadn't looked far enough! Thanks. > > /martin --=_a2789913733c8912979d493f6fb71f53 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 
On 2013-09-05 12:06, Martin Bjorklund wrote:=20

> Hi,
>=20
> Jonathan Hansford <Jonathan@hansfords.net> wrote:
>=20
>> Hi, RFC 6241 appears to be quiet about notifying the client if a
>> confirmed commit times out. Is it a server implementation detail t=
o
>> determine whether to send a notification to the client? I know eve=
nt
>> notifications are an optional capability and may not be supported =
by
>> either the client or the server, but its seems odd that the approp=
riate
>> behaviour is not defined as, if the client is performing a series =
of
>> confirmed commits, how will it know whether previous confirmed com=
mits
>> have timed out and been reverted?
>=20
> The notification "netconf-confirmed-commit" in RFC 6470 does this.
>=20
> This was standardized after 6241, which is the reason it is not
> mentioned in 6241. If we revise 6241, it would make sense to mention
> this; even if notifications are still an optional capability.
> 

That's exactly what I was looking for; I obviously just hadn't looked far
enough! Thanks.

>=20
> /martin
--=_a2789913733c8912979d493f6fb71f53-- From andy@yumaworks.com Thu Sep 5 06:07:58 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843DA21F8319 for ; Thu, 5 Sep 2013 06:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=-0.897, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_WRLDWD=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOXz4GQv+jw6 for ; Thu, 5 Sep 2013 06:07:53 -0700 (PDT) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 907DF1F0C55 for ; Thu, 5 Sep 2013 06:07:52 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id xb4so1734246pbc.8 for ; Thu, 05 Sep 2013 06:07:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=66Wydzb6PWwkOZ5juqjoOmlN+KRtPxfXEXN6vkcEMpI=; b=cSyrJcHVrHuguYaBTI0MJOlk0eSepxQo+eEBDyTQuDv9ZbO+fDiTpHGonqPqjE2Bi4 bFjHlzhCvw6M2k5QAdEBw+k8ZoYo+euYYUc98r24OSUThXIMOf3WQS9um1xpQOVYOaBj FEE0hrbWB3hb7vhtw1701Hajaucj8B5sZ4M3zM3O2DKCg/8yftfnHi4a3f8ljGTo6oYx y/Y6MxiLHKJRtbnV1hHe17YxF4cXp5iM6z3UcEjRjgJIqIptrIuLw/FBdml1O1xSwOJ9 r79/O2VBEwzrwTc1FUWdIdIyloVlGlom1ONB2grx5wquz2FlTXXyUdfvvxw94r8HKzw0 KhqA== X-Gm-Message-State: ALoCoQlZmq6noUQHfA0EVggr/uxVRZbuIMAe/HtqULek0Hoyxf1SdhtFKYKiAyAQdv7YSsfUqFW6 MIME-Version: 1.0 X-Received: by 10.68.183.131 with SMTP id em3mr9143161pbc.56.1378386471624; Thu, 05 Sep 2013 06:07:51 -0700 (PDT) Received: by 10.70.41.162 with HTTP; Thu, 5 Sep 2013 06:07:51 -0700 (PDT) In-Reply-To: <20130905052426.GA56548@elstar.local> References: <20130904235917.30173.82970.idtracker@ietfa.amsl.com> <20130905052426.GA56548@elstar.local> Date: Thu, 5 Sep 2013 06:07:51 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Netconf Content-Type: multipart/alternative; boundary=047d7b6d822601385704e5a29c57 Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 13:08:07 -0000 --047d7b6d822601385704e5a29c57 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 4, 2013 at 10:24 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > I am wondering whether the authors did consider approaches that do not > require to construct complex URIs. See for example this I-D that > provides some warnings: > > http://tools.ietf.org/html/draft-nottingham-uri-get-off-my-lawn-02 > > It is a tradeoff whether the YANG-derived text is in the URI or in the message body. I do not agree that using a URI for this purpose is a problem, any more than using YANG at all is a problem. Schema-based applications need stable (static) URIs. Discovering the entire set of URIs on a device each session is too inefficient. Is .well-known really intended to be the root of a complex URI > namespace for applications like RESTCONF? For example, RFC 5785 > says: > > However, in keeping with the Architecture of the World- > Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended > for general information retrieval or establishment of large URI > namespaces on the Web. > > Does it make sense to run this proposal through some application area > experts for early review and comment? > Probably -- we added .well-known because we thought it was needed. If not, that saves 12 useless characters in every request. > > /js > > Andy > On Wed, Sep 04, 2013 at 05:03:46PM -0700, Andy Bierman wrote: > > FYI, > > > > The initial RESTCONF protocol draft has been published. > > Support for notifications has not been added yet. > > See the change log for a summary of the updates > > since the yang-api-01 draft. > > > > > > Andy > > > > > > ---------- Forwarded message ---------- > > From: > > Date: Wed, Sep 4, 2013 at 4:59 PM > > Subject: I-D Action: draft-bierman-netconf-restconf-00.txt > > To: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : RESTCONF Protocol > > Author(s) : Andy Bierman > > Martin Bjorklund > > Kent Watsen > > Rex Fernando > > Filename : draft-bierman-netconf-restconf-00.txt > > Pages : 93 > > Date : 2013-09-04 > > > > Abstract: > > This document describes a RESTful protocol that provides a > > programmatic interface over HTTP for accessing data defined in YANG, > > using the datastores defined in NETCONF. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-bierman-netconf-restconf > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-bierman-netconf-restconf-00 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --047d7b6d822601385704e5a29c57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Sep 4, 2013 at 10:24 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

I am wondering whether the authors did consider approaches that do not
require to construct complex URIs. See for example this I-D that
provides some warnings:

=A0 =A0http://tools.ietf.org/html/draft-nottingham-ur= i-get-off-my-lawn-02



It is a tradeoff whethe= r the YANG-derived text is in the URI
or in the message body. =A0= I do not agree that using a URI for this
purpose is a problem, an= y more than using YANG at all
is a problem. =A0Schema-based applications need stable (static) URIs.<= /div>
Discovering the entire set of URIs on a device each session is
too inefficient.


Is .well-known really intended to be the root of a complex URI
namespace for applications like RESTCONF? For example, RFC 5785
says:

=A0 =A0However, in keeping with the Architecture of the World-
=A0 =A0Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intende= d
=A0 =A0for general information retrieval or establishment of large URI
=A0 =A0namespaces on the Web.

Does it make sense to run this proposal through some application area
experts for early review and comment?

P= robably -- we added .well-known because we thought it was needed.
If not, that saves 12 useless characters in every request.
=A0

/js



Andy
=A0
On Wed, Sep 04, 2013 at 05:03:46PM -0700, Andy Bierman wrote:
> FYI,
>
> The initial RESTCONF protocol draft has been published.
> Support for notifications has not been added yet.
> See the change log for a summary of the updates
> since the yang-api-01 draft.
>
>
> Andy
>
>
> ---------- Forwarded message ----------
> From: <internet-drafts@= ietf.org>
> Date: Wed, Sep 4, 2013 at 4:59 PM
> Subject: I-D Action: draft-bierman-netconf-restconf-00.txt
> To: i-d-announce@ietf.org=
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : RESTCONF Protocol
> =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Andy Bierman
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Martin Bjorklund > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kent Watsen
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rex Fernando
> =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-bierman-netconf-restco= nf-00.txt
> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 93
> =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-09-04
>
> Abstract:
> =A0 =A0This document describes a RESTful protocol that provides a
> =A0 =A0programmatic interface over HTTP for accessing data defined in = YANG,
> =A0 =A0using the datastores defined in NETCONF.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-bierman-netc= onf-restconf
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-bierman-netconf-restc= onf-00
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>

--047d7b6d822601385704e5a29c57-- From kwatsen@juniper.net Thu Sep 5 10:49:10 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C5811E824A for ; Thu, 5 Sep 2013 10:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_WRLDWD=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnU0q4Ar-EUp for ; Thu, 5 Sep 2013 10:49:05 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 3515E11E81EB for ; Thu, 5 Sep 2013 10:49:05 -0700 (PDT) Received: from mail60-am1-R.bigfish.com (10.3.201.231) by AM1EHSOBE016.bigfish.com (10.3.207.138) with Microsoft SMTP Server id 14.1.225.22; Thu, 5 Sep 2013 17:49:04 +0000 Received: from mail60-am1 (localhost [127.0.0.1]) by mail60-am1-R.bigfish.com (Postfix) with ESMTP id 31611240295; Thu, 5 Sep 2013 17:49:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zf7Iz1432I4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz17326ah1de097h186068h8275dhz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail60-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(164054003)(2473001)(51704005)(31966008)(4396001)(74662001)(83506001)(56816003)(46102001)(74366001)(81342001)(15202345003)(80976001)(76176001)(19580395003)(47446002)(54356001)(74502001)(47736001)(49866001)(81542001)(77096001)(47976001)(50986001)(83322001)(53806001)(51856001)(56776001)(76482001)(81816001)(36756003)(83072001)(15975445006)(80022001)(65816001)(54316002)(66066001)(79102001)(74876001)(561944002)(77982001)(59766001)(81686001)(63696002)(69226001)(74706001)(76796001)(76786001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB125; H:BY2PR05MB125.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail60-am1 (localhost.localdomain [127.0.0.1]) by mail60-am1 (MessageSwitch) id 1378403341108198_15148; Thu, 5 Sep 2013 17:49:01 +0000 (UTC) Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.242]) by mail60-am1.bigfish.com (Postfix) with ESMTP id 0D2122C00B0; Thu, 5 Sep 2013 17:49:01 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 5 Sep 2013 17:49:00 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.353.4; Thu, 5 Sep 2013 17:48:56 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) by BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 5 Sep 2013 17:48:53 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.57]) by BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.186]) with mapi id 15.00.0745.000; Thu, 5 Sep 2013 17:48:53 +0000 From: Kent Watsen To: Andy Bierman , Juergen Schoenwaelder , Netconf Thread-Topic: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-00.txt Thread-Index: AQHOqctyXoscyPJp5EqwtYZh3lo72Jm2nMgAgACBeoCAAAt2AA== Date: Thu, 5 Sep 2013 17:48:52 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [66.129.232.2] x-forefront-prvs: 096029FF66 Content-Type: text/plain; charset="us-ascii" Content-ID: <6A1917275BF6AA44B59D5C03C216563D@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 17:49:10 -0000 >> Is .well-known really intended to be the root of a complex URI >> namespace for applications like RESTCONF? For example, RFC 5785 >> says: >> >> However, in keeping with the Architecture of the World- >> Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended >> for general information retrieval or establishment of large URI >> namespaces on the Web. >> >> Does it make sense to run this proposal through some application area >> experts for early review and comment? > > > Probably -- we added .well-known because we thought it was needed. > If not, that saves 12 useless characters in every request. =20 [Ooops, sorry, there was a misunderstanding. The .well-known (RFC 5785) is good, but it was only intended to retrieve the host-meta resource (RFC 6415), which is defined to be an extensible resource descriptor (XRD) [http://docs.oasis-open.org/xri/xrd/v1.0/xrd-1.0.html], which itself contains types defined in RFC 5988. For instance: Request ------- GET /.well-known/host-meta users HTTP/1.1 Accept: application/xrd+xml Response -------- HTTP/1.1 200 OK Content-Type: application/xrd+xml Content-Length: nnn >From this, the client then knows that the entire RESTCONF URL-space is under /api. Per RFC 5988, we just need to register "restconf" in IANA's Link Relation Types registry=20 (http://www.iana.org/assignments/link-relations/link-relations.xhtml). Thanks, Kent From andy@yumaworks.com Mon Sep 9 14:14:17 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6162D11E8153 for ; Mon, 9 Sep 2013 14:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+ODwB7s4hcg for ; Mon, 9 Sep 2013 14:14:10 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id 0761E11E80F8 for ; Mon, 9 Sep 2013 14:14:09 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl13so6793268pab.34 for ; Mon, 09 Sep 2013 14:14:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=+93M3c8VD3wuilsO36F/F5b/12dcUENO+US5qazU0+U=; b=YVufD4rzUaQVoi1Nt5+UdcW6V3hRdd60lZiRDim0knfF3vBqKsXagPGJRF1pdOPazA FaK6nRMeGMBGoj9weVnsDumBNoRRmkqnwvAVFqUvHR3nZpRILdll2MnIGf/dAZOrfOt+ wwGYsGBMeCNYl82GdeUJl9RQ0J89RWdDzDqMwBWLiQ+JgDSJTdPn1TQxhivuJHU9uren cBOyhD8vRBhfWSabPngPjhqhy9odiNpi5TViRUpl73WGQ2xoBalIuV6Lhi5SpD7TrDjM qUa5MxiZkGXuEscYCGBQ+J7k6eRHoPIa25SDn1yEuLGb60SqEuAaDV/KtFP7IbBX9Uhb J5BQ== X-Gm-Message-State: ALoCoQmedxqr+aoQ+YUj/sniKR4Cad1A/5tk0VAcygyqrVTXK8vRrolHH5XB3HTGazKiVcIv82sU MIME-Version: 1.0 X-Received: by 10.66.119.136 with SMTP id ku8mr10675524pab.121.1378761249740; Mon, 09 Sep 2013 14:14:09 -0700 (PDT) Received: by 10.70.41.162 with HTTP; Mon, 9 Sep 2013 14:14:09 -0700 (PDT) In-Reply-To: <20130909210924.27020.27331.idtracker@ietfa.amsl.com> References: <20130909210924.27020.27331.idtracker@ietfa.amsl.com> Date: Mon, 9 Sep 2013 14:14:09 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=e89a8ffbacdf856c1204e5f9deb5 Subject: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 21:14:18 -0000 --e89a8ffbacdf856c1204e5f9deb5 Content-Type: text/plain; charset=ISO-8859-1 FYI, This RESTCONF draft update fixes some bugs in -00. I do not know if there will be time at the next IETF meeting to discuss the technical details. There should be a discussion first on the need for RESTCONF and the scope of a charter for such a work item. Andy ---------- Forwarded message ---------- From: Date: Mon, Sep 9, 2013 at 2:09 PM Subject: I-D Action: draft-bierman-netconf-restconf-01.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RESTCONF Protocol Author(s) : Andy Bierman Martin Bjorklund Kent Watsen Rex Fernando Filename : draft-bierman-netconf-restconf-01.txt Pages : 92 Date : 2013-09-09 Abstract: This document describes a RESTful protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bierman-netconf-restconf There's also a htmlized version available at: http://tools.ietf.org/html/draft-bierman-netconf-restconf-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-bierman-netconf-restconf-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --e89a8ffbacdf856c1204e5f9deb5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI,

This RESTCONF draft update fixes s= ome bugs in -00.

I do not know if there will be ti= me at the next IETF meeting
to discuss the technical details. =A0= There should be a discussion
first on the need for RESTCONF and the scope of a charter for
such a work item.


Andy
=

---------- Forwarded message ----------<= br> From: <internet-drafts@ietf.org>
= Date: Mon, Sep 9, 2013 at 2:09 PM
Subject: I-D Action: draft-bierman-net= conf-restconf-01.txt
To: i-d-announce@ietf.org
<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : RESTCONF Protocol
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Andy Bierman
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Martin Bjorklund
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kent Watsen
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rex Fernando
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-bierman-netconf-restconf-01= .txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 92
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-09-09

Abstract:
=A0 =A0This document describes a RESTful protocol that provides a
=A0 =A0programmatic interface over HTTP for accessing data defined in YANG,=
=A0 =A0using the datastores defined in NETCONF.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bierman-netconf-r= estconf

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netconf-restconf-0= 1

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-bierman-ne= tconf-restconf-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--e89a8ffbacdf856c1204e5f9deb5-- From balazs.lengyel@ericsson.com Mon Sep 16 01:16:25 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42F811E8146 for ; Mon, 16 Sep 2013 01:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLYA0q5QihDT for ; Mon, 16 Sep 2013 01:16:11 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 669A311E8227 for ; Mon, 16 Sep 2013 01:14:32 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-bb-5236bdc63735 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 18.69.16099.6CDB6325; Mon, 16 Sep 2013 10:13:59 +0200 (CEST) Received: from [159.107.197.46] (153.88.183.147) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.328.9; Mon, 16 Sep 2013 10:13:58 +0200 Message-ID: <5236BDC6.3050006@ericsson.com> Date: Mon, 16 Sep 2013 10:13:58 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "netconf@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOJMWRmVeSWpSXmKPExsUyM+Jvje7xvWZBBkeuMFtM3XSb1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGeu3rWAumMtWseT3Q+YGxlssXYycHBICJhIt9xawQdhiEhfu rQeyuTiEBA4zSvzrPcUI4axhlFjQ2MkIUsUroC1xcnczmM0ioCqx5WYjE4jNJmAkMbX/PNhU UYEoiQ3bL7BA1AtKnJz5BMwWEdCUaJz1gRXEFhbQkmhd+gmsl1nAVuLCnOssELa8xPa3c5hB bCEBDYmHF/6yTmDkm4Vk1CwkLbOQtCxgZF7FyJ6bmJmTXm64iREYOAe3/NbdwXjqnMghRmkO FiVx3k16ZwKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MPJ9Dbz08ve0E7f6PNp/dTk1frcu KF3bkMe9gmt724EjVqLW0WXO7BedJ7OknssNzJ5j0eg1YcKqZ3vzN88/kG58IkdB+v/VvCUX FiRcS2dYl2K591rf/F7rZX94pDpXvZn1zWDdCf9g99n7v7LOD82+bH80UHtupuSbi0xczgdk zS+0N2ZOrVJiKc5INNRiLipOBABRcT6R6gEAAA== Subject: [Netconf] What to check in cndidate config? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 08:16:25 -0000 Hello, When editing a candidate config some model constraints may be violated temporarily. E.g. mandatory leafs might be added in a later separate edit-config. However some constraints are probably checked immediately, e.g. the string "XYZ" is not accepted if a leaf's type is int32. Is there somewhere a list describing which type of checks should or should not be checked at edit-config to the candidate, and which should only be checked at a validate or commit operation. Ideally this list of constraints/checks should be part of the YANG RFC. regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From mbj@tail-f.com Mon Sep 16 01:31:30 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A35821F8421 for ; Mon, 16 Sep 2013 01:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Noby02RYLi56 for ; Mon, 16 Sep 2013 01:30:03 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2644011E81EB for ; Mon, 16 Sep 2013 01:19:35 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 729231200434; Mon, 16 Sep 2013 10:19:01 +0200 (CEST) Date: Mon, 16 Sep 2013 10:19:01 +0200 (CEST) Message-Id: <20130916.101901.1139180237571657090.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <5236BDC6.3050006@ericsson.com> References: <5236BDC6.3050006@ericsson.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] What to check in cndidate config? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 08:31:50 -0000 Hi, Balazs Lengyel wrote: > Hello, > When editing a candidate config some model constraints may be violated > temporarily. E.g. mandatory leafs might be added in a later separate > edit-config. However some constraints are probably checked > immediately, e.g. the string "XYZ" is not accepted if a leaf's type is > int32. > Is there somewhere a list describing which type of checks should or > should not be checked at edit-config to the candidate, and which > should only be checked at a validate or commit operation. Ideally this > list of constraints/checks should be part of the YANG RFC. See Section 8.3 in RFC 6020. /martin From jonathan@hansfords.net Thu Sep 19 05:41:40 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689BB21F943C for ; Thu, 19 Sep 2013 05:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUICi0nhWD1V for ; Thu, 19 Sep 2013 05:41:34 -0700 (PDT) Received: from avasout07.plus.net (avasout07.plus.net [84.93.230.235]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAC521F93F8 for ; Thu, 19 Sep 2013 05:41:32 -0700 (PDT) Received: from webmail.plus.net ([84.93.228.66]) by avasout07 with smtp id T0hV1m0071SbfYc010hVPg; Thu, 19 Sep 2013 13:41:30 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=GK4xTI9K c=1 sm=1 tr=0 a=C5+YawzV8SR07mwocaP9vA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=lxldWUwtbAkA:10 a=dYCPD3cKDi0A:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=Af6SbmDO6U4A:10 a=yJ5w7H1UJ92kGsEnBloA:9 a=QEXdDO2ut3YA:10 a=S_TGt6QnTbHmjarnXU4A:9 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Thu, 19 Sep 2013 13:41:29 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_4a83001d5b5306c7fb829ed4133d8e67" Date: Thu, 19 Sep 2013 13:41:29 +0100 From: Jonathan Hansford To: Netconf Message-ID: <76a7f77cfd72c64ce0459f00d430df4d@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] Subject: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 12:41:40 -0000 --=_4a83001d5b5306c7fb829ed4133d8e67 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Hi, I am writing an Interface Definition Document that references NETCONF but am struggling to explain the terminology surrounding confirmed and confirming commits. From my reading, the difference between a confirmed commit and a confirming commit is the latter effectively marks the end of a transaction (running configuration cannot be rolled back beyond the last confirming commit). Consequently, it seems to me that a "confirmed commit" would be better described as an "unconfirmed commit" since it is not confirmed until followed by a "confirming commit". Can someone explain the choice of the current terminology and correct any erroneous assumptions I have made? Thanks, Jonathan --=_4a83001d5b5306c7fb829ed4133d8e67 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi,

I am writing an Interface Definition Document that references NETCONF bu= t am struggling to explain the terminology surrounding confirmed and confir= ming commits. From my reading, the difference between a confirmed commit an= d a confirming commit is the latter effectively marks the end of a transact= ion (running configuration cannot be rolled back beyond the last confirming= commit). Consequently, it seems to me that a "confirmed commit" would be b= etter described as an "unconfirmed commit" since it is not confirmed until = followed by a "confirming commit". Can someone explain the choice of the cu= rrent terminology and correct any erroneous assumptions I have made?

Thanks,

Jonathan

 

--=_4a83001d5b5306c7fb829ed4133d8e67-- From jonathan@hansfords.net Thu Sep 19 13:07:27 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E354621F89C3 for ; Thu, 19 Sep 2013 13:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9EaAmmpISWX for ; Thu, 19 Sep 2013 13:07:20 -0700 (PDT) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE2121F89F7 for ; Thu, 19 Sep 2013 13:07:19 -0700 (PDT) Received: from webmail.plus.net ([84.93.237.98]) by avasout04 with smtp id T87H1m002283uBY0187JXx; Thu, 19 Sep 2013 21:07:18 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=MqNrtQqe c=1 sm=1 tr=0 a=BJaFPv9AyABFDM2hXLRoEA==:117 a=ay7+waBXjX2gYBYtdgtTjg==:17 a=0Bzu9jTXAAAA:8 a=YehYk60mo_QA:10 a=dYCPD3cKDi0A:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=EBOSESyhAAAA:8 a=urOY2GcFnqMA:10 a=EUNhRHg1KrDzSDlP3jIA:9 a=QEXdDO2ut3YA:10 a=Ka8QxA_ivzZ_vTYoEPAA:9 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from hansfords.plus.com ([84.92.149.4]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Thu, 19 Sep 2013 21:07:17 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_8c26ef82d48564ef12240fe8b347dc1b" Date: Thu, 19 Sep 2013 21:07:17 +0100 From: Jonathan Hansford To: In-Reply-To: <76a7f77cfd72c64ce0459f00d430df4d@imap.plus.net> References: <76a7f77cfd72c64ce0459f00d430df4d@imap.plus.net> Message-ID: X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [84.92.149.4] Subject: Re: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:07:27 -0000 --=_8c26ef82d48564ef12240fe8b347dc1b Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 After about two hours digging around in the NETCONF archive and then a Google search on "confirmed commit", I've come to the conclusion confirmed commit has come out of the JUNOS "commit confirmed" command. My guess is the JUNOS command is shorthand for "revert this commit after the timeout unless it is confirmed"; not exactly clear. Indeed, I would have thought "commit confirmed" would be the command to confirm the previous commit, though obviously that would overload the meaning of the original "commit" command since it would not persist without the confirmation. But "confirmed commit" implies the commit has been confirmed, not that it needs to be confirmed. Isn't this confusing to anyone else? Jonathan On 2013-09-19 13:41, Jonathan Hansford wrote: > Hi, > > I am writing an Interface Definition Document that references NETCONF but am struggling to explain the terminology surrounding confirmed and confirming commits. From my reading, the difference between a confirmed commit and a confirming commit is the latter effectively marks the end of a transaction (running configuration cannot be rolled back beyond the last confirming commit). Consequently, it seems to me that a "confirmed commit" would be better described as an "unconfirmed commit" since it is not confirmed until followed by a "confirming commit". Can someone explain the choice of the current terminology and correct any erroneous assumptions I have made? > > Thanks, > > Jonathan --=_8c26ef82d48564ef12240fe8b347dc1b Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

After about two hours digging around in the NETCONF archive and then a G= oogle search on "confirmed commit", I've come to the conclusion confirmed c= ommit has come out of the JUNOS "commit confirmed" command. My guess is the= JUNOS command is shorthand for "revert this commit after the timeout unles= s it is confirmed"; not exactly clear. Indeed, I would have thought "commit= confirmed" would be the command to confirm the previous commit, though obv= iously that would overload the meaning of the original "commit" command sin= ce it would not persist without the confirmation.

But "confirmed commit" implies the commit has been confirmed, not that i= t needs to be confirmed. Isn't this confusing to anyone else?

Jonathan

On 2013-09-19 13:41, Jonathan Hansford wrote:

Hi,

I am writing an Interface Definition Document that references NETCONF bu= t am struggling to explain the terminology surrounding confirmed and confir= ming commits. From my reading, the difference between a confirmed commit an= d a confirming commit is the latter effectively marks the end of a transact= ion (running configuration cannot be rolled back beyond the last confirming= commit). Consequently, it seems to me that a "confirmed commit" would be b= etter described as an "unconfirmed commit" since it is not confirmed until = followed by a "confirming commit". Can someone explain the choice of the cu= rrent terminology and correct any erroneous assumptions I have made?

Thanks,

Jonathan

 

--=_8c26ef82d48564ef12240fe8b347dc1b-- From mikebianc@aol.com Thu Sep 19 13:15:13 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330F121F85B3 for ; Thu, 19 Sep 2013 13:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwlyAdaG4eGy for ; Thu, 19 Sep 2013 13:15:07 -0700 (PDT) Received: from omr-m01.mx.aol.com (omr-m01.mx.aol.com [64.12.143.75]) by ietfa.amsl.com (Postfix) with ESMTP id CE94421F85B2 for ; Thu, 19 Sep 2013 13:15:06 -0700 (PDT) Received: from mtaout-db06.r1000.mx.aol.com (mtaout-db06.r1000.mx.aol.com [172.29.51.198]) by omr-m01.mx.aol.com (Outbound Mail Relay) with ESMTP id AC393701065EC; Thu, 19 Sep 2013 16:15:04 -0400 (EDT) Received: from mgs-aad01.mail.aol.com (mgs-aad01.mail.aol.com [205.188.178.60]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-db06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 6BB6EE0000E2; Thu, 19 Sep 2013 16:15:04 -0400 (EDT) Date: Thu, 19 Sep 2013 16:15:04 -0400 From: "mikebianc@aol.com" To: Jonathan@hansfords.net, netconf@ietf.org Message-ID: <1469752086.21674.1379621704097.JavaMail.tomcat@mgs-aad01.mail.aol.com> In-Reply-To: References: <76a7f77cfd72c64ce0459f00d430df4d@imap.plus.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_21673_1128350158.1379621704096" X-Originating-IP: 10.181.180.189, 64.12.75.136 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20121107; t=1379621704; bh=a2z7cj6oNd8PJN6FoyVaXXwaeYo/MDZqlezfYtL8S0w=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=P+UOofeyhA4zt3ErjO7m00pJFz11bYWX1duSbJ8WA2cJi5jfqJnG46STWftD4NYlL 6bHPrJCPev9ZYv3aSt4PJ/VgS+3n3ZWiGQvsxASB2H6S48JSPyy8ZKRwyfDF9eowS5 SeQ7SRuiXpa6QW37g4vWEqxK+icYHw5gsojOOMi8= x-aol-sid: 3039ac1d33c6523b5b48630b X-AOL-IP: 205.188.178.60 Subject: Re: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:15:13 -0000 ------=_Part_21673_1128350158.1379621704096 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I am familiar with the Juniper 'commit confirmed' command which means exactly what you guessed it means (you type in 'commit confirmed [timeout]' and then if you aren't kicked off the box, you type in 'commit' to confirm the commit otherwise it reverts back). So to answer your question, having 'confirming' commit as well as 'confirmed commit' is rather confusing, esp to someone who is unfamiliar with one or both cases and has to make assumptions. From: Jonathan@hansfords.net To: Sent: Thursday, September 19, 2013 Subject: Re: [Netconf] Confirmed commit After about two hours digging around in the NETCONF archive and then a Google search on "confirmed commit", I've come to the conclusion confirmed commit has come out of the JUNOS "commit confirmed" command. My guess is the JUNOS command is shorthand for "revert this commit after the timeout unless it is confirmed"; not exactly clear. Indeed, I would have thought "commit confirmed" would be the command to confirm the previous commit, though obviously that would overload the meaning of the original "commit" command since it would not persist without the confirmation. But "confirmed commit" implies the commit has been confirmed, not that it needs to be confirmed. Isn't this confusing to anyone else? Jonathan On 2013-09-19 13:41, Jonathan Hansford wrote: Hi, I am writing an Interface Definition Document that references NETCONF but am struggling to explain the terminology surrounding confirmed and confirming commits. From my reading, the difference between a confirmed commit and a confirming commit is the latter effectively marks the end of a transaction (running configuration cannot be rolled back beyond the last confirming commit). Consequently, it seems to me that a "confirmed commit" would be better described as an "unconfirmed commit" since it is not confirmed until followed by a "confirming commit". Can someone explain the choice of the current terminology and correct any erroneous assumptions I have made? Thanks, Jonathan ------=_Part_21673_1128350158.1379621704096 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I am familiar with the Juniper 'commit confirmed' command which means exactly what you guessed it means (you type in 'commit confirmed [timeout]' and then if you aren't kicked off the box, you type in 'commit' to confirm the commit otherwise it reverts back).

So to answer your question, having 'confirming' commit as well as 'confirmed commit' is rather confusing, esp to someone who is unfamiliar with one or both cases and has to make assumptions.





From: Jonathan@hansfords.net<Jonathan@hansfords.net>
To: <netconf@ietf.org>
Sent: Thursday, September 19, 2013
Subject: Re: [Netconf] Confirmed commit

After about two hours digging around in the NETCONF archive and then a Google search on "confirmed commit", I've come to the conclusion confirmed commit has come out of the JUNOS "commit confirmed" command. My guess is the JUNOS command is shorthand for "revert this commit after the timeout unless it is confirmed"; not exactly clear. Indeed, I would have thought "commit confirmed" would be the command to confirm the previous commit, though obviously that would overload the meaning of the original "commit" command since it would not persist without the confirmation.

But "confirmed commit" implies the commit has been confirmed, not that it needs to be confirmed. Isn't this confusing to anyone else?

Jonathan

On 2013-09-19 13:41, Jonathan Hansford wrote:

Hi,

I am writing an Interface Definition Document that references NETCONF but am struggling to explain the terminology surrounding confirmed and confirming commits. From my reading, the difference between a confirmed commit and a confirming commit is the latter effectively marks the end of a transaction (running configuration cannot be rolled back beyond the last confirming commit). Consequently, it seems to me that a "confirmed commit" would be better described as an "unconfirmed commit" since it is not confirmed until followed by a "confirming commit". Can someone explain the choice of the current terminology and correct any erroneous assumptions I have made?

Thanks,

Jonathan

------=_Part_21673_1128350158.1379621704096-- From j.schoenwaelder@jacobs-university.de Thu Sep 19 13:15:42 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0C621F85E8 for ; Thu, 19 Sep 2013 13:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.165 X-Spam-Level: X-Spam-Status: No, score=-103.165 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gh9tRYsTc7cx for ; Thu, 19 Sep 2013 13:15:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7752521F85EE for ; Thu, 19 Sep 2013 13:15:33 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CCB6720C11; Thu, 19 Sep 2013 22:15:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ts2sQ8xffpWc; Thu, 19 Sep 2013 22:15:24 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6120620C10; Thu, 19 Sep 2013 22:15:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 59834287327D; Thu, 19 Sep 2013 22:15:19 +0200 (CEST) Date: Thu, 19 Sep 2013 22:15:18 +0200 From: Juergen Schoenwaelder To: Jonathan Hansford Message-ID: <20130919201517.GA1886@elstar.local> Mail-Followup-To: Jonathan Hansford , netconf@ietf.org References: <76a7f77cfd72c64ce0459f00d430df4d@imap.plus.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:15:42 -0000 On Thu, Sep 19, 2013 at 09:07:17PM +0100, Jonathan Hansford wrote: > > > After about two hours digging around in the NETCONF archive and then > a Google search on "confirmed commit", I've come to the conclusion > confirmed commit has come out of the JUNOS "commit confirmed" command. > My guess is the JUNOS command is shorthand for "revert this commit after > the timeout unless it is confirmed"; not exactly clear. Indeed, I would > have thought "commit confirmed" would be the command to confirm the > previous commit, though obviously that would overload the meaning of the > original "commit" command since it would not persist without the > confirmation. > > But "confirmed commit" implies the commit has been > confirmed, not that it needs to be confirmed. Isn't this confusing to > anyone else? There is the ':confirmed-commit' capability, there is the 'confirming commit' and there is the initial commit which is sometimes called the 'confirmed commit'. I assume it is this last one term you believe is confusing since it is the 'to be confirmed commit'. Perhaps we could have picked a better term - but as long as the description is clear (section 8.4 of RFC 6241), I think we are in a good enough state. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jonathan@hansfords.net Thu Sep 19 13:23:35 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54FD21F85EF for ; Thu, 19 Sep 2013 13:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlJM8awyrvEW for ; Thu, 19 Sep 2013 13:23:29 -0700 (PDT) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id D684521F8947 for ; Thu, 19 Sep 2013 13:23:28 -0700 (PDT) Received: from webmail.plus.net ([84.93.237.98]) by avasout04 with smtp id T8PS1m004283uBY018PTGQ; Thu, 19 Sep 2013 21:23:27 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=MqNrtQqe c=1 sm=1 tr=0 a=BJaFPv9AyABFDM2hXLRoEA==:117 a=ay7+waBXjX2gYBYtdgtTjg==:17 a=0Bzu9jTXAAAA:8 a=YehYk60mo_QA:10 a=dYCPD3cKDi0A:10 a=0B8HqoTn75oA:10 a=IkcTkHD0fZMA:10 a=6bkCdLdQAAAA:8 a=EBOSESyhAAAA:8 a=urOY2GcFnqMA:10 a=XejjvIVApJNYj4X8FmMA:9 a=QEXdDO2ut3YA:10 X-AUTH: hansfords+us:2500 Received: from hansfords.plus.com ([84.92.149.4]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Thu, 19 Sep 2013 21:23:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 19 Sep 2013 21:23:26 +0100 From: Jonathan Hansford To: In-Reply-To: <20130919201517.GA1886@elstar.local> References: <76a7f77cfd72c64ce0459f00d430df4d@imap.plus.net> <20130919201517.GA1886@elstar.local> Message-ID: <7fd4d189fd6346c514c58c312d1d4f6f@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [84.92.149.4] Subject: Re: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:23:35 -0000 On 2013-09-19 21:15, Juergen Schoenwaelder wrote: > On Thu, Sep 19, 2013 at 09:07:17PM +0100, Jonathan Hansford wrote: > >> After about two hours digging around in the NETCONF archive and then >> a >> Google search on "confirmed commit", I've come to the conclusion >> confirmed commit has come out of the JUNOS "commit confirmed" >> command. >> My guess is the JUNOS command is shorthand for "revert this commit >> after the timeout unless it is confirmed"; not exactly clear. >> Indeed, I >> would have thought "commit confirmed" would be the command to >> confirm >> the previous commit, though obviously that would overload the >> meaning >> of the original "commit" command since it would not persist without >> the >> confirmation. But "confirmed commit" implies the commit has been >> confirmed, not that it needs to be confirmed. Isn't this confusing >> to >> anyone else? > > There is the ':confirmed-commit' capability, there is the 'confirming > commit' and there is the initial commit which is sometimes called the > 'confirmed commit'. I assume it is this last one term you believe is > confusing since it is the 'to be confirmed commit'. Perhaps we could > have picked a better term - but as long as the description is clear > (section 8.4 of RFC 6241), I think we are in a good enough state. > > /js Thanks, you have confirmed (no pun intended) my reading of the RFC and I will use your definition of it being a 'to be confirmed commit' in my document. Jonathan From andy@yumaworks.com Thu Sep 19 13:39:33 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F4921F88B4 for ; Thu, 19 Sep 2013 13:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugNrIVL3Kh5q for ; Thu, 19 Sep 2013 13:39:29 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id 311A321F88DD for ; Thu, 19 Sep 2013 13:39:29 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id x12so5811093qcv.22 for ; Thu, 19 Sep 2013 13:39:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=76qTqCSmrBSL9fDT2Nzhjmwavl8e0LXOOxHyFmJOenE=; b=YjMYMZJRWlTXMvptKV9im/qo4d4QBUs5oUoiYzqJ9QT7EF1AUEHNNG/TZy/N8eMlow LoQFG7ULp3zeji/vv2cV5gk/L2cLw237bCTlfCFdUvuo5zoJ1uCRzFdQEZoGF+lmMIHS wH6Hlop5HQIxvS8lasalbqpkbvKwA0B+vGXNWJr5V4q3Kp+wpg0gPzxR5AIUO9Ym0vsS y2iN8ZHbOV2/tmx2q62EYabajUUp9Lk39/NMXrMaD08771UCU610IhNFHoBGLbBp4ScY Y84t30doyP+6YRw0hG0PcZL3ZNcOhC6M0eRsS6qRjr7yeL7A9Zb1YCR4SQlwzkt2wMRR bY4A== X-Gm-Message-State: ALoCoQkPYjEZ1ioV7m6NaMKePBaASkaFYYhFY4v178a9lCgX2K6NtIlWrr2p8waIvlW68Q2B6otn MIME-Version: 1.0 X-Received: by 10.224.130.72 with SMTP id r8mr1095855qas.32.1379623168481; Thu, 19 Sep 2013 13:39:28 -0700 (PDT) Received: by 10.140.26.209 with HTTP; Thu, 19 Sep 2013 13:39:28 -0700 (PDT) In-Reply-To: <20130919201517.GA1886@elstar.local> References: <76a7f77cfd72c64ce0459f00d430df4d@imap.plus.net> <20130919201517.GA1886@elstar.local> Date: Thu, 19 Sep 2013 13:39:28 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Jonathan Hansford , Netconf Content-Type: multipart/alternative; boundary=001a1132ec70e1ab2504e6c28c11 Subject: Re: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:39:34 -0000 --001a1132ec70e1ab2504e6c28c11 Content-Type: text/plain; charset=ISO-8859-1 Hi, I always found section 8.4.1, para 2 confusing. T0: /int8.1 does not exist > merge /int8.1 value=20 > commit confirmed confirm-timeout=60 T1: /int8.1 = 20 merge /int8.1 value=30 commit confirmed confirm-timeout=60 T2: /int8.1 = 30 T3: timeout occurs: para 6 says: If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the confirmed commit. The problem is that there are 2 confirmed commit operations. At time T3 does the server go back to state T1 or T0? (Our server goes back to T0). The 2nd commit contains a confirmed parameter, and para 2 sentence 2 clearly says this is not a confirming commit. The text does not actually define a "confirmed commit", but I assume it is a commit with a confirmed parameter. Therefore, paragraphs 5 - 7 are wrong where they refer to "the confirmed commit", because there are 2 of them. Andy On Thu, Sep 19, 2013 at 1:15 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Sep 19, 2013 at 09:07:17PM +0100, Jonathan Hansford wrote: > > > > > > After about two hours digging around in the NETCONF archive and then > > a Google search on "confirmed commit", I've come to the conclusion > > confirmed commit has come out of the JUNOS "commit confirmed" command. > > My guess is the JUNOS command is shorthand for "revert this commit after > > the timeout unless it is confirmed"; not exactly clear. Indeed, I would > > have thought "commit confirmed" would be the command to confirm the > > previous commit, though obviously that would overload the meaning of the > > original "commit" command since it would not persist without the > > confirmation. > > > > But "confirmed commit" implies the commit has been > > confirmed, not that it needs to be confirmed. Isn't this confusing to > > anyone else? > > There is the ':confirmed-commit' capability, there is the 'confirming > commit' and there is the initial commit which is sometimes called the > 'confirmed commit'. I assume it is this last one term you believe is > confusing since it is the 'to be confirmed commit'. Perhaps we could > have picked a better term - but as long as the description is clear > (section 8.4 of RFC 6241), I think we are in a good enough state. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a1132ec70e1ab2504e6c28c11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I always found section 8.4.1, para = 2 confusing.

T0: /int8.1 does not exist
=
=A0 =A0> merge /int8.1 value=3D20
=A0 =A0> c= ommit confirmed confirm-timeout=3D60

T1: /int8.1 =3D 20

=A0 =A0merg= e /int8.1 value=3D30
=A0 =A0commit confirmed confirm-timeout=3D60=

T2: /int8.1 =3D 30

T3: t= imeout occurs:

para 6 says:

   If a conf=
irming commit is not issued, the device will revert its
   configuration to the state prior to the issuance of the confirmed
   commit.

=
The problem is that there are 2 confirmed = commit operations.
At time T3 does the serv= er go back to state T1 or T0?
(Our server goes back to T0).

The 2nd commit contains = a confirmed parameter, and para 2
sentence = 2 clearly says this is not a confirming commit.
The text does not actually define a "confir= med commit",
but I assume it is a comm= it with a confirmed parameter.
Therefore, p= aragraphs 5 - 7 are wrong where they refer
to "the confirmed commit", because the= re are 2 of them.


Andy


<= br>
On Thu, Sep 19, 2013 at 1:15 PM, Juerge= n Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Sep 19, 2013 at 09:07:17PM +0100, Jonathan Hansfor= d wrote:
>
>
> After about two hours digging around in the NETCONF archive and then > a Google search on "confirmed commit", I've come to the = conclusion
> confirmed commit has come out of the JUNOS "commit confirmed"= ; command.
> My guess is the JUNOS command is shorthand for "revert this commi= t after
> the timeout unless it is confirmed"; not exactly clear. Indeed, I= would
> have thought "commit confirmed" would be the command to conf= irm the
> previous commit, though obviously that would overload the meaning of t= he
> original "commit" command since it would not persist without= the
> confirmation.
>
> But "confirmed commit" implies the commit has been
> confirmed, not that it needs to be confirmed. Isn't this confusing= to
> anyone else?

There is the ':confirmed-commit' capability, there is the 'conf= irming
commit' and there is the initial commit which is sometimes called the 'confirmed commit'. I assume it is this last one term you believe i= s
confusing since it is the 'to be confirmed commit'. Perhaps we coul= d
have picked a better term - but as long as the description is clear
(section 8.4 of RFC 6241), I think we are in a good enough state.

/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br> _______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--001a1132ec70e1ab2504e6c28c11-- From j.schoenwaelder@jacobs-university.de Thu Sep 19 22:13:28 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4B321F86B2 for ; Thu, 19 Sep 2013 22:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.172 X-Spam-Level: X-Spam-Status: No, score=-103.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOBGVfO4xu54 for ; Thu, 19 Sep 2013 22:13:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BFBC621F856A for ; Thu, 19 Sep 2013 22:13:22 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A84AB20C14; Fri, 20 Sep 2013 07:13:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4-28Z9L1NtUK; Fri, 20 Sep 2013 07:13:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15E9720C11; Fri, 20 Sep 2013 07:13:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A2CAD2873AB3; Fri, 20 Sep 2013 07:13:15 +0200 (CEST) Date: Fri, 20 Sep 2013 07:13:15 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130920051315.GA2835@elstar.local> Mail-Followup-To: Andy Bierman , Jonathan Hansford , Netconf References: <76a7f77cfd72c64ce0459f00d430df4d@imap.plus.net> <20130919201517.GA1886@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 05:13:29 -0000 On Thu, Sep 19, 2013 at 01:39:28PM -0700, Andy Bierman wrote: > Hi, > > I always found section 8.4.1, para 2 confusing. > > T0: /int8.1 does not exist > > > merge /int8.1 value=20 > > commit confirmed confirm-timeout=60 > > T1: /int8.1 = 20 > > merge /int8.1 value=30 > commit confirmed confirm-timeout=60 > > T2: /int8.1 = 30 > > T3: timeout occurs: > > para 6 says: > > If a confirming commit is not issued, the device will revert its > configuration to the state prior to the issuance of the confirmed > commit. > > > The problem is that there are 2 confirmed commit operations. > At time T3 does the server go back to state T1 or T0? > (Our server goes back to T0). > > The 2nd commit contains a confirmed parameter, and para 2 > sentence 2 clearly says this is not a confirming commit. > The text does not actually define a "confirmed commit", > but I assume it is a commit with a confirmed parameter. > Therefore, paragraphs 5 - 7 are wrong where they refer > to "the confirmed commit", because there are 2 of them. > Yes, this corner case where multiple confirmed commits are issued is not described well. Your interpretation that subsequent confirmed commits effectively extend the first one makes sense to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Thu Sep 19 23:41:55 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C39521F878F for ; Thu, 19 Sep 2013 23:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+oiJHifw9ZD for ; Thu, 19 Sep 2013 23:41:49 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7E721F8948 for ; Thu, 19 Sep 2013 23:41:47 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VMuPP-00077e-L2; Fri, 20 Sep 2013 08:41:46 +0200 Received: from kitten.ripe.net ([193.0.1.240] helo=[IPv6:::1]) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1VMuPP-0003Mx-DZ; Fri, 20 Sep 2013 08:41:43 +0200 Message-ID: <523BEE26.4070908@bwijnen.net> Date: Fri, 20 Sep 2013 08:41:42 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andy Bierman , Jonathan Hansford , Netconf References: <76a7f77cfd72c64ce0459f00d430df4d@imap.plus.net> <20130919201517.GA1886@elstar.local> <20130920051315.GA2835@elstar.local> In-Reply-To: <20130920051315.GA2835@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130920 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4ffd07ea786ba60165e949f5614242e21 Subject: Re: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 06:41:55 -0000 See at bottom On 9/20/13 7:13 AM, Juergen Schoenwaelder wrote: > On Thu, Sep 19, 2013 at 01:39:28PM -0700, Andy Bierman wrote: >> Hi, >> >> I always found section 8.4.1, para 2 confusing. >> >> T0: /int8.1 does not exist >> >> > merge /int8.1 value=20 >> > commit confirmed confirm-timeout=60 >> >> T1: /int8.1 = 20 >> >> merge /int8.1 value=30 >> commit confirmed confirm-timeout=60 >> >> T2: /int8.1 = 30 >> >> T3: timeout occurs: >> >> para 6 says: >> >> If a confirming commit is not issued, the device will revert its >> configuration to the state prior to the issuance of the confirmed >> commit. >> >> >> The problem is that there are 2 confirmed commit operations. >> At time T3 does the server go back to state T1 or T0? >> (Our server goes back to T0). >> >> The 2nd commit contains a confirmed parameter, and para 2 >> sentence 2 clearly says this is not a confirming commit. >> The text does not actually define a "confirmed commit", >> but I assume it is a commit with a confirmed parameter. >> Therefore, paragraphs 5 - 7 are wrong where they refer >> to "the confirmed commit", because there are 2 of them. >> > > Yes, this corner case where multiple confirmed commits are issued is > not described well. Your interpretation that subsequent confirmed > commits effectively extend the first one makes sense to me. > Can wee keep this somewhere so we clarify it if we ever have to open up and update the document? Bert > /js > From mbj@tail-f.com Thu Sep 19 23:48:17 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E6721F8443 for ; Thu, 19 Sep 2013 23:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5OQF7hPzO9i for ; Thu, 19 Sep 2013 23:48:11 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6377C21F898A for ; Thu, 19 Sep 2013 23:48:11 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A65971200434; Fri, 20 Sep 2013 08:48:08 +0200 (CEST) Date: Fri, 20 Sep 2013 08:48:08 +0200 (CEST) Message-Id: <20130920.084808.1683088744508333672.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130920051315.GA2835@elstar.local> References: <20130919201517.GA1886@elstar.local> <20130920051315.GA2835@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 06:48:17 -0000 Juergen Schoenwaelder wrote: > On Thu, Sep 19, 2013 at 01:39:28PM -0700, Andy Bierman wrote: > > Hi, > > > > I always found section 8.4.1, para 2 confusing. > > > > T0: /int8.1 does not exist > > > > > merge /int8.1 value=20 > > > commit confirmed confirm-timeout=60 > > > > T1: /int8.1 = 20 > > > > merge /int8.1 value=30 > > commit confirmed confirm-timeout=60 > > > > T2: /int8.1 = 30 > > > > T3: timeout occurs: > > > > para 6 says: > > > > If a confirming commit is not issued, the device will revert its > > configuration to the state prior to the issuance of the confirmed > > commit. > > > > > > The problem is that there are 2 confirmed commit operations. > > At time T3 does the server go back to state T1 or T0? > > (Our server goes back to T0). > > > > The 2nd commit contains a confirmed parameter, and para 2 > > sentence 2 clearly says this is not a confirming commit. > > The text does not actually define a "confirmed commit", > > but I assume it is a commit with a confirmed parameter. > > Therefore, paragraphs 5 - 7 are wrong where they refer > > to "the confirmed commit", because there are 2 of them. > > > > Yes, this corner case where multiple confirmed commits are issued is > not described well. Your interpretation that subsequent confirmed > commits effectively extend the first one makes sense to me. +1 /martin From bertietf@bwijnen.net Fri Sep 20 03:08:26 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D520221F8FDC for ; Fri, 20 Sep 2013 03:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-0+1mzuM3fy for ; Fri, 20 Sep 2013 03:08:21 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 80A8A21F8F97 for ; Fri, 20 Sep 2013 03:08:20 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VMxdI-0000kj-Mt; Fri, 20 Sep 2013 12:08:19 +0200 Received: from kitten.ripe.net ([193.0.1.240] helo=[IPv6:::1]) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1VMxdI-000766-Jt; Fri, 20 Sep 2013 12:08:16 +0200 Message-ID: <523C1E8F.5020207@bwijnen.net> Date: Fri, 20 Sep 2013 12:08:15 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: jonathan@hansfords.net References: <76a7f77cfd72c64ce0459f00d430df4d@imap.plus.net> <20130919201517.GA1886@elstar.local> <20130920051315.GA2835@elstar.local> <523BEE26.4070908@bwijnen.net> <535778763-1379664004-cardhu_decombobulator_blackberry.rim.net-1112072667-@b28.c4.bise7.blackberry> In-Reply-To: <535778763-1379664004-cardhu_decombobulator_blackberry.rim.net-1112072667-@b28.c4.bise7.blackberry> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130920 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd46effcedbad66cf7c5350e69c3d4b670c Cc: Netconf Subject: Re: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 10:08:27 -0000 THat is one (and probably good) approach. So can the authors/experts suggest some text that makes sense as a fix (or better clarification) to a possible erratum? Bert On 9/20/13 10:00 AM, Jonathan Hansford wrote: > Would it be worth agreeing text online then raising an erratum? > Sent from my BlackBerry > > -----Original Message----- > From: "Bert Wijnen (IETF)" > Date: Fri, 20 Sep 2013 08:41:42 > To: Andy Bierman; Jonathan Hansford; Netconf > Subject: Re: [Netconf] Confirmed commit > See at bottom > > On 9/20/13 7:13 AM, Juergen Schoenwaelder wrote: >> On Thu, Sep 19, 2013 at 01:39:28PM -0700, Andy Bierman wrote: >>> Hi, >>> >>> I always found section 8.4.1, para 2 confusing. >>> >>> T0: /int8.1 does not exist >>> >>> > merge /int8.1 value=20 >>> > commit confirmed confirm-timeout=60 >>> >>> T1: /int8.1 = 20 >>> >>> merge /int8.1 value=30 >>> commit confirmed confirm-timeout=60 >>> >>> T2: /int8.1 = 30 >>> >>> T3: timeout occurs: >>> >>> para 6 says: >>> >>> If a confirming commit is not issued, the device will revert its >>> configuration to the state prior to the issuance of the confirmed >>> commit. >>> >>> >>> The problem is that there are 2 confirmed commit operations. >>> At time T3 does the server go back to state T1 or T0? >>> (Our server goes back to T0). >>> >>> The 2nd commit contains a confirmed parameter, and para 2 >>> sentence 2 clearly says this is not a confirming commit. >>> The text does not actually define a "confirmed commit", >>> but I assume it is a commit with a confirmed parameter. >>> Therefore, paragraphs 5 - 7 are wrong where they refer >>> to "the confirmed commit", because there are 2 of them. >>> >> >> Yes, this corner case where multiple confirmed commits are issued is >> not described well. Your interpretation that subsequent confirmed >> commits effectively extend the first one makes sense to me. >> > > > Can wee keep this somewhere so we clarify it if we ever have to > open up and update the document? > > Bert >> /js >> From jonathan@hansfords.net Fri Sep 20 03:29:41 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCC921F90FD for ; Fri, 20 Sep 2013 03:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAkYsws5e41S for ; Fri, 20 Sep 2013 03:29:35 -0700 (PDT) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id AC82D21F9193 for ; Fri, 20 Sep 2013 03:29:33 -0700 (PDT) Received: from webmail.plus.net ([84.93.237.98]) by avasout04 with smtp id TNVX1m004283uBY01NVYD4; Fri, 20 Sep 2013 11:29:32 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=MqNrtQqe c=1 sm=1 tr=0 a=BJaFPv9AyABFDM2hXLRoEA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=lxldWUwtbAkA:10 a=dYCPD3cKDi0A:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=urOY2GcFnqMA:10 a=SUE4xeBjAAAA:8 a=xskcdSivAAAA:8 a=48vgC7mUAAAA:8 a=rPp2i0zUz4JSECK8f_wA:9 a=QEXdDO2ut3YA:10 a=jFPUFpGHtmAA:10 a=ChEcuLpljosA:10 a=1rgnPY4EEFsA:10 a=lZB815dzVvQA:10 a=F_-xGfPuGH-TOJ81glQA:9 a=9kjqu_gVvwLbRaF8:21 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 20 Sep 2013 11:29:31 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_24c5105c5f1ce0acd1a8e40ec92f820f" Date: Fri, 20 Sep 2013 11:29:31 +0100 From: Jonathan Hansford To: "Bert Wijnen (IETF)" Message-ID: X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] Cc: Netconf Subject: Re: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 10:29:41 -0000 --=_24c5105c5f1ce0acd1a8e40ec92f820f Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 I propose the following changes to address Andy's issue relating to consecutive confirmed commits and my issue relating to the confusing terminology: 8.4.1. Description (paras 2-6) A operation with the parameter (an unconfirmed ) MUST be reverted if a confirming commit is not issued within the timeout period (by default 600 seconds = 10 minutes). The confirming commit is a operation without the parameter and, if successful, cannot be reverted. The timeout period can be adjusted with the parameter. If a follow-up unconfirmed operation is issued before the timer expires, the timer is reset to the new value (600 seconds by default). Both the confirming commit and a follow-up unconfirmed operation MAY introduce additional changes to the configuration. If the element is not given in the unconfirmed commit operation, any follow-up commit and the confirming commit MUST be issued on the same session that issued the unconfirmed commit. If the element is given in the unconfirmed operation, a follow-up commit and the confirming commit can be given on any session, and they MUST include a element with a value equal to the given value of the element. If the server also advertises the :startup capability, a from running to startup is also necessary to save the changes to startup. If the session issuing a sequence of one or more unconfirmed commits is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the sequence of unconfirmed commits was issued, unless the last unconfirmed commit also included a element. If the device reboots for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the sequence of unconfirmed commits was issued. If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the first in the current sequence of unconfirmed commits. To cancel the current sequence of unconfirmed commits and revert changes without waiting for the confirm timeout to expire, the client can explicitly restore the configuration to its state before the sequence of unconfirmed commits was issued, by using the operation. : 8.4.4.1. Description: Cancels an ongoing sequence of unconfirmed commits. If the parameter is not given, the operation MUST be issued on the same session that issued the sequence of unconfirmed commits. Parameters: persist-id: Cancels a persistent sequence of unconfirmed commits. The value MUST be equal to the value given in the parameter to the operation. If the value does not match, the operation fails with an "invalid-value" error. : 8.4.5.1. The :confirmed-commit:1.1 capability allows 4 additional parameters to the operation. Parameters: confirmed: Perform an unconfirmed operation. confirm-timeout: Timeout period for confirmed commit, in seconds. If unspecified, the confirm timeout defaults to 600 seconds. persist: Make the unconfirmed commit survive a session termination, and set a token on the ongoing sequence of unconfirmed commits. persist-id: Used to issue a follow-up unconfirmed commit or a confirming commit from any session, with the token from the previous operation. On 2013-09-20 11:08, Bert Wijnen (IETF) wrote: > THat is one (and probably good) approach. > > So can the authors/experts suggest some text that makes > sense as a fix (or better clarification) to a possible > erratum? > > Bert > > On 9/20/13 10:00 AM, Jonathan Hansford wrote: > >> Would it be worth agreeing text online then raising an erratum? Sent from my BlackBerry -----Original Message----- From: "Bert Wijnen (IETF)" Date: Fri, 20 Sep 2013 08:41:42 To: Andy Bierman; Jonathan Hansford; Netconf Subject: Re: [Netconf] Confirmed commit See at bottom On 9/20/13 7:13 AM, Juergen Schoenwaelder wrote: >> >>> On Thu, Sep 19, 2013 at 01:39:28PM -0700, Andy Bierman wrote: >>> >>>> Hi, I always found section 8.4.1, para 2 confusing. T0: /int8.1 does not exist >>>> >>>>> merge /int8.1 value=20 commit confirmed confirm-timeout=60 >>>> T1: /int8.1 = 20 merge /int8.1 value=30 commit confirmed confirm-timeout=60 T2: /int8.1 = 30 T3: timeout occurs: para 6 says: If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the confirmed commit. The problem is that there are 2 confirmed commit operations. At time T3 does the server go back to state T1 or T0? (Our server goes back to T0). The 2nd commit contains a confirmed parameter, and para 2 sentence 2 clearly says this is not a confirming commit. The text does not actually define a "confirmed commit", but I assume it is a commit with a confirmed parameter. Therefore, paragraphs 5 - 7 are wrong where they refer to "the confirmed commit", because there are 2 of them. >>> Yes, this corner case where multiple confirmed commits are issued is not described well. Your interpretation that subsequent confirmed commits effectively extend the first one makes sense to me. >> Can wee keep this somewhere so we clarify it if we ever have to open up and update the document? Bert >> >>> /js Links: ------ [1] mailto:bertietf@bwijnen.net [2] mailto:andy@yumaworks.com [3] mailto:Jonathan@hansfords.net [4] mailto:netconf@ietf.org --=_24c5105c5f1ce0acd1a8e40ec92f820f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

I propose the following changes to address Andy's issue relating to cons= ecutive confirmed commits and my issue relating to the confusing terminolog= y:

8.4.1. Description (paras 2-6)
A <commit> operation with the = <confirmed> parameter (an unconfirmed <commit>) MUST be reverte= d if a confirming commit is not issued within the timeout period (by defaul= t 600 seconds =3D 10 minutes). The confirming commit is a <commit> op= eration without the <confirmed> parameter and, if successful, cannot = be reverted. The timeout period can be adjusted with the <confirm-timeou= t> parameter. If a follow-up unconfirmed <commit> operation is iss= ued before the timer expires, the timer is reset to the new value (600 seco= nds by default). Both the confirming commit and a follow-up unconfirmed <= ;commit> operation MAY introduce additional changes to the configuration= =2E
If the <persist> element is not given in the unconfirmed com= mit operation, any follow-up commit and the confirming commit MUST be issue= d on the same session that issued the unconfirmed commit. If the <persis= t> element is given in the unconfirmed <commit> operation, a follo= w-up commit and the confirming commit can be given on any session, and they= MUST include a <persist-id> element with a value equal to the given = value of the <persist> element.
If the server also advertises th= e :startup capability, a <copy-config> from running to startup is als= o necessary to save the changes to startup. If the session issuing a sequen= ce of one or more unconfirmed commits is terminated for any reason before t= he confirm timeout expires, the server MUST restore the configuration to it= s state before the sequence of unconfirmed commits was issued, unless the l= ast unconfirmed commit also included a <persist> element.
If the= device reboots for any reason before the confirm timeout expires, the serv= er MUST restore the configuration to its state before the sequence of uncon= firmed commits was issued.
If a confirming commit is not issued, the d= evice will revert its configuration to the state prior to the issuance of t= he first in the current sequence of unconfirmed commits. To cancel the curr= ent sequence of unconfirmed commits and revert changes without waiting for = the confirm timeout to expire, the client can explicitly restore the config= uration to its state before the sequence of unconfirmed commits was issued,= by using the <cancel-commit> operation.
:
8.4.4.1. <can= cel-commit>
Description:
Cancels an ongoing sequence of unconf= irmed commits. If the <persist-id> parameter is not given, the <ca= ncel-commit> operation MUST be issued on the same session that issued th= e sequence of unconfirmed commits.
Parameters:
persist-id:
C= ancels a persistent sequence of unconfirmed commits. The value MUST be equa= l to the value given in the <persist> parameter to the <commit>= operation. If the value does not match, the operation fails with an "inval= id-value" error.
:
8.4.5.1. <commit>
The :confirmed-co= mmit:1.1 capability allows 4 additional parameters to the <commit> op= eration.
Parameters:
confirmed:
Perform an unconfirmed <c= ommit> operation.
confirm-timeout:
Timeout period for confirme= d commit, in seconds. If unspecified, the confirm timeout defaults to 600 s= econds.
persist:
Make the unconfirmed commit survive a session te= rmination, and set a token on the ongoing sequence of unconfirmed commits= =2E
persist-id:
Used to issue a follow-up unconfirmed commit or a= confirming commit from any session, with the token from the previous <c= ommit> operation.


On 2013-09-20 11:08, Bert Wijnen (IETF) wrote:

THat is one (and probably good) approach.

So can the authors/experts suggest some text that makes
sense as a fix (or better clarification) to a possible
erratum?

Bert

On 9/20/13 10:00 AM, Jonathan Hansford wrote:
Would it be worth agreeing text onlin= e then raising an erratum? Sent from my BlackBerry -----Original Message---= -- From: "Bert Wijnen (IETF)" <b= ertietf@bwijnen.net> Date: Fri, 20 Sep 2013 08:41:42 To: Andy Bierma= n<andy@yumaworks.com>; Jona= than Hansford<Jonathan@hansfor= ds.net>; Netconf<netconf@ietf= =2Eorg> Subject: Re: [Netconf] Confirmed commit See at bottom On 9/2= 0/13 7:13 AM, Juergen Schoenwaelder wrote:
On Thu, Sep 19, 2013 at 01:39:28PM -0= 700, Andy Bierman wrote:
Hi, I always found section 8.4.1, par= a 2 confusing. T0: /int8.1 does not exist
merge /int8.1 value=3D20 commit confi= rmed confirm-timeout=3D60
T1: /int8.1 =3D 20 merge /int8.1 value=3D30 commit confirmed confirm-timeou= t=3D60 T2: /int8.1 =3D 30 T3: timeout occurs: para 6 says: If a confirming = commit is not issued, the device will revert its configuration to the state= prior to the issuance of the confirmed commit. The problem is that there a= re 2 confirmed commit operations. At time T3 does the server go back to sta= te T1 or T0? (Our server goes back to T0). The 2nd commit contains a confir= med parameter, and para 2 sentence 2 clearly says this is not a confirming = commit. The text does not actually define a "confirmed commit", but I assum= e it is a commit with a confirmed parameter. Therefore, paragraphs 5 - 7 ar= e wrong where they refer to "the confirmed commit", because there are 2 of = them.
Yes, this corner case where multiple confirmed commits are issued is not de= scribed well. Your interpretation that subsequent confirmed commits effecti= vely extend the first one makes sense to me.
Can wee keep this somewhere so we clarify it if we ever have to open up and= update the document? Bert
/js
--=_24c5105c5f1ce0acd1a8e40ec92f820f-- From jonathan@hansfords.net Fri Sep 20 03:41:27 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC2E21F9302 for ; Fri, 20 Sep 2013 03:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69qy-5mrL6bD for ; Fri, 20 Sep 2013 03:41:21 -0700 (PDT) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id AF36D21F9323 for ; Fri, 20 Sep 2013 03:41:20 -0700 (PDT) Received: from webmail.plus.net ([84.93.237.98]) by avasout04 with smtp id TNhJ1m009283uBY01NhKHf; Fri, 20 Sep 2013 11:41:19 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=MqNrtQqe c=1 sm=1 tr=0 a=BJaFPv9AyABFDM2hXLRoEA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=lxldWUwtbAkA:10 a=dYCPD3cKDi0A:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=urOY2GcFnqMA:10 a=SUE4xeBjAAAA:8 a=xskcdSivAAAA:8 a=48vgC7mUAAAA:8 a=rPp2i0zUz4JSECK8f_wA:9 a=QEXdDO2ut3YA:10 a=jFPUFpGHtmAA:10 a=ChEcuLpljosA:10 a=1rgnPY4EEFsA:10 a=lZB815dzVvQA:10 a=F_-xGfPuGH-TOJ81glQA:9 a=vN4dwRHMXWvb5fTD:21 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 20 Sep 2013 11:41:18 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a998706ac4616afc76219fe40225d69f" Date: Fri, 20 Sep 2013 11:41:18 +0100 From: Jonathan Hansford To: "Bert Wijnen (IETF)" In-Reply-To: References: Message-ID: <023fc00e33712ce3424be87abbd67937@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] Cc: Netconf Subject: Re: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 10:41:28 -0000 --=_a998706ac4616afc76219fe40225d69f Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 I realise these changes have a knock-on impact on other parts of the document (e.g. Appendices C and E), but I thought it important to try and propose core changes before visiting those other sections. On 2013-09-20 11:29, Jonathan Hansford wrote: > I propose the following changes to address Andy's issue relating to consecutive confirmed commits and my issue relating to the confusing terminology: > > 8.4.1. Description (paras 2-6) > A operation with the parameter (an unconfirmed ) MUST be reverted if a confirming commit is not issued within the timeout period (by default 600 seconds = 10 minutes). The confirming commit is a operation without the parameter and, if successful, cannot be reverted. The timeout period can be adjusted with the parameter. If a follow-up unconfirmed operation is issued before the timer expires, the timer is reset to the new value (600 seconds by default). Both the confirming commit and a follow-up unconfirmed operation MAY introduce additional changes to the configuration. > If the element is not given in the unconfirmed commit operation, any follow-up commit and the confirming commit MUST be issued on the same session that issued the unconfirmed commit. If the element is given in the unconfirmed operation, a follow-up commit and the confirming commit can be given on any session, and they MUST include a element with a value equal to the given value of the element. > If the server also advertises the :startup capability, a from running to startup is also necessary to save the changes to startup. If the session issuing a sequence of one or more unconfirmed commits is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the sequence of unconfirmed commits was issued, unless the last unconfirmed commit also included a element. > If the device reboots for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the sequence of unconfirmed commits was issued. > If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the first in the current sequence of unconfirmed commits. To cancel the current sequence of unconfirmed commits and revert changes without waiting for the confirm timeout to expire, the client can explicitly restore the configuration to its state before the sequence of unconfirmed commits was issued, by using the operation. > : > 8.4.4.1. > Description: > Cancels an ongoing sequence of unconfirmed commits. If the parameter is not given, the operation MUST be issued on the same session that issued the sequence of unconfirmed commits. > Parameters: > persist-id: > Cancels a persistent sequence of unconfirmed commits. The value MUST be equal to the value given in the parameter to the operation. If the value does not match, the operation fails with an "invalid-value" error. > : > 8.4.5.1. > The :confirmed-commit:1.1 capability allows 4 additional parameters to the operation. > Parameters: > confirmed: > Perform an unconfirmed operation. > confirm-timeout: > Timeout period for confirmed commit, in seconds. If unspecified, the confirm timeout defaults to 600 seconds. > persist: > Make the unconfirmed commit survive a session termination, and set a token on the ongoing sequence of unconfirmed commits. > persist-id: > Used to issue a follow-up unconfirmed commit or a confirming commit from any session, with the token from the previous operation. > > On 2013-09-20 11:08, Bert Wijnen (IETF) wrote: > >> THat is one (and probably good) approach. >> >> So can the authors/experts suggest some text that makes >> sense as a fix (or better clarification) to a possible >> erratum? >> >> Bert >> >> On 9/20/13 10:00 AM, Jonathan Hansford wrote: >> >>> Would it be worth agreeing text online then raising an erratum? Sent from my BlackBerry -----Original Message----- From: "Bert Wijnen (IETF)" Date: Fri, 20 Sep 2013 08:41:42 To: Andy Bierman; Jonathan Hansford; Netconf Subject: Re: [Netconf] Confirmed commit See at bottom On 9/20/13 7:13 AM, Juergen Schoenwaelder wrote: >>> >>>> On Thu, Sep 19, 2013 at 01:39:28PM -0700, Andy Bierman wrote: >>>> >>>>> Hi, I always found section 8.4.1, para 2 confusing. T0: /int8.1 does not exist >>>>> >>>>>> merge /int8.1 value=20 commit confirmed confirm-timeout=60 >>>>> T1: /int8.1 = 20 merge /int8.1 value=30 commit confirmed confirm-timeout=60 T2: /int8.1 = 30 T3: timeout occurs: para 6 says: If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the confirmed commit. The problem is that there are 2 confirmed commit operations. At time T3 does the server go back to state T1 or T0? (Our server goes back to T0). The 2nd commit contains a confirmed parameter, and para 2 sentence 2 clearly says this is not a confirming commit. The text does not actually define a "confirmed commit", but I assume it is a commit with a confirmed parameter. Therefore, paragraphs 5 - 7 are wrong where they refer to "the confirmed commit", because there are 2 of them. >>>> Yes, this corner case where multiple confirmed commits are issued is not described well. Your interpretation that subsequent confirmed commits effectively extend the first one makes sense to me. >>> Can wee keep this somewhere so we clarify it if we ever have to open up and update the document? Bert >>> >>>> /js Links: ------ [1] mailto:bertietf@bwijnen.net [2] mailto:andy@yumaworks.com [3] mailto:Jonathan@hansfords.net [4] mailto:netconf@ietf.org --=_a998706ac4616afc76219fe40225d69f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

I realise these changes have a knock-on impact on other parts of the doc= ument (e.g. Appendices C and E), but I thought it important to try and prop= ose core changes before visiting those other sections.

On 2013-09-20 11:29, Jonathan Hansford wrote:

I propose the following changes to address Andy's issue relating to cons= ecutive confirmed commits and my issue relating to the confusing terminolog= y:

8.4.1. Description (paras 2-6)
A <commit> operation with the = <confirmed> parameter (an unconfirmed <commit>) MUST be reverte= d if a confirming commit is not issued within the timeout period (by defaul= t 600 seconds =3D 10 minutes). The confirming commit is a <commit> op= eration without the <confirmed> parameter and, if successful, cannot = be reverted. The timeout period can be adjusted with the <confirm-timeou= t> parameter. If a follow-up unconfirmed <commit> operation is iss= ued before the timer expires, the timer is reset to the new value (600 seco= nds by default). Both the confirming commit and a follow-up unconfirmed <= ;commit> operation MAY introduce additional changes to the configuration= =2E
If the <persist> element is not given in the unconfirmed com= mit operation, any follow-up commit and the confirming commit MUST be issue= d on the same session that issued the unconfirmed commit. If the <persis= t> element is given in the unconfirmed <commit> operation, a follo= w-up commit and the confirming commit can be given on any session, and they= MUST include a <persist-id> element with a value equal to the given = value of the <persist> element.
If the server also advertises th= e :startup capability, a <copy-config> from running to startup is als= o necessary to save the changes to startup. If the session issuing a sequen= ce of one or more unconfirmed commits is terminated for any reason before t= he confirm timeout expires, the server MUST restore the configuration to it= s state before the sequence of unconfirmed commits was issued, unless the l= ast unconfirmed commit also included a <persist> element.
If the= device reboots for any reason before the confirm timeout expires, the serv= er MUST restore the configuration to its state before the sequence of uncon= firmed commits was issued.
If a confirming commit is not issued, the d= evice will revert its configuration to the state prior to the issuance of t= he first in the current sequence of unconfirmed commits. To cancel the curr= ent sequence of unconfirmed commits and revert changes without waiting for = the confirm timeout to expire, the client can explicitly restore the config= uration to its state before the sequence of unconfirmed commits was issued,= by using the <cancel-commit> operation.
:
8.4.4.1. <can= cel-commit>
Description:
Cancels an ongoing sequence of unconf= irmed commits. If the <persist-id> parameter is not given, the <ca= ncel-commit> operation MUST be issued on the same session that issued th= e sequence of unconfirmed commits.
Parameters:
persist-id:
C= ancels a persistent sequence of unconfirmed commits. The value MUST be equa= l to the value given in the <persist> parameter to the <commit>= operation. If the value does not match, the operation fails with an "inval= id-value" error.
:
8.4.5.1. <commit>
The :confirmed-co= mmit:1.1 capability allows 4 additional parameters to the <commit> op= eration.
Parameters:
confirmed:
Perform an unconfirmed <c= ommit> operation.
confirm-timeout:
Timeout period for confirme= d commit, in seconds. If unspecified, the confirm timeout defaults to 600 s= econds.
persist:
Make the unconfirmed commit survive a session te= rmination, and set a token on the ongoing sequence of unconfirmed commits= =2E
persist-id:
Used to issue a follow-up unconfirmed commit or a= confirming commit from any session, with the token from the previous <c= ommit> operation.


On 2013-09-20 11:08, Bert Wijnen (IETF) wrote:

THat is one (and probably good) approach.

So can the authors/experts suggest some text that makes
sense as a fix (or better clarification) to a possible
erratum?

Bert

On 9/20/13 10:00 AM, Jonathan Hansford wrote:
Would it be worth agreeing text online then = raising an erratum? Sent from my BlackBerry -----Original Message----- From= : "Bert Wijnen (IETF)" <bertietf= @bwijnen.net> Date: Fri, 20 Sep 2013 08:41:42 To: Andy Bierman<andy@yumaworks.com>; Jonathan Ha= nsford<Jonathan@hansfords.net<= /a>>; Netconf<netconf@ietf.org> Subject: Re: [Netconf] Confirmed commit See at bottom On 9/20/13 7:13= AM, Juergen Schoenwaelder wrote:
On Thu, Sep 19, 2013 at 01:39:28PM -0700, An= dy Bierman wrote:
Hi, I always found section 8.4.1, para 2 con= fusing. T0: /int8.1 does not exist
merge /int8.1 value=3D20 commit confirmed co= nfirm-timeout=3D60
T1: /int8.1 =3D 20 merge /int8.1 value=3D30 commit confirmed confirm-timeou= t=3D60 T2: /int8.1 =3D 30 T3: timeout occurs: para 6 says: If a confirming = commit is not issued, the device will revert its configuration to the state= prior to the issuance of the confirmed commit. The problem is that there a= re 2 confirmed commit operations. At time T3 does the server go back to sta= te T1 or T0? (Our server goes back to T0). The 2nd commit contains a confir= med parameter, and para 2 sentence 2 clearly says this is not a confirming = commit. The text does not actually define a "confirmed commit", but I assum= e it is a commit with a confirmed parameter. Therefore, paragraphs 5 - 7 ar= e wrong where they refer to "the confirmed commit", because there are 2 of = them.
Yes, this corner case where multiple confirmed commits are issued is not de= scribed well. Your interpretation that subsequent confirmed commits effecti= vely extend the first one makes sense to me.
Can wee keep this somewhere so we clarify it if we ever have to open up and= update the document? Bert
/js
--=_a998706ac4616afc76219fe40225d69f-- From mbj@tail-f.com Fri Sep 20 03:57:28 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EC421F93F8 for ; Fri, 20 Sep 2013 03:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNEcFQ1nUNqa for ; Fri, 20 Sep 2013 03:57:22 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E566D21F92CD for ; Fri, 20 Sep 2013 03:57:21 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 03806120043D; Fri, 20 Sep 2013 12:57:19 +0200 (CEST) Date: Fri, 20 Sep 2013 12:57:18 +0200 (CEST) Message-Id: <20130920.125718.2241274183066609324.mbj@tail-f.com> To: Jonathan@hansfords.net From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 10:57:28 -0000 Hi, I don't think we should change the terminology in an errata. (and actually I don't think we should change it at all - I agree there might be a better term, but the term "confirmed commit" has been used for several years and people are used to it) Your text about sequence of commits is fine; but I think we should stick to the current terminology. /martin Jonathan Hansford wrote: > > > I propose the following changes to address Andy's issue relating to > consecutive confirmed commits and my issue relating to the confusing > terminology: > > 8.4.1. Description (paras 2-6) > A operation with > the parameter (an unconfirmed ) MUST be reverted if > a confirming commit is not issued within the timeout period (by default > 600 seconds = 10 minutes). The confirming commit is a operation > without the parameter and, if successful, cannot be > reverted. The timeout period can be adjusted with the > parameter. If a follow-up unconfirmed operation is issued > before the timer expires, the timer is reset to the new value (600 > seconds by default). Both the confirming commit and a follow-up > unconfirmed operation MAY introduce additional changes to the > configuration. > If the element is not given in the unconfirmed > commit operation, any follow-up commit and the confirming commit MUST be > issued on the same session that issued the unconfirmed commit. If the > element is given in the unconfirmed operation, a > follow-up commit and the confirming commit can be given on any session, > and they MUST include a element with a value equal to the > given value of the element. > If the server also advertises the > :startup capability, a from running to startup is also > necessary to save the changes to startup. If the session issuing a > sequence of one or more unconfirmed commits is terminated for any reason > before the confirm timeout expires, the server MUST restore the > configuration to its state before the sequence of unconfirmed commits > was issued, unless the last unconfirmed commit also included a > element. > If the device reboots for any reason before the confirm timeout > expires, the server MUST restore the configuration to its state before > the sequence of unconfirmed commits was issued. > If a confirming commit > is not issued, the device will revert its configuration to the state > prior to the issuance of the first in the current sequence of > unconfirmed commits. To cancel the current sequence of unconfirmed > commits and revert changes without waiting for the confirm timeout to > expire, the client can explicitly restore the configuration to its state > before the sequence of unconfirmed commits was issued, by using the > operation. > : > 8.4.4.1. > > Description: > Cancels an ongoing sequence of unconfirmed > commits. If the parameter is not given, the > operation MUST be issued on the same session that issued the sequence of > unconfirmed commits. > Parameters: > persist-id: > Cancels a persistent > sequence of unconfirmed commits. The value MUST be equal to the value > given in the parameter to the operation. If the value > does not match, the operation fails with an "invalid-value" > error. > : > 8.4.5.1. > The :confirmed-commit:1.1 capability allows 4 > additional parameters to the > operation. > Parameters: > confirmed: > Perform an unconfirmed > operation. > confirm-timeout: > Timeout period for confirmed commit, in > seconds. If unspecified, the confirm timeout defaults to 600 > seconds. > persist: > Make the unconfirmed commit survive a session > termination, and set a token on the ongoing sequence of unconfirmed > commits. > persist-id: > Used to issue a follow-up unconfirmed commit or a > confirming commit from any session, with the token from the previous > operation. > > On 2013-09-20 11:08, Bert Wijnen (IETF) wrote: > > > > THat is one (and probably good) approach. > > > > So can the > authors/experts suggest some text that makes > > sense as a fix (or better > clarification) to a possible > > erratum? > > > > Bert > > > > On 9/20/13 10:00 > AM, Jonathan Hansford wrote: > > > >> Would it be worth agreeing text > online then raising an erratum? Sent from my BlackBerry -----Original > Message----- From: "Bert Wijnen (IETF)" Date: > Fri, 20 Sep 2013 08:41:42 To: Andy Bierman; > Jonathan Hansford; Netconf [4]> Subject: Re: [Netconf] Confirmed commit See at bottom On 9/20/13 > 7:13 AM, Juergen Schoenwaelder wrote: > >> > >>> On Thu, Sep 19, 2013 at > 01:39:28PM -0700, Andy Bierman wrote: > >>> > >>>> Hi, I always found > section 8.4.1, para 2 confusing. T0: /int8.1 does not exist > >>>> > >>>>> > merge /int8.1 value=20 commit confirmed confirm-timeout=60 > >>>> T1: > /int8.1 = 20 merge /int8.1 value=30 commit confirmed confirm-timeout=60 > T2: /int8.1 = 30 T3: timeout occurs: para 6 says: If a confirming commit > is not issued, the device will revert its configuration to the state > prior to the issuance of the confirmed commit. The problem is that there > are 2 confirmed commit operations. At time T3 does the server go back to > state T1 or T0? (Our server goes back to T0). The 2nd commit contains a > confirmed parameter, and para 2 sentence 2 clearly says this is not a > confirming commit. The text does not actually define a "confirmed > commit", but I assume it is a commit with a confirmed parameter. > Therefore, paragraphs 5 - 7 are wrong where they refer to "the confirmed > commit", because there are 2 of them. > >>> Yes, this corner case where > multiple confirmed commits are issued is not described well. Your > interpretation that subsequent confirmed commits effectively extend the > first one makes sense to me. > >> Can wee keep this somewhere so we > clarify it if we ever have to open up and update the document? Bert > >> > > >>> /js > > > Links: > ------ > [1] mailto:bertietf@bwijnen.net > [2] > mailto:andy@yumaworks.com > [3] mailto:Jonathan@hansfords.net > [4] > mailto:netconf@ietf.org From jonathan@hansfords.net Fri Sep 20 04:50:19 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196A321F96ED for ; Fri, 20 Sep 2013 04:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9MpZjVHh8SF for ; Fri, 20 Sep 2013 04:50:12 -0700 (PDT) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id 259BD21F8531 for ; Fri, 20 Sep 2013 04:50:11 -0700 (PDT) Received: from webmail.plus.net ([84.93.237.98]) by avasout04 with smtp id TPq51m006283uBY01Pq6JD; Fri, 20 Sep 2013 12:50:07 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=MqNrtQqe c=1 sm=1 tr=0 a=BJaFPv9AyABFDM2hXLRoEA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=lxldWUwtbAkA:10 a=dYCPD3cKDi0A:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=urOY2GcFnqMA:10 a=WsHRSziEuBKHsdT8Qo4A:9 a=QEXdDO2ut3YA:10 a=ZW4rysBpQiurvS_4lI4A:9 a=yRx7HFGvrmKr19nn:21 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 20 Sep 2013 12:50:05 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_2c165fa68fdb55f3f55b7d2702e87fbf" Date: Fri, 20 Sep 2013 12:50:05 +0100 From: Jonathan Hansford To: Martin Bjorklund In-Reply-To: <20130920.125718.2241274183066609324.mbj@tail-f.com> References: <20130920.125718.2241274183066609324.mbj@tail-f.com> Message-ID: <024d2c7822969b9b4ba0b3fdaabb393a@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 11:50:19 -0000 --=_2c165fa68fdb55f3f55b7d2702e87fbf Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Hi, I agree that changing the terminology would be confusing for those who are used to it, but in its current form it is extremely confusing to those who come to it cold. To my mind there needs, at least, to be something that seeks to explain the current terminology. It has taken me several readings, a trawl of the NETCONF list archive and Internet search to reach some kind of understanding and even then it had to be confirmed by someone "in the know". However, putting that to one side for now, my text without the changed terminology becomes: 8.4.1. Description (paras 2-6) A operation with the parameter (an unconfirmed ) MUST be reverted if a confirming commit is not issued within the timeout period (by default 600 seconds = 10 minutes). The confirming commit is a operation without the parameter and, if successful, cannot be reverted. The timeout period can be adjusted with the parameter. If a follow-up unconfirmed operation is issued before the timer expires, the timer is reset to the new value (600 seconds by default). Both the confirming commit and a follow-up unconfirmed operation MAY introduce additional changes to the configuration. If the element is not given in the unconfirmed commit operation, any follow-up commit and the confirming commit MUST be issued on the same session that issued the unconfirmed commit. If the element is given in the unconfirmed operation, a follow-up commit and the confirming commit can be given on any session, and they MUST include a element with a value equal to the given value of the element. If the server also advertises the :startup capability, a from running to startup is also necessary to save the changes to startup. If the session issuing a sequence of one or more unconfirmed commits is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the sequence of unconfirmed commits was issued, unless the last unconfirmed commit also included a element. If the device reboots for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the sequence of unconfirmed commits was issued. If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the first in the current sequence of unconfirmed commits. To cancel the current sequence of unconfirmed commits and revert changes without waiting for the confirm timeout to expire, the client can explicitly restore the configuration to its state before the sequence of unconfirmed commits was issued, by using the operation. : 8.4.4.1. Description: Cancels an ongoing sequence of unconfirmed commits. If the parameter is not given, the operation MUST be issued on the same session that issued the sequence of unconfirmed commits. Parameters: persist-id: Cancels a persistent sequence of unconfirmed commits. The value MUST be equal to the value given in the parameter to the operation. If the value does not match, the operation fails with an "invalid-value" error. : 8.4.5.1. The :confirmed-commit:1.1 capability allows 4 additional parameters to the operation. Parameters: confirmed: Perform an unconfirmed operation. confirm-timeout: Timeout period for confirmed commit, in seconds. If unspecified, the confirm timeout defaults to 600 seconds. persist: Make the unconfirmed commit survive a session termination, and set a token on the ongoing sequence of unconfirmed commits. persist-id: Used to issue a follow-up unconfirmed commit or a confirming commit from any session, with the token from the previous operation. Jonathan On 2013-09-20 11:57, Martin Bjorklund wrote: > Hi, > > I don't think we should change the terminology in an errata. > (and actually I don't think we should change it at all - I agree there > might be a better term, but the term "confirmed commit" has been used > for several years and people are used to it) > > Your text about sequence of commits is fine; but I think we should > stick to the current terminology. > > /martin --=_2c165fa68fdb55f3f55b7d2702e87fbf Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi,

I agree that changing the terminology would be confusing for those who a= re used to it, but in its current form it is extremely confusing to those w= ho come to it cold. To my mind there needs, at least, to be something that = seeks to explain the current terminology. It has taken me several readings,= a trawl of the NETCONF list archive and Internet search to reach some kind= of understanding and even then it had to be confirmed by someone "in the k= now".

However, putting that to one side for now, my text without the changed t= erminology becomes:

8.4.1. Description (paras 2-6)
A <commit> operation with the = <confirmed> parameter (an unconfirmed <commit>) MUST be reverte= d if a confirming commit is not issued within the timeout period (by defaul= t 600 seconds =3D 10 minutes). The confirming commit is a <commit> op= eration without the <confirmed> parameter and, if successful, cannot = be reverted. The timeout period can be adjusted with the <confirm-timeou= t> parameter. If a follow-up unconfirmed <commit> operation is iss= ued before the timer expires, the timer is reset to the new value (600 seco= nds by default). Both the confirming commit and a follow-up unconfirmed <= ;commit> operation MAY introduce additional changes to the configuration= =2E
If the <persist> element is not given in the unconfirmed com= mit operation, any follow-up commit and the confirming commit MUST be issue= d on the same session that issued the unconfirmed commit. If the <persis= t> element is given in the unconfirmed <commit> operation, a follo= w-up commit and the confirming commit can be given on any session, and they= MUST include a <persist-id> element with a value equal to the given = value of the <persist> element.
If the server also advertises th= e :startup capability, a <copy-config> from running to startup is als= o necessary to save the changes to startup. If the session issuing a sequen= ce of one or more unconfirmed commits is terminated for any reason before t= he confirm timeout expires, the server MUST restore the configuration to it= s state before the sequence of unconfirmed commits was issued, unless the l= ast unconfirmed commit also included a <persist> element.
If the= device reboots for any reason before the confirm timeout expires, the serv= er MUST restore the configuration to its state before the sequence of uncon= firmed commits was issued.
If a confirming commit is not issued, the d= evice will revert its configuration to the state prior to the issuance of t= he first in the current sequence of unconfirmed commits. To cancel the curr= ent sequence of unconfirmed commits and revert changes without waiting for = the confirm timeout to expire, the client can explicitly restore the config= uration to its state before the sequence of unconfirmed commits was issued,= by using the <cancel-commit> operation.
:
8.4.4.1. <can= cel-commit>
Description:
Cancels an ongoing sequence of unconf= irmed commits. If the <persist-id> parameter is not given, the <ca= ncel-commit> operation MUST be issued on the same session that issued th= e sequence of unconfirmed commits.
Parameters:
persist-id:
C= ancels a persistent sequence of unconfirmed commits. The value MUST be equa= l to the value given in the <persist> parameter to the <commit>= operation. If the value does not match, the operation fails with an "inval= id-value" error.
:
8.4.5.1. <commit>
The :confirmed-co= mmit:1.1 capability allows 4 additional parameters to the <commit> op= eration.
Parameters:
confirmed:
Perform an unconfirmed <c= ommit> operation.
confirm-timeout:
Timeout period for confirme= d commit, in seconds. If unspecified, the confirm timeout defaults to 600 s= econds.
persist:
Make the unconfirmed commit survive a session te= rmination, and set a token on the ongoing sequence of unconfirmed commits= =2E
persist-id:
Used to issue a follow-up unconfirmed commit or a= confirming commit from any session, with the token from the previous <c= ommit> operation.

Jonathan

On 2013-09-20 11:57, Martin Bjorklund wrote:

Hi,

I don't think we should change the terminology in an errata.
(and actually I don't think we should change it at all - I agree there
might be a better term, but the term "confirmed commit" has been used
for several years and people are used to it)

Your text about sequence of commits is fine; but I think we should
stick to the current terminology.


/martin
--=_2c165fa68fdb55f3f55b7d2702e87fbf-- From bertietf@bwijnen.net Fri Sep 20 04:58:34 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FC221F9477 for ; Fri, 20 Sep 2013 04:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsYb0+OGTgmF for ; Fri, 20 Sep 2013 04:58:22 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id BE68221F93F3 for ; Fri, 20 Sep 2013 04:58:21 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VMzLj-0006Nx-De; Fri, 20 Sep 2013 13:58:18 +0200 Received: from kitten.ripe.net ([193.0.1.240] helo=[IPv6:::1]) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1VMzLi-0004xR-WB; Fri, 20 Sep 2013 13:58:15 +0200 Message-ID: <523C3856.9040304@bwijnen.net> Date: Fri, 20 Sep 2013 13:58:14 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Martin Bjorklund References: <20130920.125718.2241274183066609324.mbj@tail-f.com> In-Reply-To: <20130920.125718.2241274183066609324.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130920 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4cafc45d3a039c63390849b67e7f88d5a Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 11:58:34 -0000 Speaking as a technical contributor. I also think we should stick to the terminology we have been using for many years now. So I was thinking more about some clarifying or explanatory text instead of renaming our terminology. Bert On 9/20/13 12:57 PM, Martin Bjorklund wrote: > Hi, > > I don't think we should change the terminology in an errata. > (and actually I don't think we should change it at all - I agree there > might be a better term, but the term "confirmed commit" has been used > for several years and people are used to it) > > Your text about sequence of commits is fine; but I think we should > stick to the current terminology. > > > /martin > > > Jonathan Hansford wrote: >> >> >> I propose the following changes to address Andy's issue relating to >> consecutive confirmed commits and my issue relating to the confusing >> terminology: >> >> 8.4.1. Description (paras 2-6) >> A operation with >> the parameter (an unconfirmed ) MUST be reverted if >> a confirming commit is not issued within the timeout period (by default >> 600 seconds = 10 minutes). The confirming commit is a operation >> without the parameter and, if successful, cannot be >> reverted. The timeout period can be adjusted with the >> parameter. If a follow-up unconfirmed operation is issued >> before the timer expires, the timer is reset to the new value (600 >> seconds by default). Both the confirming commit and a follow-up >> unconfirmed operation MAY introduce additional changes to the >> configuration. >> If the element is not given in the unconfirmed >> commit operation, any follow-up commit and the confirming commit MUST be >> issued on the same session that issued the unconfirmed commit. If the >> element is given in the unconfirmed operation, a >> follow-up commit and the confirming commit can be given on any session, >> and they MUST include a element with a value equal to the >> given value of the element. >> If the server also advertises the >> :startup capability, a from running to startup is also >> necessary to save the changes to startup. If the session issuing a >> sequence of one or more unconfirmed commits is terminated for any reason >> before the confirm timeout expires, the server MUST restore the >> configuration to its state before the sequence of unconfirmed commits >> was issued, unless the last unconfirmed commit also included a >> element. >> If the device reboots for any reason before the confirm timeout >> expires, the server MUST restore the configuration to its state before >> the sequence of unconfirmed commits was issued. >> If a confirming commit >> is not issued, the device will revert its configuration to the state >> prior to the issuance of the first in the current sequence of >> unconfirmed commits. To cancel the current sequence of unconfirmed >> commits and revert changes without waiting for the confirm timeout to >> expire, the client can explicitly restore the configuration to its state >> before the sequence of unconfirmed commits was issued, by using the >> operation. >> : >> 8.4.4.1. >> >> Description: >> Cancels an ongoing sequence of unconfirmed >> commits. If the parameter is not given, the >> operation MUST be issued on the same session that issued the sequence of >> unconfirmed commits. >> Parameters: >> persist-id: >> Cancels a persistent >> sequence of unconfirmed commits. The value MUST be equal to the value >> given in the parameter to the operation. If the value >> does not match, the operation fails with an "invalid-value" >> error. >> : >> 8.4.5.1. >> The :confirmed-commit:1.1 capability allows 4 >> additional parameters to the >> operation. >> Parameters: >> confirmed: >> Perform an unconfirmed >> operation. >> confirm-timeout: >> Timeout period for confirmed commit, in >> seconds. If unspecified, the confirm timeout defaults to 600 >> seconds. >> persist: >> Make the unconfirmed commit survive a session >> termination, and set a token on the ongoing sequence of unconfirmed >> commits. >> persist-id: >> Used to issue a follow-up unconfirmed commit or a >> confirming commit from any session, with the token from the previous >> operation. >> >> On 2013-09-20 11:08, Bert Wijnen (IETF) wrote: >> >>> >> THat is one (and probably good) approach. >>> >>> So can the >> authors/experts suggest some text that makes >>> sense as a fix (or better >> clarification) to a possible >>> erratum? >>> >>> Bert >>> >>> On 9/20/13 10:00 >> AM, Jonathan Hansford wrote: >>> >>>> Would it be worth agreeing text >> online then raising an erratum? Sent from my BlackBerry -----Original >> Message----- From: "Bert Wijnen (IETF)" Date: >> Fri, 20 Sep 2013 08:41:42 To: Andy Bierman; >> Jonathan Hansford; Netconf> [4]> Subject: Re: [Netconf] Confirmed commit See at bottom On 9/20/13 >> 7:13 AM, Juergen Schoenwaelder wrote: >>>> >>>>> On Thu, Sep 19, 2013 at >> 01:39:28PM -0700, Andy Bierman wrote: >>>>> >>>>>> Hi, I always found >> section 8.4.1, para 2 confusing. T0: /int8.1 does not exist >>>>>> >>>>>>> >> merge /int8.1 value=20 commit confirmed confirm-timeout=60 >>>>>> T1: >> /int8.1 = 20 merge /int8.1 value=30 commit confirmed confirm-timeout=60 >> T2: /int8.1 = 30 T3: timeout occurs: para 6 says: If a confirming commit >> is not issued, the device will revert its configuration to the state >> prior to the issuance of the confirmed commit. The problem is that there >> are 2 confirmed commit operations. At time T3 does the server go back to >> state T1 or T0? (Our server goes back to T0). The 2nd commit contains a >> confirmed parameter, and para 2 sentence 2 clearly says this is not a >> confirming commit. The text does not actually define a "confirmed >> commit", but I assume it is a commit with a confirmed parameter. >> Therefore, paragraphs 5 - 7 are wrong where they refer to "the confirmed >> commit", because there are 2 of them. >>>>> Yes, this corner case where >> multiple confirmed commits are issued is not described well. Your >> interpretation that subsequent confirmed commits effectively extend the >> first one makes sense to me. >>>> Can wee keep this somewhere so we >> clarify it if we ever have to open up and update the document? Bert >>>> >> >>>>> /js >> >> >> Links: >> ------ >> [1] mailto:bertietf@bwijnen.net >> [2] >> mailto:andy@yumaworks.com >> [3] mailto:Jonathan@hansfords.net >> [4] >> mailto:netconf@ietf.org > From jonathan@hansfords.net Fri Sep 20 05:50:30 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B5321F991E for ; Fri, 20 Sep 2013 05:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asrIjPUYLqon for ; Fri, 20 Sep 2013 05:50:20 -0700 (PDT) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0F221F98EE for ; Fri, 20 Sep 2013 05:50:18 -0700 (PDT) Received: from webmail.plus.net ([84.93.237.98]) by avasout04 with smtp id TQqG1m003283uBY01QqHiW; Fri, 20 Sep 2013 13:50:17 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=MqNrtQqe c=1 sm=1 tr=0 a=BJaFPv9AyABFDM2hXLRoEA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=lxldWUwtbAkA:10 a=dYCPD3cKDi0A:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=urOY2GcFnqMA:10 a=SUE4xeBjAAAA:8 a=xskcdSivAAAA:8 a=48vgC7mUAAAA:8 a=rihGqeaeGMNJ_zN5TosA:9 a=j687ffqgWN9L1c5g:21 a=e7DWD138tDqp-C0T:21 a=QEXdDO2ut3YA:10 a=1rgnPY4EEFsA:10 a=jFPUFpGHtmAA:10 a=ChEcuLpljosA:10 a=lZB815dzVvQA:10 a=mKXWlFheUt9OwBv7ot4A:9 a=n2YzEJjhoVO3ULyy:21 a=Y1PkaJMBiVD0VzhX:21 a=jGZpr6vZ-Cc2wpE3:21 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Fri, 20 Sep 2013 13:50:16 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_404faad83dccbb8ce4012f39b0cd2982" Date: Fri, 20 Sep 2013 13:50:16 +0100 From: Jonathan Hansford To: "Bert Wijnen (IETF)" In-Reply-To: <523C3856.9040304@bwijnen.net> References: <20130920.125718.2241274183066609324.mbj@tail-f.com> <523C3856.9040304@bwijnen.net> Message-ID: X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 12:50:30 -0000 --=_404faad83dccbb8ce4012f39b0cd2982 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 In order to address the terminology issue without changing the terminology, how about changing the first paragraph of 8.4.1 to: The :confirmed-commit:1.1 capability indicates that the server will support the operation, the , , , and parameters for the operation, and differentiate between a "to be confirmed" operation (a "confirmed commit") and a confirming operation. See Section 8.3 for further details on the operation. Jonathan On 2013-09-20 12:58, Bert Wijnen (IETF) wrote: > Speaking as a technical contributor. > > I also think we should stick to the terminology we have been using for > many years now. So I was thinking more about some clarifying or explanatory > text instead of renaming our terminology. > > Bert > > On 9/20/13 12:57 PM, Martin Bjorklund wrote: > >> Hi, I don't think we should change the terminology in an errata. (and actually I don't think we should change it at all - I agree there might be a better term, but the term "confirmed commit" has been used for several years and people are used to it) Your text about sequence of commits is fine; but I think we should stick to the current terminology. /martin Jonathan Hansford wrote: >> >>> I propose the following changes to address Andy's issue relating to consecutive confirmed commits and my issue relating to the confusing terminology: 8.4.1. Description (paras 2-6) A operation with the parameter (an unconfirmed ) MUST be reverted if a confirming commit is not issued within the timeout period (by default 600 seconds = 10 minutes). The confirming commit is a operation without the parameter and, if successful, cannot be reverted. The timeout period can be adjusted with the parameter. If a follow-up unconfirmed operation is issued before the timer expires, the timer is reset to the new value (600 seconds by default). Both the confirming commit and a follow-up unconfirmed operation MAY introduce additional changes to the configuration. If the element is not given in the unconfirmed commit operation, any follow-up commit and the confirming commit MUST be issued on the same session that issued the unconfirmed commit. If the element is given in the unconfirmed operation, a follow-up commit and the confirming commit can be given on any session, and they MUST include a element with a value equal to the given value of the element. If the server also advertises the :startup capability, a from running to startup is also necessary to save the changes to startup. If the session issuing a sequence of one or more unconfirmed commits is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the sequence of unconfirmed commits was issued, unless the last unconfirmed commit also included a element. If the device reboots for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the sequence of unconfirmed commits was issued. If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the first in the current sequence of unconfirmed commits. To cancel the current sequence of unconfirmed commits and revert changes without waiting for the confirm timeout to expire, the client can explicitly restore the configuration to its state before the sequence of unconfirmed commits was issued, by using the operation. : 8.4.4.1. Description: Cancels an ongoing sequence of unconfirmed commits. If the parameter is not given, the operation MUST be issued on the same session that issued the sequence of unconfirmed commits. Parameters: persist-id: Cancels a persistent sequence of unconfirmed commits. The value MUST be equal to the value given in the parameter to the operation. If the value does not match, the operation fails with an "invalid-value" error. : 8.4.5.1. The :confirmed-commit:1.1 capability allows 4 additional parameters to the operation. Parameters: confirmed: Perform an unconfirmed operation. confirm-timeout: Timeout period for confirmed commit, in seconds. If unspecified, the confirm timeout defaults to 600 seconds. persist: Make the unconfirmed commit survive a session termination, and set a token on the ongoing sequence of unconfirmed commits. persist-id: Used to issue a follow-up unconfirmed commit or a confirming commit from any session, with the token from the previous operation. On 2013-09-20 11:08, Bert Wijnen (IETF) wrote:THat is one (and probably good) approach. >>> >>>> So can the >>> authors/experts suggest some text that makes >>> >>>> sense as a fix (or better >>> clarification) to a possible Yes, this corner case where multiple confirmed commits are issued is not described well. Your interpretation that subsequent confirmed commits effectively extend the first one makes sense to me. Can wee keep this somewhere so we clarify it if we ever have to open up and update the document? Bert Links: ------ [1] mailto:bertietf@bwijnen.net [2] mailto:andy@yumaworks.com [3] mailto:Jonathan@hansfords.net [4] mailto:netconf@ietf.org [5] mailto:andy@yumaworks.com [6] mailto:Jonathan@hansfords.net [7] mailto:netconf@ietf.org [8] mailto:Jonathan@hansfords.net --=_404faad83dccbb8ce4012f39b0cd2982 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

In order to address the terminology issue without changing the terminolo= gy, how about changing the first paragraph of 8.4.1 to:

The :confirmed-commit:1.1 capability indicates that the server will supp= ort the <cancel-commit> operation, the <confirmed>, <confirm= -timeout>, <persist>, and <persist-id> parameters for the &l= t;commit> operation, and differentiate between a “to be confirmed&= rdquo; <commit> operation (a “confirmed commit”) and a co= nfirming <commit> operation. See Section 8.3 for further details on t= he <commit> operation.

Jonathan

On 2013-09-20 12:58, Bert Wijnen (IETF) wrote:

Speaking as a technical contributor.

I also think we should stick to the terminology we have been using for
many years now. So I was thinking more about some clarifying or explanatory
text instead of renaming our terminology.

Bert

On 9/20/13 12:57 PM, Martin Bjorklund wrote:
Hi, I don't think we should change th= e terminology in an errata. (and actually I don't think we should change it= at all - I agree there might be a better term, but the term "confirmed com= mit" has been used for several years and people are used to it) Your text a= bout sequence of commits is fine; but I think we should stick to the curren= t terminology. /martin Jonathan Hansford <Jonathan@hansfords.net> wrote:
I propose the following changes to ad= dress Andy's issue relating to consecutive confirmed commits and my issue r= elating to the confusing terminology: 8.4.1. Description (paras 2-6) A <= commit> operation with the <confirmed> parameter (an unconfirmed &= lt;commit>) MUST be reverted if a confirming commit is not issued within= the timeout period (by default 600 seconds =3D 10 minutes). The confirming= commit is a <commit> operation without the <confirmed> paramet= er and, if successful, cannot be reverted. The timeout period can be adjust= ed with the <confirm-timeout> parameter. If a follow-up unconfirmed &= lt;commit> operation is issued before the timer expires, the timer is re= set to the new value (600 seconds by default). Both the confirming commit a= nd a follow-up unconfirmed <commit> operation MAY introduce additiona= l changes to the configuration. If the <persist> element is not given= in the unconfirmed commit operation, any follow-up commit and the confirmi= ng commit MUST be issued on the same session that issued the unconfirmed co= mmit. If the <persist> element is given in the unconfirmed <commit= > operation, a follow-up commit and the confirming commit can be given o= n any session, and they MUST include a <persist-id> element with a va= lue equal to the given value of the <persist> element. If the server = also advertises the :startup capability, a <copy-config> from running= to startup is also necessary to save the changes to startup. If the sessio= n issuing a sequence of one or more unconfirmed commits is terminated for a= ny reason before the confirm timeout expires, the server MUST restore the c= onfiguration to its state before the sequence of unconfirmed commits was is= sued, unless the last unconfirmed commit also included a <persist> el= ement. If the device reboots for any reason before the confirm timeout expi= res, the server MUST restore the configuration to its state before the sequ= ence of unconfirmed commits was issued. If a confirming commit is not issue= d, the device will revert its configuration to the state prior to the issua= nce of the first in the current sequence of unconfirmed commits. To cancel = the current sequence of unconfirmed commits and revert changes without wait= ing for the confirm timeout to expire, the client can explicitly restore th= e configuration to its state before the sequence of unconfirmed commits was= issued, by using the <cancel-commit> operation. : 8.4.4.1. <cance= l-commit> Description: Cancels an ongoing sequence of unconfirmed commit= s. If the <persist-id> parameter is not given, the <cancel-commit&= gt; operation MUST be issued on the same session that issued the sequence o= f unconfirmed commits. Parameters: persist-id: Cancels a persistent sequenc= e of unconfirmed commits. The value MUST be equal to the value given in the= <persist> parameter to the <commit> operation. If the value do= es not match, the operation fails with an "invalid-value" error. : 8.4.5.1= =2E <commit> The :confirmed-commit:1.1 capability allows 4 additional= parameters to the <commit> operation. Parameters: confirmed: Perform= an unconfirmed <commit> operation. confirm-timeout: Timeout period f= or confirmed commit, in seconds. If unspecified, the confirm timeout defaul= ts to 600 seconds. persist: Make the unconfirmed commit survive a session t= ermination, and set a token on the ongoing sequence of unconfirmed commits= =2E persist-id: Used to issue a follow-up unconfirmed commit or a confirmin= g commit from any session, with the token from the previous <commit> = operation. On 2013-09-20 11:08, Bert Wijnen (IETF) wrote:THat is one (and p= robably good) approach.
So can the
authors/experts suggest some text that makes
sense as a fix (or better clarification) to a possible
erratum? Bert On 9/20/13 10:00 AM, Jonathan Hansford wrote:
Would it be worth agreeing text
online then raising an erratum? Sent from my BlackBerry -----Original Messa= ge----- From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net [1]> Date: Fri, 20 Sep 2013 08:41:42 To= : Andy Bierman<andy@yumaworks.com<= /a> [2]>; Jonathan Hansford<Jonathan@hansfords.net [3]>; Netconf<netconf@ietf.org[4]> Subject: Re: [Netconf] Confirmed commi= t See at bottom On 9/20/13 7:13 AM, Juergen Schoenwaelder wrote:
On Thu, Sep 19, 2013 at
01:39:28PM -0700, Andy Bierman wrote:
Hi, I always found
section 8.4.1, para 2 confusing. T0: /int8.1 does not existmerge /int8.1 va= lue=3D20 commit confirmed confirm-timeout=3D60
T1:
/int8.1 =3D 20 merge /int8.1 value=3D30 commit confirmed confirm-timeout=3D= 60 T2: /int8.1 =3D 30 T3: timeout occurs: para 6 says: If a confirming comm= it is not issued, the device will revert its configuration to the state pri= or to the issuance of the confirmed commit. The problem is that there are 2= confirmed commit operations. At time T3 does the server go back to state T= 1 or T0? (Our server goes back to T0). The 2nd commit contains a confirmed = parameter, and para 2 sentence 2 clearly says this is not a confirming comm= it. The text does not actually define a "confirmed commit", but I assume it= is a commit with a confirmed parameter. Therefore, paragraphs 5 - 7 are wr= ong where they refer to "the confirmed commit", because there are 2 of them= =2E
Yes, this corner case where
multiple confirmed commits are issued is not described well. Your interpret= ation that subsequent confirmed commits effectively extend the first one ma= kes sense to me.
Can wee keep this somewhere so we
clarify it if we ever have to open up and update the document? Bert
/js
Links: ------ [1] mailto:bertietf@b= wijnen.net [2] mailto:andy@yumawo= rks.com [3] mailto:Jonathan@h= ansfords.net [4] mailto:netconf@iet= f.org
--=_404faad83dccbb8ce4012f39b0cd2982-- From andy@yumaworks.com Fri Sep 20 08:46:17 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5163321F99BD for ; Fri, 20 Sep 2013 08:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzB1ssCOWOcn for ; Fri, 20 Sep 2013 08:46:13 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id B124421F99E8 for ; Fri, 20 Sep 2013 08:46:12 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id b4so384746qen.34 for ; Fri, 20 Sep 2013 08:46:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M5k7ifK34LsrPvTM9uFZghpxHvJMpwChm/f7wNxSoYQ=; b=ZFpBhVVn6UStZ/oS+Xpbb2secR/lKrWSOLyHw3yv8HAl5djLGtVjAyJcgwgYdFeLJX bEcoDJgrhqIIVBsTAMcBUqrKxfSuKZ13QeLKpdumKGEWrBZ76HTuI+L1Icvgh3pwXJft 9BIiOSyo3+JZi3q6rQOwmIe+UUuqmy+75j+rDsfJ9Q+R9e1FvGAWm/VtyIZLErVATj5r 2aYph5vLcEw17hiCVC5gMXyPgexBD1FEC/18QjBI8JD5DOpTJZHgyMGcDen8G3N7kkKz qTBEwgya0XTU2IqRA6GT69131SMbB8OHVr0fTS2r/NANFHy+pPKQ8r2mZVee6nO+xVMJ 3t5Q== X-Gm-Message-State: ALoCoQmrIg1XoPmqYE6IRSP1pMX3ZbPg4BrFM5lg7Ews9RJSqwS41m6zSLEU2cm3/DrB53c5Vcg5 MIME-Version: 1.0 X-Received: by 10.49.120.72 with SMTP id la8mr5371729qeb.62.1379691971979; Fri, 20 Sep 2013 08:46:11 -0700 (PDT) Received: by 10.140.26.209 with HTTP; Fri, 20 Sep 2013 08:46:11 -0700 (PDT) In-Reply-To: References: <20130920.125718.2241274183066609324.mbj@tail-f.com> <523C3856.9040304@bwijnen.net> Date: Fri, 20 Sep 2013 08:46:11 -0700 Message-ID: From: Andy Bierman To: Jonathan Hansford Content-Type: multipart/alternative; boundary=047d7b6d8996e3ece204e6d291b4 Cc: Netconf Subject: Re: [Netconf] Confirmed commit X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 15:46:17 -0000 --047d7b6d8996e3ece204e6d291b4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I do not think the term "confirmed commit" is confusing. The use of the term "the" is confusing. The section also does not make it clear just how dangerous confirmed-commit is to use without holding locks for the entire procedure. It does not make it extra clear that using the "persist" parameter will at least cause all commits by other users to fail (because they won't know the persist-id to use). This at least prevents other users from providing the confirming commit or extending the current confirmed commit. It does not prevent them from adding edits to candidate so that when the real confirming commit arrives (with the correct persist-id) these extra edits will be added to the running config. Andy On Fri, Sep 20, 2013 at 5:50 AM, Jonathan Hansford wrote: > ** > > In order to address the terminology issue without changing the > terminology, how about changing the first paragraph of 8.4.1 to: > > The :confirmed-commit:1.1 capability indicates that the server will > support the operation, the , = , > , and parameters for the operation, and > differentiate between a =93to be confirmed=94 operation (a =93co= nfirmed > commit=94) and a confirming operation. See Section 8.3 for furth= er > details on the operation. > > Jonathan > > On 2013-09-20 12:58, Bert Wijnen (IETF) wrote: > > Speaking as a technical contributor. > > I also think we should stick to the terminology we have been using for > many years now. So I was thinking more about some clarifying or explanato= ry > text instead of renaming our terminology. > > Bert > > On 9/20/13 12:57 PM, Martin Bjorklund wrote: > > Hi, I don't think we should change the terminology in an errata. (and > actually I don't think we should change it at all - I agree there might b= e > a better term, but the term "confirmed commit" has been used for several > years and people are used to it) Your text about sequence of commits is > fine; but I think we should stick to the current terminology. /martin > Jonathan Hansford wrote: > > I propose the following changes to address Andy's issue relating to > consecutive confirmed commits and my issue relating to the confusing > terminology: 8.4.1. Description (paras 2-6) A operation with the > parameter (an unconfirmed ) MUST be reverted if a > confirming commit is not issued within the timeout period (by default 600 > seconds =3D 10 minutes). The confirming commit is a operation > without the parameter and, if successful, cannot be reverted. > The timeout period can be adjusted with the parameter. = If > a follow-up unconfirmed operation is issued before the timer > expires, the timer is reset to the new value (600 seconds by default). Bo= th > the confirming commit and a follow-up unconfirmed operation MAY > introduce additional changes to the configuration. If the eleme= nt > is not given in the unconfirmed commit operation, any follow-up commit an= d > the confirming commit MUST be issued on the same session that issued the > unconfirmed commit. If the element is given in the unconfirmed > operation, a follow-up commit and the confirming commit can be > given on any session, and they MUST include a element with a > value equal to the given value of the element. If the server al= so > advertises the :startup capability, a from running to start= up > is also necessary to save the changes to startup. If the session issuing = a > sequence of one or more unconfirmed commits is terminated for any reason > before the confirm timeout expires, the server MUST restore the > configuration to its state before the sequence of unconfirmed commits was > issued, unless the last unconfirmed commit also included a > element. If the device reboots for any reason before the confirm timeout > expires, the server MUST restore the configuration to its state before th= e > sequence of unconfirmed commits was issued. If a confirming commit is not > issued, the device will revert its configuration to the state prior to th= e > issuance of the first in the current sequence of unconfirmed commits. To > cancel the current sequence of unconfirmed commits and revert changes > without waiting for the confirm timeout to expire, the client can > explicitly restore the configuration to its state before the sequence of > unconfirmed commits was issued, by using the operation. : > 8.4.4.1. Description: Cancels an ongoing sequence of > unconfirmed commits. If the parameter is not given, the > operation MUST be issued on the same session that issued > the sequence of unconfirmed commits. Parameters: persist-id: Cancels a > persistent sequence of unconfirmed commits. The value MUST be equal to th= e > value given in the parameter to the operation. If the > value does not match, the operation fails with an "invalid-value" error. = : > 8.4.5.1. The :confirmed-commit:1.1 capability allows 4 additiona= l > parameters to the operation. Parameters: confirmed: Perform an > unconfirmed operation. confirm-timeout: Timeout period for > confirmed commit, in seconds. If unspecified, the confirm timeout default= s > to 600 seconds. persist: Make the unconfirmed commit survive a session > termination, and set a token on the ongoing sequence of unconfirmed > commits. persist-id: Used to issue a follow-up unconfirmed commit or a > confirming commit from any session, with the token from the previous > operation. On 2013-09-20 11:08, Bert Wijnen (IETF) wrote:THat is > one (and probably good) approach. > > So can the > > authors/experts suggest some text that makes > > sense as a fix (or better > > clarification) to a possible > > erratum? Bert On 9/20/13 10:00 > > AM, Jonathan Hansford wrote: > > Would it be worth agreeing text > > online then raising an erratum? Sent from my BlackBerry -----Original > Message----- From: "Bert Wijnen (IETF)" Date: > Fri, 20 Sep 2013 08:41:42 To: Andy Bierman; > Jonathan Hansford; Netconf > Subject: Re: [Netconf] Confirmed commit See at bottom On 9/20/13 7:13 AM, > Juergen Schoenwaelder wrote: > > On Thu, Sep 19, 2013 at > > 01:39:28PM -0700, Andy Bierman wrote: > > Hi, I always found > > section 8.4.1, para 2 confusing. T0: /int8.1 does not existmerge > /int8.1 value=3D20 commit confirmed confirm-timeout=3D60 > > T1: > > /int8.1 =3D 20 merge /int8.1 value=3D30 commit confirmed confirm-timeou= t=3D60 > T2: /int8.1 =3D 30 T3: timeout occurs: para 6 says: If a confirming commi= t is > not issued, the device will revert its configuration to the state prior t= o > the issuance of the confirmed commit. The problem is that there are 2 > confirmed commit operations. At time T3 does the server go back to state = T1 > or T0? (Our server goes back to T0). The 2nd commit contains a confirmed > parameter, and para 2 sentence 2 clearly says this is not a confirming > commit. The text does not actually define a "confirmed commit", but I > assume it is a commit with a confirmed parameter. Therefore, paragraphs 5= - > 7 are wrong where they refer to "the confirmed commit", because there are= 2 > of them. > > Yes, this corner case where > > multiple confirmed commits are issued is not described well. Your > interpretation that subsequent confirmed commits effectively extend the > first one makes sense to me. > > Can wee keep this somewhere so we > > clarify it if we ever have to open up and update the document? Bert > > /js > > Links: ------ [1] mailto:bertietf@bwijnen.net [2] mailto: > andy@yumaworks.com [3] mailto:Jonathan@hansfords.net [4] mailto: > netconf@ietf.org > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --047d7b6d8996e3ece204e6d291b4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,

I do not think the term "confi= rmed commit" is confusing.
The use of the term "the&quo= t; is confusing.

The section also does not make it= clear just how dangerous confirmed-commit
is to use without holding locks for the entire procedure. It does not = make
it extra clear that using the "persist" parameter = will at least cause all commits
by other users to fail (because t= hey won't know the persist-id to use).

This at least prevents other users from providing the c= onfirming commit
or extending the current confirmed commit. =A0It= does not prevent them from
adding edits to candidate so that whe= n the real confirming commit arrives
(with the correct persist-id) these extra edits will be added to the r= unning config.


Andy=


On Fri,= Sep 20, 2013 at 5:50 AM, Jonathan Hansford <Jonathan@hansfords.net= > wrote:

In order to address the terminology issue without changing the terminolo= gy, how about changing the first paragraph of 8.4.1 to:

The :confirmed-commit:1.1 capability indicates that the server will supp= ort the <cancel-commit> operation, the <confirmed>, <confirm= -timeout>, <persist>, and <persist-id> parameters for the &l= t;commit> operation, and differentiate between a =93to be confirmed=94 &= lt;commit> operation (a =93confirmed commit=94) and a confirming <com= mit> operation. See Section 8.3 for further details on the <commit>= ; operation.

Jonathan

On 2013-09-20 12:58, Bert Wijnen (IETF) wrote:

Speaking as a technical contributor.

I also think we should stick to the terminology we have been using for
many years now. So I was thinking more about some clarifying or explanatory
text instead of renaming our terminology.

Bert

On 9/20/13 12:57 PM, Martin Bjorklund wrote:
Hi, I don't think we should change t= he terminology in an errata. (and actually I don't think we should chan= ge it at all - I agree there might be a better term, but the term "con= firmed commit" has been used for several years and people are used to = it) Your text about sequence of commits is fine; but I think we should stic= k to the current terminology. /martin Jonathan Hansford <Jonathan@hansfords.net>= wrote:
I propose the following changes to addre= ss Andy's issue relating to consecutive confirmed commits and my issue = relating to the confusing terminology: 8.4.1. Description (paras 2-6) A <= ;commit> operation with the <confirmed> parameter (an unconfirmed = <commit>) MUST be reverted if a confirming commit is not issued withi= n the timeout period (by default 600 seconds =3D 10 minutes). The confirmin= g commit is a <commit> operation without the <confirmed> parame= ter and, if successful, cannot be reverted. The timeout period can be adjus= ted with the <confirm-timeout> parameter. If a follow-up unconfirmed = <commit> operation is issued before the timer expires, the timer is r= eset to the new value (600 seconds by default). Both the confirming commit = and a follow-up unconfirmed <commit> operation MAY introduce addition= al changes to the configuration. If the <persist> element is not give= n in the unconfirmed commit operation, any follow-up commit and the confirm= ing commit MUST be issued on the same session that issued the unconfirmed c= ommit. If the <persist> element is given in the unconfirmed <commi= t> operation, a follow-up commit and the confirming commit can be given = on any session, and they MUST include a <persist-id> element with a v= alue equal to the given value of the <persist> element. If the server= also advertises the :startup capability, a <copy-config> from runnin= g to startup is also necessary to save the changes to startup. If the sessi= on issuing a sequence of one or more unconfirmed commits is terminated for = any reason before the confirm timeout expires, the server MUST restore the = configuration to its state before the sequence of unconfirmed commits was i= ssued, unless the last unconfirmed commit also included a <persist> e= lement. If the device reboots for any reason before the confirm timeout exp= ires, the server MUST restore the configuration to its state before the seq= uence of unconfirmed commits was issued. If a confirming commit is not issu= ed, the device will revert its configuration to the state prior to the issu= ance of the first in the current sequence of unconfirmed commits. To cancel= the current sequence of unconfirmed commits and revert changes without wai= ting for the confirm timeout to expire, the client can explicitly restore t= he configuration to its state before the sequence of unconfirmed commits wa= s issued, by using the <cancel-commit> operation. : 8.4.4.1. <canc= el-commit> Description: Cancels an ongoing sequence of unconfirmed commi= ts. If the <persist-id> parameter is not given, the <cancel-commit= > operation MUST be issued on the same session that issued the sequence = of unconfirmed commits. Parameters: persist-id: Cancels a persistent sequen= ce of unconfirmed commits. The value MUST be equal to the value given in th= e <persist> parameter to the <commit> operation. If the value d= oes not match, the operation fails with an "invalid-value" error.= : 8.4.5.1. <commit> The :confirmed-commit:1.1 capability allows 4 ad= ditional parameters to the <commit> operation. Parameters: confirmed:= Perform an unconfirmed <commit> operation. confirm-timeout: Timeout = period for confirmed commit, in seconds. If unspecified, the confirm timeou= t defaults to 600 seconds. persist: Make the unconfirmed commit survive a s= ession termination, and set a token on the ongoing sequence of unconfirmed = commits. persist-id: Used to issue a follow-up unconfirmed commit or a conf= irming commit from any session, with the token from the previous <commit= > operation. On 2013-09-20 11:08, Bert Wijnen (IETF) wrote:THat is one (= and probably good) approach.
So can the
authors/experts suggest some text that makes
sense as a fix (or better
clarification) to a possible
erratum? Bert On 9/20/13 10:00 AM, Jonathan Hansford wrote:
Would it be worth agreeing text
online then raising an erratum? Sent from my BlackBerry -----Original Messa= ge----- From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net [1]> Date: Fri,= 20 Sep 2013 08:41:42 To: Andy Bierman<andy@yumaworks.com [2]>; Jonathan Hansford<= ;Jonathan@hansf= ords.net [3]>; Netconf<netconf@ietf.org[4]> Subject: Re: [Netconf] Confirmed co= mmit See at bottom On 9/20/13 7:13 AM, Juergen Schoenwaelder wrote:
On Thu, Sep 19, 2013 at
01:39:28PM -0700, Andy Bierman wrote:
Hi, I always found
section 8.4.1, para 2 confusing. T0: /int8.1 does not existmerge /int8.1 va= lue=3D20 commit confirmed confirm-timeout=3D60
T1:
/int8.1 =3D 20 merge /int8.1 value=3D30 commit confirmed confirm-timeout=3D= 60 T2: /int8.1 =3D 30 T3: timeout occurs: para 6 says: If a confirming comm= it is not issued, the device will revert its configuration to the state pri= or to the issuance of the confirmed commit. The problem is that there are 2= confirmed commit operations. At time T3 does the server go back to state T= 1 or T0? (Our server goes back to T0). The 2nd commit contains a confirmed = parameter, and para 2 sentence 2 clearly says this is not a confirming comm= it. The text does not actually define a "confirmed commit", but I= assume it is a commit with a confirmed parameter. Therefore, paragraphs 5 = - 7 are wrong where they refer to "the confirmed commit", because= there are 2 of them.
Yes, this corner case where
multiple confirmed commits are issued is not described well. Your interpret= ation that subsequent confirmed commits effectively extend the first one ma= kes sense to me.
Can wee keep this somewhere so we
clarify it if we ever have to open up and update the document? Bert
/js
Links: ------ [1] mailto:bertietf@bwijnen.net [2] mailto:andy@yumaworks.com [3] mailto:Jonathan@hansfords.net [4] = mailto:netconf@ietf.o= rg

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


--047d7b6d8996e3ece204e6d291b4-- From andy@yumaworks.com Sun Sep 29 16:56:40 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8598A21F9E95 for ; Sun, 29 Sep 2013 16:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6R0CebTdL0u for ; Sun, 29 Sep 2013 16:56:30 -0700 (PDT) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id ADC0721F9EC4 for ; Sun, 29 Sep 2013 16:56:30 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id 1so3291510qec.15 for ; Sun, 29 Sep 2013 16:56:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=h04kp+T3jMdFmNq7nDan1F6k1TEokpofgCMczdIP1Ag=; b=CiiEOwxY1ciZ23FS+QCBudura0uqiT0kzVbSyxa/pqkwioTQimKCY7DvpGlKLlIOuL SrjtxYxMgT6S1a+7gCkebFdv0S4X2N9ECBRKFDAo6HGtHdHxXV64bJnYmonG6qxVu67a TKQUINmvy0MDkbVlYZv6F3GMxXxy/5Vanxw6bjlE2RZii17FvR8Hw77LPd0itQXseioG 9KWt+0K+Y0wX1X/amTJxTmyKz4AbbajIZIPHTPKazFw8hOk+WJg+Qvs8Qqi8JXMCYJf/ Ydi4AjJ+p8+6rdcEKep2/EofIevAUlSWULTtUtKJo+l1KLi4ITSl/UwV/GcPH+R73GU9 cAkw== X-Gm-Message-State: ALoCoQk61xMfhGpRjHdFoHBSbg2722hstXHdXuwHfrxk3TyNxB+G94ZsPe2ZJwr3ZGpAZazgdHzv MIME-Version: 1.0 X-Received: by 10.224.130.129 with SMTP id t1mr10516551qas.35.1380498988002; Sun, 29 Sep 2013 16:56:28 -0700 (PDT) Received: by 10.140.26.209 with HTTP; Sun, 29 Sep 2013 16:56:27 -0700 (PDT) Date: Sun, 29 Sep 2013 16:56:27 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a1132ecf2cafbeb04e78e77bd Subject: [Netconf] source-host leaf in ietf-netconf-notifications.yang X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 23:56:40 -0000 --001a1132ecf2cafbeb04e78e77bd Content-Type: text/plain; charset=ISO-8859-1 Hi, Is there some reason we made the source-host leaf in RFC 6470 an inet:ip-address type instead of a inet:host type? The netconf-session-start notification code is failing to add the source-addr leaf if it is a valid domain name. Since sessions in the netconf-state module are type inet:host it seems the notification type is a bug. Andy --001a1132ecf2cafbeb04e78e77bd Content-Type: text/html; charset=ISO-8859-1
Hi,

Is there some reason we made the source-host leaf in RFC 6470
an inet:ip-address type instead of a inet:host type?

The netconf-session-start notification code is failing
to add the source-addr leaf if it is a valid domain name.
Since sessions in the netconf-state module are type inet:host
it seems the notification type is a bug.



Andy
--001a1132ecf2cafbeb04e78e77bd--