htt= p://tools.ietf.org/wg/netconf/agenda?item=3Dagenda77.html

A very handy link is also this one:

http://tools.ie= tf.org/agenda/77/#2010-03-20_0930

It has various other links to the jkabber room, = materials=20 etc.

You can start RIGHT NOW of course by READING the = CURRENT=20 DRAFTS that

are ON our AGENDA for coming = Monday:

- http://= tools.ietf.org/html/draft-ietf-netconf-4741bis-02

- h= ttp://tools.ietf.org/html/draft-ietf-netconf-with-defaults-05<= /DIV>

- http= ://tools.ietf.org/html/draft-ietf-netconf-rfc4742bis-00

- h= ttp://tools.ietf.org/html/draft-cole-netconf-robust-config-02<= /DIV>

- http://tools.ietf.org/html/draft-bierman-netconf-access-control-01=

PLEASE COME PREPARED!

Bert and Mehmet

Netconf WG co-chairs

------=_NextPart_000_0EFE_01CAC5CD.B67E52A0-- From bertietf@bwijnen.net Wed Mar 17 04:36:37 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13EE3A6965 for ; Wed, 17 Mar 2010 04:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.055 X-Spam-Level: * X-Spam-Status: No, score=1.055 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8Ws1TgITy06 for ; Wed, 17 Mar 2010 04:36:36 -0700 (PDT) Received: from relay.versatel.net (relay56.tele2.vuurwerk.nl [62.250.3.56]) by core3.amsl.com (Postfix) with ESMTP id 038193A6961 for ; Wed, 17 Mar 2010 04:36:35 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1NrrYL-0005H6-91; Wed, 17 Mar 2010 12:36:45 +0100 Message-ID: <44FBD36A521446AD8BE8FBEADE574ADC@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Martin Bjorklund" References: <4B46EC66.3010908@bwijnen.net> <20100315.155908.145834344.mbj@tail-f.com> In-Reply-To: <20100315.155908.145834344.mbj@tail-f.com> Date: Wed, 17 Mar 2010 12:35:22 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0F30_01CAC5CE.50096BD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 Cc: Netconf Subject: Re: [Netconf] [Fwd: I-D Action:draft-ietf-netconf-rfc4742bis-00.txt] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 11:36:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0F30_01CAC5CE.50096BD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Off course! thanks Martin. Margaret, pls note and answer Bert ----- Original Message -----=20 From: Martin Bjorklund=20 To: bertietf@bwijnen.net=20 Cc: netconf@ietf.org=20 Sent: Monday, March 15, 2010 3:59 PM Subject: Re: [Netconf] [Fwd: I-D = Action:draft-ietf-netconf-rfc4742bis-00.txt] Hi, "Bert (IETF) Wijnen" wrote: > pls review and comment on this initial version. Sooner is better = than later. ... but later is hopefully better than never :) Here are some comments: rfcdiff shows some typos compared with 4742: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc4742bis-00.txt= Section 1 introduces the terms "client / server" and "manager / agent" and makes a distinction between them. These terms are not consistent with how they are used in 4741. Also, in the document, the term "user" and "application" is also used instead of "manager". Would it be simpler to use only the terms "client" and "server" throughout the doc? s/RPC message/RPC operation/ s/command/operation/ Section 4 specifies that the clients sends elements and the server sends elements. It should also mention elements. Clarification in Section 5: OLD: The agent MUST NOT process any RPC commands received on the current session after the command. NEW: The agent MUST NOT process any RPC operations received on the = current NETCONF session after the command. /martin -------------------------------------------------------------------------= ----- Geen virus gevonden in het binnenkomende-bericht. Gecontroleerd door AVG - www.avg.com=20 Versie: 9.0.790 / Virusdatabase: 271.1.1/2748 - datum van uitgifte: = 03/15/10 08:33:00 ------=_NextPart_000_0F30_01CAC5CE.50096BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Off course! thanks Martin.

Margaret, pls note and answer

Bert

----- Original Message -----

From:=20 Martin = Bjorklund=20

To: bertietf@bwijnen.net

Cc: netconf@ietf.org

Sent: Monday, March 15, 2010 = 3:59=20 PM

Subject: Re: [Netconf] [Fwd: = I-D=20 Action:draft-ietf-netconf-rfc4742bis-00.txt]

Hi,

"Bert (IETF) Wijnen" <bertietf@bwijnen.net> = wrote:
>=20 pls review and comment on this initial version. Sooner is better than=20 later.

... but later is hopefully better than never = :)

Here are=20 some comments:

rfcdiff shows some typos compared with = 4742:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc4742= bis-00.txt

Section=20 1 introduces the terms "client / server" and "manager / agent"
and = makes a=20 distinction between them. These terms are not consistent
with = how=20 they are used in 4741. Also, in the document, the term
"user" = and=20 "application" is also used instead of "manager".   Would = it
be=20 simpler to use only the terms "client" and "server" throughout=20 the
doc?

s/RPC message/RPC=20 operation/
s/command/operation/

Section 4 specifies that = the=20 clients sends <rpc> elements and the
server sends = <rpc-reply>=20 elements. It should also mention
<notification>=20 elements.

Clarification in Section=20 5:

OLD:
   The agent MUST NOT process any RPC = commands=20 received on the current
   session after the=20 <close-session> command.

NEW:
   The agent = MUST NOT=20 process any RPC operations received on the current
   = NETCONF=20 session after the <close-session>=20 command.

/martin

Geen virus gevonden in het = binnenkomende-bericht.
Gecontroleerd=20 door AVG - www.avg.com
Versie: = 9.0.790 /=20 Virusdatabase: 271.1.1/2748 - datum van uitgifte: 03/15/10=20 08:33:00
------=_NextPart_000_0F30_01CAC5CE.50096BD0-- From johan.rydberg@edgeware.tv Wed Mar 17 04:46:15 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA153A68E5 for ; Wed, 17 Mar 2010 04:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vB4vWDGesnzK for ; Wed, 17 Mar 2010 04:46:14 -0700 (PDT) Received: from mail.edgeware.tv (mail.edgeware.tv [94.127.35.114]) by core3.amsl.com (Postfix) with ESMTP id 68A153A68CC for ; Wed, 17 Mar 2010 04:46:13 -0700 (PDT) Received: from Edgewares-Mac-mini.local (unknown [94.127.35.115]) by mail.edgeware.tv (Postfix) with ESMTPA id 4E0641910099 for ; Wed, 17 Mar 2010 12:46:22 +0100 (CET) Message-ID: <4BA0C10D.4030700@edgeware.tv> Date: Wed, 17 Mar 2010 12:46:21 +0100 From: Johan Rydberg User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: netconf@ietf.org References: <4B1ECEC7.5080604@netconfcentral.com> <20100316.222442.159618448.mbj@tail-f.com> In-Reply-To: <20100316.222442.159618448.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 11:46:15 -0000 > I propose a new capability, :confirmed-commit:1.1 to solve 2 and 4 Why not make confirmation of a commit a first class operation? The semantics that a commit confirms another commit can be confusing to some people (including me). From phil@juniper.net Wed Mar 17 05:03:37 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4F3D3A6A27 for ; Wed, 17 Mar 2010 05:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.978 X-Spam-Level: X-Spam-Status: No, score=-5.978 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2U6Zk50tsFa for ; Wed, 17 Mar 2010 05:03:36 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 16C4D3A6931 for ; Wed, 17 Mar 2010 05:03:35 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKS6DFHhNedM96/d+S2W4Tre0V0Mz72aAw@postini.com; Wed, 17 Mar 2010 05:03:46 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.393.1; Wed, 17 Mar 2010 05:00:20 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 05:00:20 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 05:00:20 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 05:00:20 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o2HC0JD33329; Wed, 17 Mar 2010 05:00:19 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o2HBi02G030180; Wed, 17 Mar 2010 11:44:00 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201003171144.o2HBi02G030180@idle.juniper.net> To: In-Reply-To: <4B9FFBD3.2040603@iwl.com> Date: Wed, 17 Mar 2010 07:44:00 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 Mar 2010 12:00:20.0107 (UTC) FILETIME=[6A9A35B0:01CAC5C9] MIME-Version: 1.0 Content-Type: text/plain Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 12:03:37 -0000 Andy Bierman writes: >It is clear -- the confirmed commit is rolled back >if the session that started it is terminated. I would like to see this declared as a bug in the spec: If the session issuing the confirmed commit is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued. I dislike this because it means that changes that affect the session's path to the device are not possible. I can't commit confirmed, discard my now useless session, open a new one, see that all is good, and issue a confirming commit. I see this as useful functionality is it's how the commit confirmed originally worked in JUNOS. >> But there is no way to "explicitly restore" the configuration. >close-session That's not explicit. Explicit means you reload or rollback the config by hand (from a saved copy). Thanks, Phil From mbj@tail-f.com Wed Mar 17 05:22:05 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39F23A6A39 for ; Wed, 17 Mar 2010 05:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp5GNGYiGUl9 for ; Wed, 17 Mar 2010 05:22:01 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4E2453A6A37 for ; Wed, 17 Mar 2010 05:21:58 -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 CE970616009; Wed, 17 Mar 2010 13:22:07 +0100 (CET) Date: Wed, 17 Mar 2010 13:22:07 +0100 (CET) Message-Id: <20100317.132207.131010805.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4B9FFBD3.2040603@iwl.com> References: <4B1ECEC7.5080604@netconfcentral.com> <20100316.222442.159618448.mbj@tail-f.com> <4B9FFBD3.2040603@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 12:22:05 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Hi, > > > > Andy Bierman wrote: > >> Hi, > >> > >> First there was the Robust Configuration draft, which proposed > >> a verified-commit procedure. Then there was some consensus > >> towards decoupling the verify and commit procedures. Then there > >> was a suggestion to improve the commit procedure with a new > >> capability. Old clients would still work because there would > >> be 1 or more new parameters that must be present to select the > >> new behavior. The new confirmed-commit-1.1 > >> capability would add a parameter to the > >> operation. > >> > >> There are no proposed edits at this time. > >> The WG needs to decide on a basic solution approach first: > >> > >> A) add a new capability which changes the commit procedure > >> to allow the original server to terminate without > >> canceling the confirmed commit; detailed proposal > >> from Martin is still needed, and WG consensus on > >> all the details is needed > > > > I think there are 4 problems with the :confirmed-commit:1.0 > > capability. > > > > 1. It is not clear if the confirming commit MUST be sent on the > > same session which sent the confirmed commit. > > > > Since the confirmed commit is aborted if the original session is > > terminated, it seems to make sense that the confirming commit > > MUST be sent on the original session. Also, allowing the > > confirming commit to be sent on other sessions opens up > > interesting access control questions. > > > > FWIW, I know two different implementations that has interpreted > > the text this way. > > > > It is clear -- the confirmed commit is rolled back > if the session that started it is terminated. *That* is clear, I agree. But that's not what I wrote. The question is if the confirming commit can be sent over a different session. > > 2. The text says: > > > > Thus to cancel a confirmed commit and revert changes without > > waiting for the confirm timeout to expire, the client can > > explicitly restore the configuration to its state before the > > confirmed commit was issued. > > > > But there is no way to "explicitly restore" the configuration. > > > > close-session If this is what the text really refers to, the text should mention it, and not call it explicit: Thus to cancel a confirmed commit and revert changes without waiting for the confirm timeout to expire, the client can restore the configuration to its state before the confirmed commit was issued by closing the session. But I don't think close-session is what the original text refered to... > > 3. If another client takes a lock when the confirming commit is > > pending, it will be surprised if the config changes due to a > > rollback. > > > > Proposal: do not allow lock when a confirming-commit is pending. > > > > This seems fine, along with many other small changes, > except the WG already decided not to change the base capability, > so there is no way for a client to tell an RFC4741 server > from a 4741bis server. An old client is not going > to be looking for a 1.1 confirmed-commit capability, > so anything that worked before (even gray areas like this) > need to be considered compliant. What does this have to do with confirmed-commit:1.1??? This problem (3 in my list), points out a problem with interaction between lock and confirmed commit. Do you agree that if a session has a lock, the db MUST NOT change? /martin From calle@tail-f.com Wed Mar 17 05:26:46 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACB273A67FD; Wed, 17 Mar 2010 05:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgXlugdxQpB4; Wed, 17 Mar 2010 05:26:46 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 710D53A659A; Wed, 17 Mar 2010 05:26:46 -0700 (PDT) Received: from [192.168.1.143] (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 11A42616009; Wed, 17 Mar 2010 13:26:56 +0100 (CET) Message-ID: <4BA0CA8F.3010805@tail-f.com> Date: Wed, 17 Mar 2010 13:26:55 +0100 From: Carl Moberg User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0 MIME-Version: 1.0 To: NETCONF WG , NETMOD WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Netconf] Invitation to NETCONF and YANG discussions, Sunday @ IETF 77 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 12:26:46 -0000 This is an open invitation for sharing and discussing implementation and operational experiences of NETCONF and YANG on Sunday, March 21 2010 from 12:00noon to 3:00pm in the Carmel room at the Anaheim Hilton. We are particularily looking for input to the following open questions: - Any experience from implementing NETCONF and YANG? - What can be expected from NETCONF and YANG implementations? - Any operational pros and cons of NETCONF and YANG? - What can be done to make NETCONF and YANG more useful in operator environments? - Any additional ideas or thoughts on where NETCONF and YANG could be applicable to address configuration management issues? Refreshments will be available. Regards, -- Carl Moberg mailto:calle@tail-f.com http://www.tail-f.com From andyb@iwl.com Wed Mar 17 05:27:01 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 400163A659A for ; Wed, 17 Mar 2010 05:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7zL7JimSrpw for ; Wed, 17 Mar 2010 05:27:00 -0700 (PDT) Received: from smtp174.dfw.emailsrvr.com (smtp174.dfw.emailsrvr.com [67.192.241.174]) by core3.amsl.com (Postfix) with ESMTP id 74B3A3A67FD for ; Wed, 17 Mar 2010 05:27:00 -0700 (PDT) Received: from relay7.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay7.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 54D84CE6932; Wed, 17 Mar 2010 08:27:10 -0400 (EDT) Received: by relay7.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 17D55CE6857; Wed, 17 Mar 2010 08:27:10 -0400 (EDT) Message-ID: <4BA0CA52.9090600@iwl.com> Date: Wed, 17 Mar 2010 05:25:54 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Phil Shafer References: <201003171144.o2HBi02G030180@idle.juniper.net> In-Reply-To: <201003171144.o2HBi02G030180@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 12:27:01 -0000 Phil Shafer wrote: > Andy Bierman writes: >> It is clear -- the confirmed commit is rolled back >> if the session that started it is terminated. > > I would like to see this declared as a bug in the spec: > It was not considered a bug when it was written. The WG was quite aware how confirmed-commit. The text clearly says that if the session that starts the commit is terminated for any reason, the confirmed commit fails and is rolled back. This is not a bug. This is how the standard is defined. > If the session issuing the confirmed commit is terminated for any > reason before the confirm timeout expires, the server MUST restore > the configuration to its state before the confirmed commit was > issued. > > I dislike this because it means that changes that affect the session's > path to the device are not possible. I can't commit confirmed, > discard my now useless session, open a new one, see that all is > good, and issue a confirming commit. I see this as useful > functionality is it's how the commit confirmed originally worked > in JUNOS. This should have been addressed when the RFC was being written. I object to any changes to 4741 that cause an old server or old client (compliant to RFC 4741) to be considered a bug in the new version. Adding a new capability as Marting suggests will break existing clients and servers, so it is a non-starter. We can obsolete 4741 and start over with 1.1 -- that is an acceptable migration path. > >>> But there is no way to "explicitly restore" the configuration. >> close-session > > That's not explicit. Explicit means you reload or rollback the > config by hand (from a saved copy). Explicit just means by client command; this was the choice of the WG at the time. The addition of more commands was discussed and rejected. > > Thanks, > Phil > Andy From andyb@iwl.com Wed Mar 17 05:30:47 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A61D3A6A29 for ; Wed, 17 Mar 2010 05:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx0AFi-6f0p9 for ; Wed, 17 Mar 2010 05:30:46 -0700 (PDT) Received: from smtp194.iad.emailsrvr.com (smtp194.iad.emailsrvr.com [207.97.245.194]) by core3.amsl.com (Postfix) with ESMTP id 8E8603A659A for ; Wed, 17 Mar 2010 05:30:46 -0700 (PDT) Received: from relay19.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay19.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 2BEC41B5519; Wed, 17 Mar 2010 08:30:56 -0400 (EDT) Received: by relay19.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id C53051B402A; Wed, 17 Mar 2010 08:30:55 -0400 (EDT) Message-ID: <4BA0CB34.4000502@iwl.com> Date: Wed, 17 Mar 2010 05:29:40 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B1ECEC7.5080604@netconfcentral.com> <20100316.222442.159618448.mbj@tail-f.com> <4B9FFBD3.2040603@iwl.com> <20100317.132207.131010805.mbj@tail-f.com> In-Reply-To: <20100317.132207.131010805.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 12:30:47 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Hi, >>> >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> First there was the Robust Configuration draft, which proposed >>>> a verified-commit procedure. Then there was some consensus >>>> towards decoupling the verify and commit procedures. Then there >>>> was a suggestion to improve the commit procedure with a new >>>> capability. Old clients would still work because there would >>>> be 1 or more new parameters that must be present to select the >>>> new behavior. The new confirmed-commit-1.1 >>>> capability would add a parameter to the >>>> operation. >>>> >>>> There are no proposed edits at this time. >>>> The WG needs to decide on a basic solution approach first: >>>> >>>> A) add a new capability which changes the commit procedure >>>> to allow the original server to terminate without >>>> canceling the confirmed commit; detailed proposal >>>> from Martin is still needed, and WG consensus on >>>> all the details is needed >>> I think there are 4 problems with the :confirmed-commit:1.0 >>> capability. >>> >>> 1. It is not clear if the confirming commit MUST be sent on the >>> same session which sent the confirmed commit. >>> >>> Since the confirmed commit is aborted if the original session is >>> terminated, it seems to make sense that the confirming commit >>> MUST be sent on the original session. Also, allowing the >>> confirming commit to be sent on other sessions opens up >>> interesting access control questions. >>> >>> FWIW, I know two different implementations that has interpreted >>> the text this way. >>> >> It is clear -- the confirmed commit is rolled back >> if the session that started it is terminated. > > *That* is clear, I agree. But that's not what I wrote. The question > is if the confirming commit can be sent over a different session. > >>> 2. The text says: >>> >>> Thus to cancel a confirmed commit and revert changes without >>> waiting for the confirm timeout to expire, the client can >>> explicitly restore the configuration to its state before the >>> confirmed commit was issued. >>> >>> But there is no way to "explicitly restore" the configuration. >>> >> close-session > > If this is what the text really refers to, the text should mention it, > and not call it explicit: > > Thus to cancel a confirmed commit and revert changes without > waiting for the confirm timeout to expire, the client can > restore the configuration to its state before the > confirmed commit was issued by closing the session. > > But I don't think close-session is what the original text refered > to... > >>> 3. If another client takes a lock when the confirming commit is >>> pending, it will be surprised if the config changes due to a >>> rollback. >>> >>> Proposal: do not allow lock when a confirming-commit is pending. >>> >> This seems fine, along with many other small changes, >> except the WG already decided not to change the base capability, >> so there is no way for a client to tell an RFC4741 server >> from a 4741bis server. An old client is not going >> to be looking for a 1.1 confirmed-commit capability, >> so anything that worked before (even gray areas like this) >> need to be considered compliant. > > What does this have to do with confirmed-commit:1.1??? You cannot add 1.1 because it changes the way 1.0 works. An old client doesn't know about 1.1, only 1.0. Advertising 1.1 breaks the 1,0 client. IMO, this is a non-starter. Advertising 1.1 and not 1.0 breaks old clients as well. You cannot declare previously acceptable protocol behavior to now be an error. > > This problem (3 in my list), points out a problem with interaction > between lock and confirmed commit. Do you agree that if a session has > a lock, the db MUST NOT change? > > > > /martin > Andy From mbj@tail-f.com Wed Mar 17 05:45:16 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 729E53A68C8 for ; Wed, 17 Mar 2010 05:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[AWL=0.895, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-ZkbO2-6u3D for ; Wed, 17 Mar 2010 05:45:15 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 527873A682F for ; Wed, 17 Mar 2010 05:45:15 -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 419EE616009; Wed, 17 Mar 2010 13:45:24 +0100 (CET) Date: Wed, 17 Mar 2010 13:45:24 +0100 (CET) Message-Id: <20100317.134524.09979196.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BA0CB34.4000502@iwl.com> References: <4B9FFBD3.2040603@iwl.com> <20100317.132207.131010805.mbj@tail-f.com> <4BA0CB34.4000502@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 12:45:16 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Hi, > >>> > >>> Andy Bierman wrote: > >>>> Hi, > >>>> > >>>> First there was the Robust Configuration draft, which proposed > >>>> a verified-commit procedure. Then there was some consensus > >>>> towards decoupling the verify and commit procedures. Then there > >>>> was a suggestion to improve the commit procedure with a new > >>>> capability. Old clients would still work because there would > >>>> be 1 or more new parameters that must be present to select the > >>>> new behavior. The new confirmed-commit-1.1 > >>>> capability would add a parameter to the > >>>> operation. > >>>> > >>>> There are no proposed edits at this time. > >>>> The WG needs to decide on a basic solution approach first: > >>>> > >>>> A) add a new capability which changes the commit procedure > >>>> to allow the original server to terminate without > >>>> canceling the confirmed commit; detailed proposal > >>>> from Martin is still needed, and WG consensus on > >>>> all the details is needed > >>> I think there are 4 problems with the :confirmed-commit:1.0 > >>> capability. > >>> > >>> 1. It is not clear if the confirming commit MUST be sent on the > >>> same session which sent the confirmed commit. > >>> > >>> Since the confirmed commit is aborted if the original session is > >>> terminated, it seems to make sense that the confirming commit > >>> MUST be sent on the original session. Also, allowing the > >>> confirming commit to be sent on other sessions opens up > >>> interesting access control questions. > >>> > >>> FWIW, I know two different implementations that has interpreted > >>> the text this way. > >>> > >> It is clear -- the confirmed commit is rolled back > >> if the session that started it is terminated. > > > > *That* is clear, I agree. But that's not what I wrote. The question > > is if the confirming commit can be sent over a different session. > > > >>> 2. The text says: > >>> > >>> Thus to cancel a confirmed commit and revert changes without > >>> waiting for the confirm timeout to expire, the client can > >>> explicitly restore the configuration to its state before the > >>> confirmed commit was issued. > >>> > >>> But there is no way to "explicitly restore" the configuration. > >>> > >> close-session > > > > If this is what the text really refers to, the text should mention it, > > and not call it explicit: > > > > Thus to cancel a confirmed commit and revert changes without > > waiting for the confirm timeout to expire, the client can > > restore the configuration to its state before the > > confirmed commit was issued by closing the session. > > > > But I don't think close-session is what the original text refered > > to... > > > >>> 3. If another client takes a lock when the confirming commit is > >>> pending, it will be surprised if the config changes due to a > >>> rollback. > >>> > >>> Proposal: do not allow lock when a confirming-commit is pending. > >>> > >> This seems fine, along with many other small changes, > >> except the WG already decided not to change the base capability, > >> so there is no way for a client to tell an RFC4741 server > >> from a 4741bis server. An old client is not going > >> to be looking for a 1.1 confirmed-commit capability, > >> so anything that worked before (even gray areas like this) > >> need to be considered compliant. > > > > What does this have to do with confirmed-commit:1.1??? > > You cannot add 1.1 because it changes the way 1.0 works. I'm sorry, but how does 1.1, as I proposed, chnage the way 1.0 works? /martin From mbj@tail-f.com Wed Mar 17 05:50:48 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3093A682F for ; Wed, 17 Mar 2010 05:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9ds-RvJimM6 for ; Wed, 17 Mar 2010 05:50:47 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D30763A681A for ; Wed, 17 Mar 2010 05:50:43 -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 79EC3616009; Wed, 17 Mar 2010 13:50:53 +0100 (CET) Date: Wed, 17 Mar 2010 13:50:53 +0100 (CET) Message-Id: <20100317.135053.94942791.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BA0CA52.9090600@iwl.com> References: <201003171144.o2HBi02G030180@idle.juniper.net> <4BA0CA52.9090600@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 12:50:48 -0000 Andy Bierman wrote: > I object to any changes to 4741 that cause an old server > or old client (compliant to RFC 4741) to be considered a bug > in the new version. The problem with most of the things we're discussing lies in the term "compliant". If the spec is unclear so that different implementations behave differently, it should be clarified. We are chartered to fix bugs, and we can even do extensions in order to fix bugs. /martin From mbj@tail-f.com Wed Mar 17 06:38:34 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A273A6A3B for ; Wed, 17 Mar 2010 06:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.07 X-Spam-Level: * X-Spam-Status: No, score=1.07 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DZHuAH3rf-2 for ; Wed, 17 Mar 2010 06:38:33 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id D8B3D3A689F for ; Wed, 17 Mar 2010 06:38:28 -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 8233B616009 for ; Wed, 17 Mar 2010 14:38:38 +0100 (CET) Date: Wed, 17 Mar 2010 14:38:37 +0100 (CET) Message-Id: <20100317.143837.256396087.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Netconf] comments on draft-ietf-netconf-with-defaults-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 13:38:35 -0000 Hi, Some comments on the latest with-default draft: sec 2.1. -------- OLD: A server indicating 'explicit' either in the basic or the also- supported parameter NEW: A server indicating 'explicit' either in the 'basic-mode' or the 'also-supported' parameter sec 2.4. -------- The capability identifier and namespace is: urn:ietf:params:netconf:capability:with-defaults:1.0 Do we really need to 1.0? With YANG, we have another mechanism to indicate version, (which also is used in this draft). I suggest we remove ':1.0'. sec 2.4. -------- s/the basic parameter/the 'basic-mode' parameter/ sec 2.6. -------- [I reported this comment last time, but I didn't get any comment, so I don't know if it was forgotten or rejected.] OLD: A new XML [W3C.REC-xml-20001006] child element is added to the method-name element. This is the element that indicates the type of the operation e.g. , or . NEW: A new XML child element is added to the , , and rpc operations. sec 2.6. -------- s/by the capability identifier's parameter/by the capability identifier's 'basic-mode' parameter sec 4. ------ This document should registers the YANG module in the YANG Module Names registry (see yang draft) /martin From andyb@iwl.com Wed Mar 17 08:42:45 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751013A695F for ; Wed, 17 Mar 2010 08:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.772 X-Spam-Level: X-Spam-Status: No, score=-2.772 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Us5NlW1wbh+0 for ; Wed, 17 Mar 2010 08:42:44 -0700 (PDT) Received: from smtp194.iad.emailsrvr.com (smtp194.iad.emailsrvr.com [207.97.245.194]) by core3.amsl.com (Postfix) with ESMTP id E8FA43A6929 for ; Wed, 17 Mar 2010 08:42:38 -0700 (PDT) Received: from relay29.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay29.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 79BAD1B4082; Wed, 17 Mar 2010 11:42:48 -0400 (EDT) Received: by relay29.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 1D3C51B407B; Wed, 17 Mar 2010 11:42:48 -0400 (EDT) Message-ID: <4BA0F82B.8030006@iwl.com> Date: Wed, 17 Mar 2010 08:41:31 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4B9FFBD3.2040603@iwl.com> <20100317.132207.131010805.mbj@tail-f.com> <4BA0CB34.4000502@iwl.com> <20100317.134524.09979196.mbj@tail-f.com> In-Reply-To: <20100317.134524.09979196.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 15:42:45 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Martin Bjorklund wrote: >>>>> Hi, >>>>> >>>>> Andy Bierman wrote: >>>>>> Hi, >>>>>> >>>>>> First there was the Robust Configuration draft, which proposed >>>>>> a verified-commit procedure. Then there was some consensus >>>>>> towards decoupling the verify and commit procedures. Then there >>>>>> was a suggestion to improve the commit procedure with a new >>>>>> capability. Old clients would still work because there would >>>>>> be 1 or more new parameters that must be present to select the >>>>>> new behavior. The new confirmed-commit-1.1 >>>>>> capability would add a parameter to the >>>>>> operation. >>>>>> >>>>>> There are no proposed edits at this time. >>>>>> The WG needs to decide on a basic solution approach first: >>>>>> >>>>>> A) add a new capability which changes the commit procedure >>>>>> to allow the original server to terminate without >>>>>> canceling the confirmed commit; detailed proposal >>>>>> from Martin is still needed, and WG consensus on >>>>>> all the details is needed >>>>> I think there are 4 problems with the :confirmed-commit:1.0 >>>>> capability. >>>>> >>>>> 1. It is not clear if the confirming commit MUST be sent on the >>>>> same session which sent the confirmed commit. >>>>> >>>>> Since the confirmed commit is aborted if the original session is >>>>> terminated, it seems to make sense that the confirming commit >>>>> MUST be sent on the original session. Also, allowing the >>>>> confirming commit to be sent on other sessions opens up >>>>> interesting access control questions. >>>>> >>>>> FWIW, I know two different implementations that has interpreted >>>>> the text this way. >>>>> >>>> It is clear -- the confirmed commit is rolled back >>>> if the session that started it is terminated. >>> *That* is clear, I agree. But that's not what I wrote. The question >>> is if the confirming commit can be sent over a different session. >>> >>>>> 2. The text says: >>>>> >>>>> Thus to cancel a confirmed commit and revert changes without >>>>> waiting for the confirm timeout to expire, the client can >>>>> explicitly restore the configuration to its state before the >>>>> confirmed commit was issued. >>>>> >>>>> But there is no way to "explicitly restore" the configuration. >>>>> >>>> close-session >>> If this is what the text really refers to, the text should mention it, >>> and not call it explicit: >>> >>> Thus to cancel a confirmed commit and revert changes without >>> waiting for the confirm timeout to expire, the client can >>> restore the configuration to its state before the >>> confirmed commit was issued by closing the session. >>> >>> But I don't think close-session is what the original text refered >>> to... >>> >>>>> 3. If another client takes a lock when the confirming commit is >>>>> pending, it will be surprised if the config changes due to a >>>>> rollback. >>>>> >>>>> Proposal: do not allow lock when a confirming-commit is pending. >>>>> >>>> This seems fine, along with many other small changes, >>>> except the WG already decided not to change the base capability, >>>> so there is no way for a client to tell an RFC4741 server >>>> from a 4741bis server. An old client is not going >>>> to be looking for a 1.1 confirmed-commit capability, >>>> so anything that worked before (even gray areas like this) >>>> need to be considered compliant. >>> What does this have to do with confirmed-commit:1.1??? >> You cannot add 1.1 because it changes the way 1.0 works. > > I'm sorry, but how does 1.1, as I proposed, chnage the way 1.0 works? > > I already explained it. For a client that doesn't know about your 1.1 capability or the verified-commit capability from my draft, that it is similar, this changes the 1.0 contract. Behavior which is unspecified on a gray area in 1.0 needs to stay that way in 1.0. If a 1.0 client starts getting errors that didn't happen before (e.g., return an error for a lock request when a c-commit is pending), then the server is broken. If the server advertises 1.0 and 1.1, how does it maintain its 1.0 behavior for old clients? I understand how the new client can opt-in by using a new parameter, but new errors are different. > /martin > Andy From mehmet.ersue@nsn.com Wed Mar 17 08:51:15 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4969C3A68C6; Wed, 17 Mar 2010 08:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=0.808, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0N0nDEEZmVVS; Wed, 17 Mar 2010 08:51:14 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id EF2093A6896; Wed, 17 Mar 2010 08:51:13 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2HFpLJk018533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Mar 2010 16:51:21 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2HFpL2N016738; Wed, 17 Mar 2010 16:51:21 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 16:51:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Mar 2010 16:51:17 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A645DAECB@DEMUEXC006.nsn-intra.net> In-Reply-To: <4BA0CA8F.3010805@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Invitation to NETCONF and YANG discussions, Sunday @ IETF 77 Thread-Index: AcrFzSTXdecsW1wqQxuESOlfYGbdLAAG6fUQ References: <4BA0CA8F.3010805@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Carl Moberg" , "NETCONF WG" , "NETMOD WG" X-OriginalArrivalTime: 17 Mar 2010 15:51:20.0936 (UTC) FILETIME=[B04CDE80:01CAC5E9] Subject: Re: [Netconf] [netmod] Invitation to NETCONF and YANG discussions, Sunday @ IETF 77 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 15:51:15 -0000 Dear Carl, thank you for orbaizing this valuable discussion. There is the IEPG meeting until noon. I assume=20 Bert and David K will be also in the IEPG meeting. Would it make sense to start the discussion at 12:30=20 to catch some food beforehand? Cheers, Mehmet =20 > -----Original Message----- > From: netmod-bounces@ietf.org=20 > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Carl Moberg > Sent: Wednesday, March 17, 2010 1:27 PM > To: NETCONF WG; NETMOD WG > Subject: [netmod] Invitation to NETCONF and YANG=20 > discussions,Sunday @ IETF 77 >=20 > This is an open invitation for sharing and discussing implementation > and operational experiences of NETCONF and YANG on Sunday, March 21 > 2010 from 12:00noon to 3:00pm in the Carmel room at the=20 > Anaheim Hilton. >=20 > We are particularily looking for input to the following open=20 > questions: > - Any experience from implementing NETCONF and YANG? > - What can be expected from NETCONF and YANG implementations? > - Any operational pros and cons of NETCONF and YANG? > - What can be done to make NETCONF and YANG more useful in > operator environments? > - Any additional ideas or thoughts on where NETCONF and YANG could be > applicable to address configuration management issues? >=20 > Refreshments will be available. >=20 > Regards, > --=20 > Carl Moberg > mailto:calle@tail-f.com > http://www.tail-f.com > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From mehmet.ersue@nsn.com Wed Mar 17 08:53:26 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 786FF28C0E8; Wed, 17 Mar 2010 08:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[AWL=0.673, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joAluqRobE6o; Wed, 17 Mar 2010 08:53:25 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 58AA928C0E6; Wed, 17 Mar 2010 08:53:25 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2HFrX1w015946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Mar 2010 16:53:33 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2HFrVAN022286; Wed, 17 Mar 2010 16:53:32 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Mar 2010 16:53:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Mar 2010 16:53:21 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A645DAECF@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Invitation to NETCONF and YANG discussions, Sunday @ IETF 77 Thread-Index: AcrFzSTXdecsW1wqQxuESOlfYGbdLAAG6fUQAABAlkA= References: <4BA0CA8F.3010805@tail-f.com> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Carl Moberg" , "NETCONF WG" , "NETMOD WG" X-OriginalArrivalTime: 17 Mar 2010 15:53:32.0312 (UTC) FILETIME=[FE9B4180:01CAC5E9] Subject: Re: [Netconf] [netmod] Invitation to NETCONF and YANG discussions, Sunday @ IETF 77 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 15:53:26 -0000 s/ba/gan/ =20 > -----Original Message----- > From: Ersue, Mehmet (NSN - DE/Munich)=20 > Sent: Wednesday, March 17, 2010 4:51 PM > To: 'ext Carl Moberg'; NETCONF WG; NETMOD WG > Subject: RE: [netmod] Invitation to NETCONF and YANG=20 > discussions,Sunday @ IETF 77 >=20 >=20 > Dear Carl, >=20 > thank you for orbaizing this valuable discussion. >=20 > There is the IEPG meeting until noon. I assume=20 > Bert and David K will be also in the IEPG meeting. >=20 > Would it make sense to start the discussion at 12:30=20 > to catch some food beforehand? >=20 > Cheers, > Mehmet >=20 > =20 >=20 > > -----Original Message----- > > From: netmod-bounces@ietf.org=20 > > [mailto:netmod-bounces@ietf.org] On Behalf Of ext Carl Moberg > > Sent: Wednesday, March 17, 2010 1:27 PM > > To: NETCONF WG; NETMOD WG > > Subject: [netmod] Invitation to NETCONF and YANG=20 > > discussions,Sunday @ IETF 77 > >=20 > > This is an open invitation for sharing and discussing implementation > > and operational experiences of NETCONF and YANG on Sunday, March 21 > > 2010 from 12:00noon to 3:00pm in the Carmel room at the=20 > > Anaheim Hilton. > >=20 > > We are particularily looking for input to the following open=20 > > questions: > > - Any experience from implementing NETCONF and YANG? > > - What can be expected from NETCONF and YANG implementations? > > - Any operational pros and cons of NETCONF and YANG? > > - What can be done to make NETCONF and YANG more useful in > > operator environments? > > - Any additional ideas or thoughts on where NETCONF and=20 > YANG could be > > applicable to address configuration management issues? > >=20 > > Refreshments will be available. > >=20 > > Regards, > > --=20 > > Carl Moberg > > mailto:calle@tail-f.com > > http://www.tail-f.com > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > >=20 From j.schoenwaelder@jacobs-university.de Wed Mar 17 09:05:05 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6C23A6BA4 for ; Wed, 17 Mar 2010 09:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.296 X-Spam-Level: X-Spam-Status: No, score=-0.296 tagged_above=-999 required=5 tests=[AWL=-1.777, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uSaOeMcePTP for ; Wed, 17 Mar 2010 09:05:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 78A383A6BAC for ; Wed, 17 Mar 2010 09:05:03 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 53139C002E; Wed, 17 Mar 2010 17:05:13 +0100 (CET) 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 EGBNpLVWkgjV; Wed, 17 Mar 2010 17:05:12 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 13D90C0035; Wed, 17 Mar 2010 17:05:12 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id ED97410E130B; Wed, 17 Mar 2010 17:05:11 +0100 (CET) Date: Wed, 17 Mar 2010 17:05:11 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100317160511.GA945@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netconf@ietf.org" References: <4B9FFBD3.2040603@iwl.com> <20100317.132207.131010805.mbj@tail-f.com> <4BA0CB34.4000502@iwl.com> <20100317.134524.09979196.mbj@tail-f.com> <4BA0F82B.8030006@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BA0F82B.8030006@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 17 Mar 2010 16:05:05 -0000 On Wed, Mar 17, 2010 at 04:41:31PM +0100, Andy Bierman wrote: > Behavior which is unspecified on a gray area in 1.0 needs > to stay that way in 1.0. > > If a 1.0 client starts getting errors that didn't happen > before (e.g., return an error for a lock request when > a c-commit is pending), then the server is broken. If the behaviour of some protocol feature is unspecified, should a well written client not be able to deal with any behaviour? /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 Wed Mar 17 09:15:10 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB633A6837 for ; Wed, 17 Mar 2010 09:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.055 X-Spam-Level: X-Spam-Status: No, score=-0.055 tagged_above=-999 required=5 tests=[AWL=-0.628, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+1lg9jWl7i5 for ; Wed, 17 Mar 2010 09:15:10 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id E5FDD3A67A3 for ; Wed, 17 Mar 2010 09:15:08 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id C9742616009; Wed, 17 Mar 2010 17:15:17 +0100 (CET) Date: Wed, 17 Mar 2010 17:15:17 +0100 (CET) Message-Id: <20100317.171517.187646319.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BA0F82B.8030006@iwl.com> References: <4BA0CB34.4000502@iwl.com> <20100317.134524.09979196.mbj@tail-f.com> <4BA0F82B.8030006@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 16:15:10 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> You cannot add 1.1 because it changes the way 1.0 works. > > > > I'm sorry, but how does 1.1, as I proposed, chnage the way 1.0 works? > > > > I already explained it. > For a client that doesn't know about your 1.1 capability > or the verified-commit capability from my draft, that it > is similar, this changes the 1.0 contract. No! Please read my proposal again. The confirmed-commit:1.1 does not in any way change any error code -- it just adds new optional operations & parameters. /martin From andyb@iwl.com Wed Mar 17 09:21:54 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6A128C0F2 for ; Wed, 17 Mar 2010 09:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.556 X-Spam-Level: X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbVI97pQi-Lx for ; Wed, 17 Mar 2010 09:21:52 -0700 (PDT) Received: from smtp154.dfw.emailsrvr.com (smtp154.dfw.emailsrvr.com [67.192.241.154]) by core3.amsl.com (Postfix) with ESMTP id A112E3A692F for ; Wed, 17 Mar 2010 09:20:06 -0700 (PDT) Received: from relay5.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay5.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id BE4AA3EF317; Wed, 17 Mar 2010 12:20:16 -0400 (EDT) Received: by relay5.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 651063EF179; Wed, 17 Mar 2010 12:20:16 -0400 (EDT) Message-ID: <4BA100F3.8020908@iwl.com> Date: Wed, 17 Mar 2010 09:18:59 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund , "netconf@ietf.org" References: <4B9FFBD3.2040603@iwl.com> <20100317.132207.131010805.mbj@tail-f.com> <4BA0CB34.4000502@iwl.com> <20100317.134524.09979196.mbj@tail-f.com> <4BA0F82B.8030006@iwl.com> <20100317160511.GA945@elstar.local> In-Reply-To: <20100317160511.GA945@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 16:21:54 -0000 Juergen Schoenwaelder wrote: > On Wed, Mar 17, 2010 at 04:41:31PM +0100, Andy Bierman wrote: > >> Behavior which is unspecified on a gray area in 1.0 needs >> to stay that way in 1.0. >> >> If a 1.0 client starts getting errors that didn't happen >> before (e.g., return an error for a lock request when >> a c-commit is pending), then the server is broken. > > If the behaviour of some protocol feature is unspecified, should a > well written client not be able to deal with any behaviour? > No -- the client will end up dealing with specific server behavior that it needs to support. You and Martin seem to be completely missing my point, so I will repeat it. There are well understood mechanisms for distinguishing 2 separate versions of a protocol. This WG does not want to use any of them, and instead insists that a 1.0 client will just deal will all the changes in a 1.1 server, and if it doesn't, it must be the 1.0 client's fault for using a poorly specified standard. Adding to an existing set of capabilities does nothing to tell an old client it is dealing with a new server and a new version of the protocol. > /js > Andy From calle@tail-f.com Wed Mar 17 10:03:19 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4AC3A6A3A; Wed, 17 Mar 2010 10:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7y4cqZC56x1T; Wed, 17 Mar 2010 10:03:18 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 55CD43A67A3; Wed, 17 Mar 2010 10:03:18 -0700 (PDT) Received: from calle-macbook.local (c83-250-192-57.bredband.comhem.se [83.250.192.57]) by mail.tail-f.com (Postfix) with ESMTPSA id D130E61600A; Wed, 17 Mar 2010 18:03:26 +0100 (CET) Message-ID: <4BA10B5D.40209@tail-f.com> Date: Wed, 17 Mar 2010 18:03:25 +0100 From: Carl Moberg User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <4BA0CA8F.3010805@tail-f.com> <80A0822C5E9A4440A5117C2F4CD36A645DAECB@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A645DAECB@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETCONF WG , NETMOD WG Subject: Re: [Netconf] [netmod] Invitation to NETCONF and YANG discussions, Sunday @ IETF 77 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 17:03:19 -0000 Mehmet, We are arranging for food to be available in the room (TBA exactly what, but something like pizza). On 2010-03-17 16:51 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > > Dear Carl, > > thank you for orbaizing this valuable discussion. > > There is the IEPG meeting until noon. I assume > Bert and David K will be also in the IEPG meeting. > > Would it make sense to start the discussion at 12:30 > to catch some food beforehand? > > Cheers, > Mehmet > > > >> -----Original Message----- >> From: netmod-bounces@ietf.org >> [mailto:netmod-bounces@ietf.org] On Behalf Of ext Carl Moberg >> Sent: Wednesday, March 17, 2010 1:27 PM >> To: NETCONF WG; NETMOD WG >> Subject: [netmod] Invitation to NETCONF and YANG >> discussions,Sunday @ IETF 77 >> >> This is an open invitation for sharing and discussing implementation >> and operational experiences of NETCONF and YANG on Sunday, March 21 >> 2010 from 12:00noon to 3:00pm in the Carmel room at the >> Anaheim Hilton. >> >> We are particularily looking for input to the following open >> questions: >> - Any experience from implementing NETCONF and YANG? >> - What can be expected from NETCONF and YANG implementations? >> - Any operational pros and cons of NETCONF and YANG? >> - What can be done to make NETCONF and YANG more useful in >> operator environments? >> - Any additional ideas or thoughts on where NETCONF and YANG could be >> applicable to address configuration management issues? >> >> Refreshments will be available. >> >> Regards, >> -- >> Carl Moberg >> mailto:calle@tail-f.com >> http://www.tail-f.com >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> From j.schoenwaelder@jacobs-university.de Wed Mar 17 11:22:26 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7056E3A6BCF for ; Wed, 17 Mar 2010 11:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[AWL=-1.338, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqHQTi+G87em for ; Wed, 17 Mar 2010 11:22:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AE10D3A677D for ; Wed, 17 Mar 2010 11:21:40 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61FC6C002E; Wed, 17 Mar 2010 19:21:50 +0100 (CET) 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 BaHIIEUgHSQg; Wed, 17 Mar 2010 19:21:49 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9BA4CC001A; Wed, 17 Mar 2010 19:21:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7C9EA10E17D7; Wed, 17 Mar 2010 19:21:48 +0100 (CET) Date: Wed, 17 Mar 2010 19:21:48 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100317182148.GA1206@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netconf@ietf.org" References: <4B9FFBD3.2040603@iwl.com> <20100317.132207.131010805.mbj@tail-f.com> <4BA0CB34.4000502@iwl.com> <20100317.134524.09979196.mbj@tail-f.com> <4BA0F82B.8030006@iwl.com> <20100317160511.GA945@elstar.local> <4BA100F3.8020908@iwl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BA100F3.8020908@iwl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 17 Mar 2010 18:22:26 -0000 On Wed, Mar 17, 2010 at 05:18:59PM +0100, Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Wed, Mar 17, 2010 at 04:41:31PM +0100, Andy Bierman wrote: > > > >> Behavior which is unspecified on a gray area in 1.0 needs > >> to stay that way in 1.0. > >> > >> If a 1.0 client starts getting errors that didn't happen > >> before (e.g., return an error for a lock request when > >> a c-commit is pending), then the server is broken. > > > > If the behaviour of some protocol feature is unspecified, should a > > well written client not be able to deal with any behaviour? > > No -- the client will end up dealing with specific server > behavior that it needs to support. But since there is no standard behaviour, such a client will misbehave anyway if it hits a certain type of servers. > You and Martin seem to be completely missing my point, so > I will repeat it. There are well understood mechanisms > for distinguishing 2 separate versions of a protocol. > > This WG does not want to use any of them, and instead > insists that a 1.0 client will just deal will all the > changes in a 1.1 server, and if it doesn't, > it must be the 1.0 client's fault for using > a poorly specified standard. I suggest you leave it to chairs to determine concensus. That said, if a certain protocol behaviour is not defined and a client then silently assumes a certain behaviour, the client is at its own risk. > Adding to an existing set of capabilities does nothing > to tell an old client it is dealing with a new server > and a new version of the protocol. Yes, but for the old client, nothing has changed since the expected server behaviour was undefined. Now we can go on in circles, but perhaps we should also look at how many deployed clients are affected by this. The larger this number and the more mission critical they are, the better for all of us. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andyb@iwl.com Wed Mar 17 11:28:33 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF0B3A693F for ; Wed, 17 Mar 2010 11:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.515 X-Spam-Level: X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[AWL=-1.460, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uNQxCnuNng3 for ; Wed, 17 Mar 2010 11:28:32 -0700 (PDT) Received: from smtp234.iad.emailsrvr.com (smtp234.iad.emailsrvr.com [207.97.245.234]) by core3.amsl.com (Postfix) with ESMTP id 541FA3A68B9 for ; Wed, 17 Mar 2010 11:28:32 -0700 (PDT) Received: from relay13.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay13.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 5A1B51CF1AA for ; Wed, 17 Mar 2010 14:28:42 -0400 (EDT) Received: by relay13.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 2BF4B1D5002 for ; Wed, 17 Mar 2010 14:28:42 -0400 (EDT) Message-ID: <4BA11F0C.2010509@iwl.com> Date: Wed, 17 Mar 2010 11:27:24 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] new capability proposal for netconf: base:1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 18:28:33 -0000 Hi, I am strongly opposed to the way RFC 4741 is being updated because the base protocol capability is the same as RFC 4741. Instead of a new confirmed-commit:1.1 capability, I propose an alternative: New capability: base:1.1 urn:ietf:params:xml:ns:netconf:base:1.1 A 4741bis-compliant client or server will advertise the base:1.0 and base:1.1 capability URIs. It will examine the base URI returned from its NETCONF peer and use the highest version advertised (1.0 or 1.1). A base:1.1 NETCONF entity complies with all mandatory behavior in RFC4741bis, and knows there are gray areas in a base:1.0 entity that may not work the same way on all servers. I do not accept the argument that just because RFC XXX doesn't say 'foo", it is okay to add "foo" to it, and still expect implementations of RFC XXX to be unaffected. Pros: - People will ask: Which RFC do I need to read to learn about the protocol version that server X is using? Current solution does not offer any clue. - This covers all new text in RFC4741bis. Currently, it is extremely unclear what the differences are between a 4741 server and a 4741bis server, but there are many non-trivial clarifications. - There are no implementations that know about confirmed-commit:1;1 or base:1.1 at this time. In that respect, they are conceptually equivalent. Except base:1.1 is better because it covers the entire document and lets users know which server version they are using. - This proposal allows us to fix things we know have workable solutions, such as rpc-warning, or capability-changed errors, etc., that can only be present if a new client is talking to a new server. - Using 1 capability URI to bundle all the new features is a rather common practice, and proven to be manageable. Creating lots of little capabilities is more complex. Cons: - Must admit that 4741bis is not backwards-compatible with 4741 Andy From mbj@tail-f.com Wed Mar 17 12:09:48 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B7163A6972 for ; Wed, 17 Mar 2010 12:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.643 X-Spam-Level: X-Spam-Status: No, score=-0.643 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY-6zj0sWDNn for ; Wed, 17 Mar 2010 12:09:47 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id B88583A6808 for ; Wed, 17 Mar 2010 12:09:46 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 0C778616009; Wed, 17 Mar 2010 20:09:56 +0100 (CET) Date: Wed, 17 Mar 2010 20:09:55 +0100 (CET) Message-Id: <20100317.200955.160256200.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BA100F3.8020908@iwl.com> References: <4BA0F82B.8030006@iwl.com> <20100317160511.GA945@elstar.local> <4BA100F3.8020908@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 19:09:48 -0000 Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Wed, Mar 17, 2010 at 04:41:31PM +0100, Andy Bierman wrote: > > > >> Behavior which is unspecified on a gray area in 1.0 needs > >> to stay that way in 1.0. > >> > >> If a 1.0 client starts getting errors that didn't happen > >> before (e.g., return an error for a lock request when > >> a c-commit is pending), then the server is broken. > > > > If the behaviour of some protocol feature is unspecified, should a > > well written client not be able to deal with any behaviour? > > > > > No -- the client will end up dealing with specific server > behavior that it needs to support. > > You and Martin seem to be completely missing my point, so > I will repeat it. There are well understood mechanisms > for distinguishing 2 separate versions of a protocol. Andy, I think *you* are missing *my* point. The proposed :confirmed-commit:1.1 capability does not change existing behavior at all. It adds some optional parameters and one optional rpc. Further, the nice thing with all the capabilities is that we *can* update single capabilities without updating the base protocol. /martin From andyb@iwl.com Wed Mar 17 14:04:29 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7853A67DA for ; Wed, 17 Mar 2010 14:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBAilTAIlsJb for ; Wed, 17 Mar 2010 14:04:28 -0700 (PDT) Received: from smtp194.iad.emailsrvr.com (smtp194.iad.emailsrvr.com [207.97.245.194]) by core3.amsl.com (Postfix) with ESMTP id C41923A68C3 for ; Wed, 17 Mar 2010 14:04:28 -0700 (PDT) Received: from relay29.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay29.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id E855B1B4020; Wed, 17 Mar 2010 17:04:38 -0400 (EDT) Received: by relay29.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id A94E31B400A; Wed, 17 Mar 2010 17:04:38 -0400 (EDT) Message-ID: <4BA14397.2000103@iwl.com> Date: Wed, 17 Mar 2010 14:03:19 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4BA0F82B.8030006@iwl.com> <20100317160511.GA945@elstar.local> <4BA100F3.8020908@iwl.com> <20100317.200955.160256200.mbj@tail-f.com> In-Reply-To: <20100317.200955.160256200.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 21:04:29 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Wed, Mar 17, 2010 at 04:41:31PM +0100, Andy Bierman wrote: >>> >>>> Behavior which is unspecified on a gray area in 1.0 needs >>>> to stay that way in 1.0. >>>> >>>> If a 1.0 client starts getting errors that didn't happen >>>> before (e.g., return an error for a lock request when >>>> a c-commit is pending), then the server is broken. >>> If the behaviour of some protocol feature is unspecified, should a >>> well written client not be able to deal with any behaviour? >>> >> >> No -- the client will end up dealing with specific server >> behavior that it needs to support. >> >> You and Martin seem to be completely missing my point, so >> I will repeat it. There are well understood mechanisms >> for distinguishing 2 separate versions of a protocol. > > Andy, I think *you* are missing *my* point. The proposed > :confirmed-commit:1.1 capability does not change existing behavior at > all. It adds some optional parameters and one optional rpc. > I am talking about the error for locking the candidate, and other changes in the spec that are not covered by your capability. I understand that lots of little 'non-changes', and protocol versions, and protocol permutations, do not make interoperability easier for the client, but rather makes it much worse. > Further, the nice thing with all the capabilities is that we *can* > update single capabilities without updating the base protocol. > > I completely disagree that this is a feature. The nice thing about a version update is that it is clear which protocol version you are using. The confirmed-commit:1.1 capability is optional, and only relevant if candidate and cc:1.0 are also supported, it cannot be used as the simple way for all clients to tell which RFC version each server supports. Since a base:1.1 server is required to act like a base:1.0 server if the client only requests base:1.0, how does this even affect clients that do not wish to update? Why do you see a version update as harmful, when it has no affect whatsoever on old clients and old servers? > > /martin > Andy From mbj@tail-f.com Wed Mar 17 14:16:40 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59D263A672E for ; Wed, 17 Mar 2010 14:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZEKr7u42cCP for ; Wed, 17 Mar 2010 14:16:39 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C7A103A6964 for ; Wed, 17 Mar 2010 14:16:35 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3C33661600D; Wed, 17 Mar 2010 22:16:45 +0100 (CET) Date: Wed, 17 Mar 2010 22:16:44 +0100 (CET) Message-Id: <20100317.221644.225410038.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BA14397.2000103@iwl.com> References: <4BA100F3.8020908@iwl.com> <20100317.200955.160256200.mbj@tail-f.com> <4BA14397.2000103@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 21:16:40 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy, I think *you* are missing *my* point. The proposed > > :confirmed-commit:1.1 capability does not change existing behavior at > > all. It adds some optional parameters and one optional rpc. > > > > I am talking about the error for locking the candidate, > and other changes in the spec that are not covered > by your capability. Ok, good, so you do agree that the proposed :confirmed-commit:1.1 does not break old clients. Re. the lock, I will start by (re-)asking a simple question: Do you agree that when the lock is taken, the db MUST NOT be modified by anyone but the session that owns the lock? > I understand that lots of little 'non-changes', and protocol versions, > and protocol permutations, do not make interoperability easier for the client, > but rather makes it much worse. For better or worse, NETCONF has many capabilities, each with its own version number. > > Further, the nice thing with all the capabilities is that we *can* > > update single capabilities without updating the base protocol. > > > > > > I completely disagree that this is a feature. > The nice thing about a version update is that it > is clear which protocol version you are using. > > The confirmed-commit:1.1 capability is optional, > and only relevant if candidate and cc:1.0 are also > supported, it cannot be used as the simple way for all clients > to tell which RFC version each server supports. > > Since a base:1.1 server is required to act like a > base:1.0 server if the client only requests base:1.0, > how does this even affect clients that do not wish > to update? Why do you see a version update as harmful, > when it has no affect whatsoever on old clients > and old servers? I haven't said that I think a base:1.1 is harmful. But I do think we should avoid it if we can. It all boils down to the changes we want to make. For example, if we decide we want to add/redesign warnings, we must do a base:1.1. I do not think that any of the changes we currently have require a new base version. [If we do make a base:1.1, we can get rid of all capabilities and use features instead. Then the protocol will work the way you describe above - the client can immediately know which rfc the server implements.] /martin From andyb@iwl.com Wed Mar 17 15:40:41 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80543A69A8 for ; Wed, 17 Mar 2010 15:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrYo6G-OWTl7 for ; Wed, 17 Mar 2010 15:40:41 -0700 (PDT) Received: from smtp194.iad.emailsrvr.com (smtp194.iad.emailsrvr.com [207.97.245.194]) by core3.amsl.com (Postfix) with ESMTP id CE3923A67F7 for ; Wed, 17 Mar 2010 15:40:40 -0700 (PDT) Received: from relay19.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay19.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 27D8D1B5804; Wed, 17 Mar 2010 18:40:51 -0400 (EDT) Received: by relay19.relay.iad.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id B2DE31B56D1; Wed, 17 Mar 2010 18:40:50 -0400 (EDT) Message-ID: <4BA15A71.7030809@iwl.com> Date: Wed, 17 Mar 2010 15:40:49 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4BA100F3.8020908@iwl.com> <20100317.200955.160256200.mbj@tail-f.com> <4BA14397.2000103@iwl.com> <20100317.221644.225410038.mbj@tail-f.com> In-Reply-To: <20100317.221644.225410038.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 22:40:41 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy, I think *you* are missing *my* point. The proposed >>> :confirmed-commit:1.1 capability does not change existing behavior at >>> all. It adds some optional parameters and one optional rpc. >>> >> I am talking about the error for locking the candidate, >> and other changes in the spec that are not covered >> by your capability. > > Ok, good, so you do agree that the proposed :confirmed-commit:1.1 does > not break old clients. no, I am not against adding the new functionality, especially since it looks so similar to the proposal I had in an earlier draft. IMO, we should use base:1.1 for the entirety of the 4741bis updates. There is no possibility of hiding a new version. All the WEB pages and RFC Index will say RFC 4741 (Obsoleted by RFC 5xxx). > > Re. the lock, I will start by (re-)asking a simple question: > > Do you agree that when the lock is taken, the db MUST NOT be > modified by anyone but the session that owns the lock? > I agree with you that the lock should not be granted to any session while the candidate rollback is possible. I just want to make it clear to users and clients which protocol version has the mandatory server error, and which is TBD by the client. >> I understand that lots of little 'non-changes', and protocol versions, >> and protocol permutations, do not make interoperability easier for the client, >> but rather makes it much worse. > > For better or worse, NETCONF has many capabilities, each with its own > version number. But these are not all bad. We started out (guided by Phil) making sure that we could model real-world native platforms. (IMO, we may have done that too well to get any standard content ;-) We should consider all the c-commit:1.1 changes to be bugfixes, because we have consensus on the need for a more robust solution. That means they are automatic if the server supports c-commit:1.0 and base:1.1. > >>> Further, the nice thing with all the capabilities is that we *can* >>> update single capabilities without updating the base protocol. >>> >>> >> I completely disagree that this is a feature. >> The nice thing about a version update is that it >> is clear which protocol version you are using. >> >> The confirmed-commit:1.1 capability is optional, >> and only relevant if candidate and cc:1.0 are also >> supported, it cannot be used as the simple way for all clients >> to tell which RFC version each server supports. >> >> Since a base:1.1 server is required to act like a >> base:1.0 server if the client only requests base:1.0, >> how does this even affect clients that do not wish >> to update? Why do you see a version update as harmful, >> when it has no affect whatsoever on old clients >> and old servers? > > I haven't said that I think a base:1.1 is harmful. But I do think we > should avoid it if we can. It all boils down to the changes we want > to make. For example, if we decide we want to add/redesign warnings, > we must do a base:1.1. I do not think that any of the changes we > currently have require a new base version. > > [If we do make a base:1.1, we can get rid of all capabilities and use > features instead. Then the protocol will work the way you describe > above - the client can immediately know which rfc the server > implements.] > The client will know either way. IMO, a base:1.1 is cleaner because we keep wanting to fix things that were not quite right in 1.0. We cannot possibly add capabilities for every behavior change, and in the long run, nobody will want that. I would like to get rid of all the little capabilities and use YANG features instead. Right now, I have not bothered to implement ietf-netconf.yang directly, since nobody supports it and I have to know all the capability values anyway for 1.0. Unless we put a stake in the ground and say we want people to use the 1.1 version, we have to support the 1.0 flaws forever. Users need to know how to tell the different RFCs apart, based on protocol version, or something every server supports. > > /martin > Andy From andyb@iwl.com Wed Mar 17 15:51:48 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991323A69DA for ; Wed, 17 Mar 2010 15:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbLQ7HLr7-J4 for ; Wed, 17 Mar 2010 15:51:47 -0700 (PDT) Received: from smtp154.dfw.emailsrvr.com (smtp154.dfw.emailsrvr.com [67.192.241.154]) by core3.amsl.com (Postfix) with ESMTP id DC17E3A6821 for ; Wed, 17 Mar 2010 15:51:47 -0700 (PDT) Received: from relay5.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay5.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 5DF6A3F0E03; Wed, 17 Mar 2010 18:51:58 -0400 (EDT) Received: by relay5.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 287CA3EF907; Wed, 17 Mar 2010 18:51:58 -0400 (EDT) Message-ID: <4BA15D0C.8040804@iwl.com> Date: Wed, 17 Mar 2010 15:51:56 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4BA100F3.8020908@iwl.com> <20100317.200955.160256200.mbj@tail-f.com> <4BA14397.2000103@iwl.com> <20100317.221644.225410038.mbj@tail-f.com> In-Reply-To: <20100317.221644.225410038.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 22:51:48 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy, I think *you* are missing *my* point. The proposed >>> :confirmed-commit:1.1 capability does not change existing behavior at >>> all. It adds some optional parameters and one optional rpc. >>> >> I am talking about the error for locking the candidate, >> and other changes in the spec that are not covered >> by your capability. > > Ok, good, so you do agree that the proposed :confirmed-commit:1.1 does > not break old clients. > Is there some reason why this cannot be added as a YANG feature and not a capability at all, since ietf-netconf.yang is normative? It's just different strings in the content to the protocol. > > /martin > Andy From mbj@tail-f.com Thu Mar 18 00:39:15 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AAF23A67EB for ; Thu, 18 Mar 2010 00:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gS3Bv9kFALE7 for ; Thu, 18 Mar 2010 00:39:13 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0893C3A6822 for ; Thu, 18 Mar 2010 00:39:04 -0700 (PDT) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 3DB6661601D; Thu, 18 Mar 2010 08:39:14 +0100 (CET) Date: Thu, 18 Mar 2010 08:39:13 +0100 (CET) Message-Id: <20100318.083913.20786389.mbj@tail-f.com> To: andyb@iwl.com From: Martin Bjorklund In-Reply-To: <4BA15D0C.8040804@iwl.com> References: <4BA14397.2000103@iwl.com> <20100317.221644.225410038.mbj@tail-f.com> <4BA15D0C.8040804@iwl.com> X-Mailer: Mew version 6.2.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 07:39:15 -0000 Andy Bierman wrote: > Martin Bjorklund wrote: > > Andy Bierman wrote: > >> Martin Bjorklund wrote: > >>> Andy, I think *you* are missing *my* point. The proposed > >>> :confirmed-commit:1.1 capability does not change existing behavior at > >>> all. It adds some optional parameters and one optional rpc. > >>> > >> I am talking about the error for locking the candidate, > >> and other changes in the spec that are not covered > >> by your capability. > > > > Ok, good, so you do agree that the proposed :confirmed-commit:1.1 does > > not break old clients. > > > > > Is there some reason why this cannot be added as a YANG feature > and not a capability at all, since ietf-netconf.yang is > normative? The capability string for base 1.0 must not contain any query components. An old client will probably not understand urn:ietf:params:netconf:base:1.0?features=confimred-commit-1.1 /martin From andyb@iwl.com Thu Mar 18 09:18:21 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2383A699D for ; Thu, 18 Mar 2010 09:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-go0YtSXRDv for ; Thu, 18 Mar 2010 09:18:20 -0700 (PDT) Received: from smtp154.dfw.emailsrvr.com (smtp154.dfw.emailsrvr.com [67.192.241.154]) by core3.amsl.com (Postfix) with ESMTP id 856B33A6889 for ; Thu, 18 Mar 2010 09:18:19 -0700 (PDT) Received: from relay15.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay15.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 4384730B1382; Thu, 18 Mar 2010 12:18:25 -0400 (EDT) Received: by relay15.relay.dfw.mlsrvr.com (Authenticated sender: andyb-AT-iwlcorp.com) with ESMTPSA id 1407E30B0B82; Thu, 18 Mar 2010 12:18:25 -0400 (EDT) Message-ID: <4BA2524E.8030407@iwl.com> Date: Thu, 18 Mar 2010 09:18:22 -0700 From: Andy Bierman Organization: Interworking Labs, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Martin Bjorklund References: <4BA14397.2000103@iwl.com> <20100317.221644.225410038.mbj@tail-f.com> <4BA15D0C.8040804@iwl.com> <20100318.083913.20786389.mbj@tail-f.com> In-Reply-To: <20100318.083913.20786389.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] 4741bis: issue 13, confirmed-commit (new capability) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: andyb@iwl.com List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 16:18:21 -0000 Martin Bjorklund wrote: > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Martin Bjorklund wrote: >>>>> Andy, I think *you* are missing *my* point. The proposed >>>>> :confirmed-commit:1.1 capability does not change existing behavior at >>>>> all. It adds some optional parameters and one optional rpc. >>>>> >>>> I am talking about the error for locking the candidate, >>>> and other changes in the spec that are not covered >>>> by your capability. >>> Ok, good, so you do agree that the proposed :confirmed-commit:1.1 does >>> not break old clients. >>> >> >> Is there some reason why this cannot be added as a YANG feature >> and not a capability at all, since ietf-netconf.yang is >> normative? > > The capability string for base 1.0 must not contain any query > components. An old client will probably not understand > > > urn:ietf:params:netconf:base:1.0?features=confimred-commit-1.1 > > This would never happen because a 4741-compliant server does not get to pick and choose pieces of 4741bis to implement. But actually, doesn't the ietf-netconf.yang module capability break this supposed rule? According to the YANG spec, a server using ietf-netconf.yang would need to advertise: urn:ietf:params:netconf:base:1.0?module=ietf-netconf&revision=2010-xx-xx&feature=candidate ... I know my code would not handle this right now because the spec says this specific URI must exactly match the string. IMO, this is another reason base:1.1 would help. The rule needs to be refined for 4741bis, so the XML namespace is an exact match to the capability URI base part (w/o any parameters). The client needs to do this already for YANG module capability URIs. > > /martin > Andy From lhotka@cesnet.cz Sun Mar 21 10:35:07 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91DD23A6AF7 for ; Sun, 21 Mar 2010 10:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.48 X-Spam-Level: ** X-Spam-Status: No, score=2.48 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B62xc5qKQaME for ; Sun, 21 Mar 2010 10:35:06 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id B5A373A6AF1 for ; Sun, 21 Mar 2010 10:35:06 -0700 (PDT) Received: from [130.129.25.190] (unknown [130.129.25.190]) by office2.cesnet.cz (Postfix) with ESMTPSA id 2DB212CDE058 for ; Sun, 21 Mar 2010 18:35:21 +0100 (CET) From: Ladislav Lhotka