From mehmet.ersue@nsn.com Mon Jul 1 03:59:56 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C968B21F9DFC for ; Mon, 1 Jul 2013 03:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.197 X-Spam-Level: X-Spam-Status: No, score=-106.197 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbvJRi04748K for ; Mon, 1 Jul 2013 03:59:52 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAF421F9DF7 for ; Mon, 1 Jul 2013 03:59:52 -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 r61AxoVl027097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 1 Jul 2013 12:59:51 +0200 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r61AxnsL029540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 1 Jul 2013 12:59:50 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.45]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Mon, 1 Jul 2013 12:59:49 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: Agenda Preparation for the Netconf Session in Berlin Thread-Index: AQHOdkoabeW9RxYcDEKqx4iOaL4pOg== Date: Mon, 1 Jul 2013 10:59:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1520 X-purgate-ID: 151667::1372676391-00002EAE-D4B09901/0-0/0-0 Subject: [Netconf] Agenda Preparation for the Netconf Session in Berlin X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 10:59:56 -0000 Dear All, we would like to poll the WG opinion on the priority of open issues and pos= sible agenda items. The two chartered items will for sure have their discussion, where the Reve= rse SSH slot will be most likely attended by the SSH/SAAG people. Some time ago we discussed different topics and their priorities (http://ww= w.ietf.org/mail-archive/web/netconf/current/msg08044.html). For IETF #87 we= asked for a Netconf session on a later day of the week to enable adhoc dis= cussions and consolidate the different views. Which topics do you see as important and should be discussed in the Netconf= session? Would a side meeting e.g. on Monday be useful to prepare a possible way for= ward? Mehmet & Bert > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behal= f Of ext > Ersue, Mehmet (NSN - DE/Munich) > Sent: Friday, June 28, 2013 6:16 PM > To: netconf@ietf.org > Subject: [Netconf] netconf - Requested session has been scheduled for IET= F 87 >=20 > Hi All, >=20 > the Netconf sessions have been scheduled as shown below: >=20 > netconf Session 1+2 (2:00:00) >=20 > Wednesday, Afternoon Session III 1620-1720 > Room Name: Charlottenburg 1 >=20 > Wednesday, Afternoon Session III 1620-1720 > Room Name: Charlottenburg 1 >=20 > Cheers, > Mehmet >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From cmavr8@gmail.com Tue Jul 2 03:41:05 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3444911E8480 for ; Tue, 2 Jul 2013 03:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dO4Sp3t5oqUf for ; Tue, 2 Jul 2013 03:41:04 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id AFF1C11E8476 for ; Tue, 2 Jul 2013 03:41:03 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id 10so3157614lbf.8 for ; Tue, 02 Jul 2013 03:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=RdrziWlUXDk9dANWUgKnzHTgSvLJuQz1Uh38gnRr+Dc=; b=g1nZQucmhFrMdWYfmRR5KWiDsKWaj2buIAqc/7So9+1lD7GGrgJ8JNvqLR98/TFyoz 3qkap0SUbAOIvaDUYY/ByY3+3e2zIpMLxjx5QDBNcAlrvTXgvqHSDjnqbDgq8C68rUMz dImoN+TPoLT3YozUXsiHD9uJ7RMa3TG2ea2ANzIzby0jcIxz15akDsD3fR0emTipdxBe EhSV2NakOUxgrUS+fB8mWqbq1rb4l/LDLBnFVD1SeU6DQscmoZERgPZs53hcHfR9WGnG VApA9sLGK50b9gURNgHt+ln1/nSYasG4vQnati0ilUDaV24Jb0YPnMutX3RZKvwtyNj1 go3w== X-Received: by 10.112.185.40 with SMTP id ez8mr13331776lbc.31.1372761662419; Tue, 02 Jul 2013 03:41:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.160.68 with HTTP; Tue, 2 Jul 2013 03:40:32 -0700 (PDT) From: Chris Mavrakis Date: Tue, 2 Jul 2013 13:40:32 +0300 Message-ID: To: netconf@ietf.org Content-Type: multipart/alternative; boundary=001a11c3cb763ff96d04e084fb7f Subject: Re: [Netconf] Yuma? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 10:44:39 -0000 --001a11c3cb763ff96d04e084fb7f Content-Type: text/plain; charset=UTF-8 Regarding the email thread below (I was not a member of the mailing list so I just copied it here), I would like to note the following: The Yuma repository on sourceforge has "disappeared" months ago, indeed. Searching for it in SF results in one result, but once one clicks on it, they get "Whoops, we can't find that page.". I have found a project called yuma123, which is a copy of the original open-source yuma. Mr Vladimir Vassilev is maintaining it and developing it further. Mr Stone, maybe the two projects should be combined in one? Different branches can be used. I also have some modules of mine that I'm planning to integrate. ------------------------------ - *To*: Andrew Stone > - *Subject*: Re: [Netconf] Yuma? - *From*: Andy Bierman > - *Date*: Sat, 27 Apr 2013 11:42:01 -0700 - *Cc*: Netconf > - *Delivered-to*: netconf at ietfa.amsl.com - *In-reply-to*: > - *List-archive*: - *List-help*: > - *List-id*: Network Configuration WG mailing list - *List-post*: > - *List-subscribe*: , < mailto:netconf-request@ietf.org?subject=subscribe > - *List-unsubscribe*: , < mailto:netconf-request@ietf.org?subject=unsubscribe > - *References*: > ------------------------------ Hi, To be clear, we did not take the Yuma open-source private. We forked YumaPro from Yuma about 18 months ago and nobody has really worked on Yuma since. thanks, Andy On Fri, Apr 26, 2013 at 2:50 PM, Andrew Stone wrote: > Yuma seems to have disappeared... I think it went closed-source into Yuma > Works. But since it is BSD licensed, I have created a git repository > https://github.com/openclovis/openyuma which contains the 2.2.5 release. > > Andy Bierman, I want to thank for your tremendous effort on this project!! > and I'm sorry to see you go closed source... but I do understand :-). > > Best, > Andy Stone > Software Architect, OpenClovis, Inc. > > _______________________________________________ > Netconf mailing list > Netconf at ietf.org > https://www.ietf.org/mailman/listinfo/netconf --001a11c3cb763ff96d04e084fb7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Regarding the email thread below (I = was not a member of the mailing list so I just copied it here), I would lik= e to note the following:

The Yuma repository o= n sourceforge has "disappeared" months ago, indeed.
Searching for it in SF results in one result, but once one clicks on it, they get "Whoops, we= can't find that page.".

I have found a project c= alled yuma123, whi= ch is a copy of the original open-source yuma. Mr Vladimir Vassilev is main= taining it and developing it further.

Mr Stone, maybe the two = projects should be combined in one? Different branches can be used. I also = have some modules of mine that I'm planning to integrate.


Hi,

To be clear, we did not take the Yuma open-source private.
and nobody has really worked on Yuma since.

thanks,
Andy


On Fri, Apr 26, 2013 at 2:50 PM, Andrew Stone=C2=A0<stone at openclovis.com>=C2=A0wrote:
Yuma seems to have disappeared... I think it went closed-s= ource into Yuma Works. =C2=A0But since it is BSD licensed, I have created a= git repository=C2=A0https://github.com/openclovis/openyuma= =C2=A0which contains the 2.2.5 release.

Andy Bierman, I want to thank for your tremendous effort on = this project!! and I'm sorry to see you go closed source... but I do un= derstand :-).

Best,
Andy Stone
Software Architect, OpenClovis, Inc.

__________________= _____________________________
Netconf mailing list
Netconf at ietf.org
https://www.ietf.org/mailman/listinfo/netconf
--001a11c3cb763ff96d04e084fb7f-- From mouse@Chip.Rodents-Montreal.ORG Sat Jun 29 08:11:19 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865D611E8156 for ; Sat, 29 Jun 2013 08:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFFDQ5+jws1M for ; Sat, 29 Jun 2013 08:11:14 -0700 (PDT) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4D48D11E8152 for ; Sat, 29 Jun 2013 08:11:14 -0700 (PDT) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id LAA19439; Sat, 29 Jun 2013 11:11:01 -0400 (EDT) Date: Sat, 29 Jun 2013 11:11:01 -0400 (EDT) From: Mouse Message-Id: <201306291511.LAA19439@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sat, 29 Jun 2013 10:37:07 -0400 (EDT) To: Jeffrey Hutzelman , draft-ietf-netconf-reverse-ssh@tools.ietf.org, netconf@ietf.org In-Reply-To: <1372273452.23365.49.camel@minbar.fac.cs.cmu.edu> References: <1372273452.23365.49.camel@minbar.fac.cs.cmu.edu> X-Mailman-Approved-At: Tue, 02 Jul 2013 08:06:23 -0700 Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 15:11:19 -0000 > The point is that before _any_ connection is ever started, an SSH > client knows who the host is supposed to be. Well, in some sense of "who". > It uses that as a key into its database of host keys, if you're using > a keyex method that uses host keys. It may. For a server to have a host key at all is only a SHOULD, not a MUST. So, for that matter, is checking it; skipping that is NOT RECOMMENDED, not MUST NOT. > You cannot discover the host's identity from anything that appears as > part of the connection; you need to know in advance what it is > supposed to be. This is at most semi-true. If a client does know a host key, then a server presenting it (and passing the usual challenge) is evidence that the server is the one the host key belongs to, evidence approximately as strong as the security of that server against leaking the corresponding secret data (or of the algorithm against its being cryptanalyzed, whichever is weaker). My own implementation, for example, uses this to hint to the user that a key is known and thus the connected-to host might actually be known by some other name; typical behaviour in such a case might look like % ssh somename No ssh-rsa key known for somename/22 Host key: ssh-rsa [fingerprints] Other hosts for which this key is known: othername/22 thirdname/20000 somename.example.com/22 Continue connecting? (yes/no/save/?) I have used this to discover what host is at an address I don't recognize (at work I often deal with multihomed hosts, often with rDNS missing for some or sometimes even all of their addresses). Of course, that's not to say that I then proceed to type passwords into such connections. I will typically ^C out at the prompt in cases like the above - and I normally never use password auth anyway, even when talking to known hosts. > This is why it's fairly important, in SSH, for the endpoint that > originated the connection to be the one that is the SSH client. The > connection originator knows in advance who it thinks it is going to > talk to, which SSH requires, I'm not convinced it does. Require it, that is. The security properties of such use are not well studied, at least not as far as I've seen, but it certainly can be done. > whereas the endpoint accepting the connection does not -- it needs to > decide whether whoever did connect is authorized. True. But I see no obvious reason why this can't be done via the usual "authenticate (SSH) server to (SSH) client" mechanisms. This may sound as though I'm arguing in favour of reverse SSH. In a sense perhaps I am; I certainly am arguing that it's not obviously ludicrous. I am far from convinced it's safe enough to standarize, but I'm also far from convinced it's out of the question. > Once an ssh connection is established, _channels_ can be opened by > either end, at will. In practice it generally only makes sense to > open some kinds of channels in one direction or the other, but the > protocol imposes no constraints here. This is, of course, true, and I note that the existing implementations do just that, for forwarded TCP connections if nothing else. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From lhotka@nic.cz Wed Jul 3 05:54:35 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE4B21F934C for ; Wed, 3 Jul 2013 05:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.247 X-Spam-Level: X-Spam-Status: No, score=-1.247 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+mbb-t504Aw for ; Wed, 3 Jul 2013 05:54:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4092121F9301 for ; Wed, 3 Jul 2013 05:54:34 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id E9922140117 for ; Wed, 3 Jul 2013 14:54:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1372856073; bh=UiVxj9jB8jCSQhF2r94y9WNP3iEaLGjkIyOiV+/fRDE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=dpq2Sswj5+lXuE3PPjp6Y/yzT3r/P2wpITqSljy3VUWGHfeBUjSGxG7b/tBv5MQGW dfosWa7j61KunDja/C2Z6ZmctkbhP8+EL/w1xBJ/w54kfZgWE/D7NttwdyxW6QXv2j XW5eCTCzy8D+V2Iro+X5YXstu8TqsDIGWYJ+fNpY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <00bd01ce74bb$934e1f40$4001a8c0@gateway.2wire.net> Date: Wed, 3 Jul 2013 14:54:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <415BD41D-2409-4817-A0CB-ED1F0735DFAD@nic.cz> References: <00bd01ce74bb$934e1f40$4001a8c0@gateway.2wire.net> To: Netconf X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 12:54:35 -0000 [NETCONF list only] Hi, a colleague of mine proposed to define XMPP as a new transport for = NETCONF. This would certainly solve the "calling home" issue, and may = have other use cases, such as offloading authentication from the = devices. The idea is to use a (dedicated) XMPP server as a proxy to = which both NETCONF server and client connect as XMPP clients. Looking into XMPP spec (RFC 6120), the protocols seems to be a perfect = fit for transporting NETCONF. Strictly speaking, it doesn't satisfy the = requirements of 6241 in that there is no direct connection between the = NETCONF server and client, but IMO it could work fine even without it. So I wonder - has anybody considered this option? At least one router = vendor (Arista) does this, though not with NETCONF. Lada On Jun 29, 2013, at 1:23 PM, t.petch wrote: > ---- Original Message ----- > From: "Kent Watsen" > To: "t.petch" ; "Martin Bjorklund" = > Cc: ; > Sent: Friday, June 28, 2013 10:26 PM > On 6/26/13 1:36 PM, "t.petch" wrote: >=20 >> Yes, that I understand. >>=20 >> But ... the firewalls I know, at least the better ones, can look for > and >> reject PDU of protocols such as SSH, regardless of which ports the = TCP >> connection is using. So in that sense, a device behind a firewall = that >> filters SSH connections still cannot be accessed. Is this an > acceptable >> limitation? >=20 > I would think so - this is what Juniper has been doing for almost a > decade > now and I've never heard this raised as an issue before. >=20 >> My other point is that I cannot see how this is a generic solution as >> the I-D claims. You need something to signal that this three-way TCP >> handshake is for Netconf over SSH and the only parameter I can see is >> the port number, so this I-D cannot be used for anything else over >> anything else; each combination of protocols will need a different = port >> number. >=20 > By "generic", the draft is trying to say that the solution applied to > solve this problem can equally well be applied to other protocols that > use > SSH for their transport. >=20 > > OK, so it is limited to reverse SSH (as opposed to a generic call = home) > and that is what the I-D says, so that is ok. >=20 > But ... I would like to see a note added that the server/device must = be > prepared to receive any SSH PDU and act appropriately and not just > assume it is netconf. I am wondering if there is a Security > Consideration in there somewhere but cannot put my finger on one. >=20 > Tom Petch >=20 > >=20 > That said, I'll just add that the port number does not have to be = bound > to > how the application might use the SSH connection. For instance, when = a > Junos device connects to our management server, yes, it knows it can > open > the "netconf" subsystem, but it also knows all the other subsystems it > can > start...and it does! For instance, it will open additional SSH = channels > for SFTP, notifications, packet captures, etc. It would've been = easier > if > SSH defined a subsystem-discovery mechanism, but we worked around that > too. >=20 > Thanks, > Kent >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From ietfdbh@comcast.net Wed Jul 3 07:30:54 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4830711E81B0 for ; Wed, 3 Jul 2013 07:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.237 X-Spam-Level: X-Spam-Status: No, score=-99.237 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFhNf3Jg9hFi for ; Wed, 3 Jul 2013 07:30:49 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 7352A11E81AF for ; Wed, 3 Jul 2013 07:30:49 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta06.westchester.pa.mail.comcast.net with comcast id vnJf1l0030ldTLk56qWpE2; Wed, 03 Jul 2013 14:30:49 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta04.westchester.pa.mail.comcast.net with comcast id vqWo1l0162yZEBF01qWoAV; Wed, 03 Jul 2013 14:30:48 +0000 From: "ietfdbh" To: "'Ladislav Lhotka'" , "'Netconf'" Date: Wed, 3 Jul 2013 10:30:26 -0400 Message-ID: <006b01ce77f9$dc933500$95b99f00$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac53+Vd02FXg2cGXSDOIdVfGETHIWw== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372861849; bh=oHJudPaK1Y2VjZUkufsyikjJzKriSpu7MlfNwPM0qgw=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=XwYwheOD9Gls7Zk3ak/qKB3Zu0R1+X9yEnhtucfUi+MNWenP2BH/H8RSWXY/d0KGS 7W+NdpP9tNwwNS+JI1MDjZUXmt0zfog9VEt4EqKiGjqG58TOK6E5Tg0dJMDpUiPhaY upFl9ZUtjtZBHaV8myRnyeB1KId1lxu1i0OErykW7jzBzoSb1lzHjYEj/oj7cpxI+M wz5nZvlQmplcpE20WI0+iKJbsbjb7pfP8mvUymWU74AthdZXq0075bbzuCENy8aaP3 NKak2Aij/tFJcwM1rBX9lY6H48oKS6ID9J11zREEXmTDmO1+xfiTThAxtsowTQDiQ0 hrXSpxky2QLfg== Subject: [Netconf] XMPP as transport X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 14:30:58 -0000 Hi Lada, I would be interested in your analysis of how XMPP does/does not meet the rfc6241 requirements for transport. For example, can Netconf reliably determine if a connection is terminated, so it knows to release locks? David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Ladislav Lhotka > Sent: Wednesday, July 03, 2013 8:55 AM > To: Netconf > Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt > > [NETCONF list only] > > Hi, > > a colleague of mine proposed to define XMPP as a new transport for > NETCONF. This would certainly solve the "calling home" issue, and may have > other use cases, such as offloading authentication from the devices. The idea > is to use a (dedicated) XMPP server as a proxy to which both NETCONF > server and client connect as XMPP clients. > > Looking into XMPP spec (RFC 6120), the protocols seems to be a perfect fit > for transporting NETCONF. Strictly speaking, it doesn't satisfy the > requirements of 6241 in that there is no direct connection between the > NETCONF server and client, but IMO it could work fine even without it. > > So I wonder - has anybody considered this option? At least one router > vendor (Arista) does this, though not with NETCONF. > > Lada > > On Jun 29, 2013, at 1:23 PM, t.petch wrote: > > > ---- Original Message ----- > > From: "Kent Watsen" > > To: "t.petch" ; "Martin Bjorklund" > > > > Cc: ; > > Sent: Friday, June 28, 2013 10:26 PM > > On 6/26/13 1:36 PM, "t.petch" wrote: > > > >> Yes, that I understand. > >> > >> But ... the firewalls I know, at least the better ones, can look for > > and > >> reject PDU of protocols such as SSH, regardless of which ports the > >> TCP connection is using. So in that sense, a device behind a > >> firewall that filters SSH connections still cannot be accessed. Is > >> this an > > acceptable > >> limitation? > > > > I would think so - this is what Juniper has been doing for almost a > > decade now and I've never heard this raised as an issue before. > > > >> My other point is that I cannot see how this is a generic solution as > >> the I-D claims. You need something to signal that this three-way TCP > >> handshake is for Netconf over SSH and the only parameter I can see is > >> the port number, so this I-D cannot be used for anything else over > >> anything else; each combination of protocols will need a different > >> port number. > > > > By "generic", the draft is trying to say that the solution applied to > > solve this problem can equally well be applied to other protocols that > > use SSH for their transport. > > > > > > OK, so it is limited to reverse SSH (as opposed to a generic call > > home) and that is what the I-D says, so that is ok. > > > > But ... I would like to see a note added that the server/device must > > be prepared to receive any SSH PDU and act appropriately and not just > > assume it is netconf. I am wondering if there is a Security > > Consideration in there somewhere but cannot put my finger on one. > > > > Tom Petch > > > > > > > > That said, I'll just add that the port number does not have to be > > bound to how the application might use the SSH connection. For > > instance, when a Junos device connects to our management server, yes, > > it knows it can open the "netconf" subsystem, but it also knows all > > the other subsystems it can start...and it does! For instance, it > > will open additional SSH channels for SFTP, notifications, packet > > captures, etc. It would've been easier if SSH defined a > > subsystem-discovery mechanism, but we worked around that too. > > > > Thanks, > > Kent > > > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From lhotka@nic.cz Wed Jul 3 09:33:43 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED08E21F9DE2 for ; Wed, 3 Jul 2013 09:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocoNHkr1K-um for ; Wed, 3 Jul 2013 09:33:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7E621F9DDD for ; Wed, 3 Jul 2013 09:33:41 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id ED50413F84E; Wed, 3 Jul 2013 18:33:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1372869221; bh=GWtgsWYELx+tsrlRT6pYCcd7iN4sMpN4x+RPWB/s+z0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=mEz2XRNzUKGS90VJj09vMTsWKCwAIt88cXxmKivz5os05Dx1ij+Pi8MbInE4g17+n yRtQuCss6E+3AY1Dj2Ba7i5Nbih2JF469ALGeAQURvkffsX51F3ZpUd+av4NcSTfHT MlXKwNLC8d8b0mTorUlCpVrUcmnbi00i8av2QrYE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <006b01ce77f9$dc933500$95b99f00$@comcast.net> Date: Wed, 3 Jul 2013 18:33:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <006b01ce77f9$dc933500$95b99f00$@comcast.net> To: "ietfdbh" X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] XMPP as transport X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 16:33:44 -0000 On Jul 3, 2013, at 4:30 PM, "ietfdbh" wrote: > Hi Lada, >=20 > I would be interested in your analysis of how XMPP does/does not meet = the > rfc6241 requirements for transport. XMPP streams are secure and authenticated, typically via TLS & SASL. = However, the endpoints of each stream are a XMPP server and client, so = the messaging between NETCONF client and server must therefore be = mediated by one or more XMPP servers, and the NETCONF parties must trust = those XMPP servers. NETCONF usernames can be derived either from JID, or just from its local = part. The "iq" stanza can be used for wrapping NETCONF RPC requests and = replies, and "message" for notifications. An XMPP server must ensure = in-order processing of the stanzas from a connected client (sec. 10.1 in = RFC 6120). > For example, can Netconf reliably determine if a connection is = terminated, > so it knows to release locks? It could be done using the same mechanism that Jabber clients use for = determining the presence of their peers. Lada >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >> Behalf Of Ladislav Lhotka >> Sent: Wednesday, July 03, 2013 8:55 AM >> To: Netconf >> Subject: Re: [Netconf] I-D Action: = draft-ietf-netconf-reverse-ssh-00.txt >>=20 >> [NETCONF list only] >>=20 >> Hi, >>=20 >> a colleague of mine proposed to define XMPP as a new transport for >> NETCONF. This would certainly solve the "calling home" issue, and may = have >> other use cases, such as offloading authentication from the devices. = The > idea >> is to use a (dedicated) XMPP server as a proxy to which both NETCONF >> server and client connect as XMPP clients. >>=20 >> Looking into XMPP spec (RFC 6120), the protocols seems to be a = perfect fit >> for transporting NETCONF. Strictly speaking, it doesn't satisfy the >> requirements of 6241 in that there is no direct connection between = the >> NETCONF server and client, but IMO it could work fine even without = it. >>=20 >> So I wonder - has anybody considered this option? At least one router >> vendor (Arista) does this, though not with NETCONF. >>=20 >> Lada >>=20 >> On Jun 29, 2013, at 1:23 PM, t.petch wrote: >>=20 >>> ---- Original Message ----- >>> From: "Kent Watsen" >>> To: "t.petch" ; "Martin Bjorklund" >>> >>> Cc: ; >>> Sent: Friday, June 28, 2013 10:26 PM >>> On 6/26/13 1:36 PM, "t.petch" wrote: >>>=20 >>>> Yes, that I understand. >>>>=20 >>>> But ... the firewalls I know, at least the better ones, can look = for >>> and >>>> reject PDU of protocols such as SSH, regardless of which ports the >>>> TCP connection is using. So in that sense, a device behind a >>>> firewall that filters SSH connections still cannot be accessed. Is >>>> this an >>> acceptable >>>> limitation? >>>=20 >>> I would think so - this is what Juniper has been doing for almost a >>> decade now and I've never heard this raised as an issue before. >>>=20 >>>> My other point is that I cannot see how this is a generic solution = as >>>> the I-D claims. You need something to signal that this three-way = TCP >>>> handshake is for Netconf over SSH and the only parameter I can see = is >>>> the port number, so this I-D cannot be used for anything else over >>>> anything else; each combination of protocols will need a different >>>> port number. >>>=20 >>> By "generic", the draft is trying to say that the solution applied = to >>> solve this problem can equally well be applied to other protocols = that >>> use SSH for their transport. >>>=20 >>> >>> OK, so it is limited to reverse SSH (as opposed to a generic call >>> home) and that is what the I-D says, so that is ok. >>>=20 >>> But ... I would like to see a note added that the server/device must >>> be prepared to receive any SSH PDU and act appropriately and not = just >>> assume it is netconf. I am wondering if there is a Security >>> Consideration in there somewhere but cannot put my finger on one. >>>=20 >>> Tom Petch >>>=20 >>> >>>=20 >>> That said, I'll just add that the port number does not have to be >>> bound to how the application might use the SSH connection. For >>> instance, when a Junos device connects to our management server, = yes, >>> it knows it can open the "netconf" subsystem, but it also knows all >>> the other subsystems it can start...and it does! For instance, it >>> will open additional SSH channels for SFTP, notifications, packet >>> captures, etc. It would've been easier if SSH defined a >>> subsystem-discovery mechanism, but we worked around that too. >>>=20 >>> Thanks, >>> Kent >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Jul 3 10:36:46 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C61121F96F5 for ; Wed, 3 Jul 2013 10:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdV5Ez7b8lbX for ; Wed, 3 Jul 2013 10:36:42 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1F87B21F9CD6 for ; Wed, 3 Jul 2013 10:36:42 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id rl6so459048pac.29 for ; Wed, 03 Jul 2013 10:36:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=k2V2QYRerK5E0orUI+vwvGWN3tOi1A5FCZrPw684frE=; b=EBqbfy4YHNZ2AwWpgmZAQ/G43DTu4D+Z/2MXN0dxhyVNiZh0Pktb2KlgQ8FbEp4uvN EebSALfdOad8D5rHXatTOopR6Nt7zvVPyFTTxZvAzu0wLEtn8WL8oPsCw46+wwGk0fAF FR+LjHz4DrPUh87O4ktWry9TyJUm9nnMKiCCYVHxjdzoXlwqMNOrkoJf8GQ4VElFmIxS faV0A0LCf+H1wWT2a6DuYD9bBpl4hm4VJIe623IP+Dkz7QjTWW5QH03elyt3VBUFxcBO VPylsrl4KCpB07w7bre7cVjCLY98KrZkQSxTRCRRMnHO93xKHfQ8tTi9vK+n7shh5hSn Fa5Q== MIME-Version: 1.0 X-Received: by 10.66.234.71 with SMTP id uc7mr3445980pac.10.1372873001725; Wed, 03 Jul 2013 10:36:41 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Wed, 3 Jul 2013 10:36:41 -0700 (PDT) In-Reply-To: References: <006b01ce77f9$dc933500$95b99f00$@comcast.net> Date: Wed, 3 Jul 2013 10:36:41 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlxTSQgxoq1cPKpVv3DVslFeckpcRGsP3qPzcUWP3c81qF97QH3/h10Kp+8Fpfvo7i2bJAZ Cc: Netconf Subject: Re: [Netconf] XMPP as transport X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 17:36:46 -0000 Hi, The "must therefore be mediated by one or more XMPP servers" part doesn't sound too great. Perhaps somebody should implement a prototype and compar= e the performance characteristics to NETCONF/SSH or NETCONF/TLS for multi-client provisioning. Then write an I-D explaining why we need another NETCONF transport, and it should be XMPP. Andy On Wed, Jul 3, 2013 at 9:33 AM, Ladislav Lhotka wrote: > > On Jul 3, 2013, at 4:30 PM, "ietfdbh" wrote: > >> Hi Lada, >> >> I would be interested in your analysis of how XMPP does/does not meet th= e >> rfc6241 requirements for transport. > > XMPP streams are secure and authenticated, typically via TLS & SASL. Howe= ver, the endpoints of each stream are a XMPP server and client, so the mess= aging between NETCONF client and server must therefore be mediated by one o= r more XMPP servers, and the NETCONF parties must trust those XMPP servers. > > NETCONF usernames can be derived either from JID, or just from its local = part. > > The "iq" stanza can be used for wrapping NETCONF RPC requests and replies= , and "message" for notifications. An XMPP server must ensure in-order proc= essing of the stanzas from a connected client (sec. 10.1 in RFC 6120). > >> For example, can Netconf reliably determine if a connection is terminate= d, >> so it knows to release locks? > > It could be done using the same mechanism that Jabber clients use for det= ermining the presence of their peers. > > Lada > >> >> David Harrington >> ietfdbh@comcast.net >> +1-603-828-1401 >> >>> -----Original Message----- >>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >>> Behalf Of Ladislav Lhotka >>> Sent: Wednesday, July 03, 2013 8:55 AM >>> To: Netconf >>> Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.tx= t >>> >>> [NETCONF list only] >>> >>> Hi, >>> >>> a colleague of mine proposed to define XMPP as a new transport for >>> NETCONF. This would certainly solve the "calling home" issue, and may h= ave >>> other use cases, such as offloading authentication from the devices. Th= e >> idea >>> is to use a (dedicated) XMPP server as a proxy to which both NETCONF >>> server and client connect as XMPP clients. >>> >>> Looking into XMPP spec (RFC 6120), the protocols seems to be a perfect = fit >>> for transporting NETCONF. Strictly speaking, it doesn't satisfy the >>> requirements of 6241 in that there is no direct connection between the >>> NETCONF server and client, but IMO it could work fine even without it. >>> >>> So I wonder - has anybody considered this option? At least one router >>> vendor (Arista) does this, though not with NETCONF. >>> >>> Lada >>> >>> On Jun 29, 2013, at 1:23 PM, t.petch wrote: >>> >>>> ---- Original Message ----- >>>> From: "Kent Watsen" >>>> To: "t.petch" ; "Martin Bjorklund" >>>> >>>> Cc: ; >>>> Sent: Friday, June 28, 2013 10:26 PM >>>> On 6/26/13 1:36 PM, "t.petch" wrote: >>>> >>>>> Yes, that I understand. >>>>> >>>>> But ... the firewalls I know, at least the better ones, can look for >>>> and >>>>> reject PDU of protocols such as SSH, regardless of which ports the >>>>> TCP connection is using. So in that sense, a device behind a >>>>> firewall that filters SSH connections still cannot be accessed. Is >>>>> this an >>>> acceptable >>>>> limitation? >>>> >>>> I would think so - this is what Juniper has been doing for almost a >>>> decade now and I've never heard this raised as an issue before. >>>> >>>>> My other point is that I cannot see how this is a generic solution as >>>>> the I-D claims. You need something to signal that this three-way TCP >>>>> handshake is for Netconf over SSH and the only parameter I can see is >>>>> the port number, so this I-D cannot be used for anything else over >>>>> anything else; each combination of protocols will need a different >>>>> port number. >>>> >>>> By "generic", the draft is trying to say that the solution applied to >>>> solve this problem can equally well be applied to other protocols that >>>> use SSH for their transport. >>>> >>>> >>>> OK, so it is limited to reverse SSH (as opposed to a generic call >>>> home) and that is what the I-D says, so that is ok. >>>> >>>> But ... I would like to see a note added that the server/device must >>>> be prepared to receive any SSH PDU and act appropriately and not just >>>> assume it is netconf. I am wondering if there is a Security >>>> Consideration in there somewhere but cannot put my finger on one. >>>> >>>> Tom Petch >>>> >>>> >>>> >>>> That said, I'll just add that the port number does not have to be >>>> bound to how the application might use the SSH connection. For >>>> instance, when a Junos device connects to our management server, yes, >>>> it knows it can open the "netconf" subsystem, but it also knows all >>>> the other subsystems it can start...and it does! For instance, it >>>> will open additional SSH channels for SFTP, notifications, packet >>>> captures, etc. It would've been easier if SSH defined a >>>> subsystem-discovery mechanism, but we worked around that too. >>>> >>>> Thanks, >>>> Kent >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From lhotka@nic.cz Wed Jul 3 10:57:48 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D44A11E810D for ; Wed, 3 Jul 2013 10:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.323 X-Spam-Level: X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ue1q0avPSwb0 for ; Wed, 3 Jul 2013 10:57:47 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DE03011E8102 for ; Wed, 3 Jul 2013 10:57:46 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 4AACC13F8B3; Wed, 3 Jul 2013 19:57:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1372874265; bh=LlhjWW9iliIKo28C3RVW4uz4UvwIUjKaI7IbDi0+xZM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=GIW4ZWr4/r+LXmDwYrCcwpMYaQVrD59D/jDMXpn3J4qcAQRsE+MkdMzdm8JTn+63u +V9sw7IF2UVEu10uJBXNOA+eLlP5FAAs9ha1iFEoAc9cxGH4J2Fnp79Sh7a6BUNfe5 R9iVptzeY6LNM6vAReAnbAi9HmiX9Om31Nut8ULQ= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 3 Jul 2013 19:57:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2D2F00CD-A567-4AC2-8636-5F21023E6558@nic.cz> References: <006b01ce77f9$dc933500$95b99f00$@comcast.net> To: Andy Bierman X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] XMPP as transport X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 17:57:48 -0000 On Jul 3, 2013, at 7:36 PM, Andy Bierman wrote: > Hi, >=20 > The "must therefore be mediated by one or more XMPP servers" part = doesn't > sound too great. Perhaps somebody should implement a prototype and = compare > the performance characteristics to NETCONF/SSH or NETCONF/TLS for > multi-client provisioning. Then write an I-D explaining why we need > another NETCONF transport, and it should be XMPP. Yes, that's my plan, unless somebody convinces me that it's a nonsense. = It may be more effective than bending ssh and facing the opposition of = ssh and security folks. Performance-wise, I don't think a XMPP server could be a bottleneck. Of = course, it's an extra box to care about. Lada >=20 >=20 > Andy >=20 >=20 > On Wed, Jul 3, 2013 at 9:33 AM, Ladislav Lhotka wrote: >>=20 >> On Jul 3, 2013, at 4:30 PM, "ietfdbh" wrote: >>=20 >>> Hi Lada, >>>=20 >>> I would be interested in your analysis of how XMPP does/does not = meet the >>> rfc6241 requirements for transport. >>=20 >> XMPP streams are secure and authenticated, typically via TLS & SASL. = However, the endpoints of each stream are a XMPP server and client, so = the messaging between NETCONF client and server must therefore be = mediated by one or more XMPP servers, and the NETCONF parties must trust = those XMPP servers. >>=20 >> NETCONF usernames can be derived either from JID, or just from its = local part. >>=20 >> The "iq" stanza can be used for wrapping NETCONF RPC requests and = replies, and "message" for notifications. An XMPP server must ensure = in-order processing of the stanzas from a connected client (sec. 10.1 in = RFC 6120). >>=20 >>> For example, can Netconf reliably determine if a connection is = terminated, >>> so it knows to release locks? >>=20 >> It could be done using the same mechanism that Jabber clients use for = determining the presence of their peers. >>=20 >> Lada >>=20 >>>=20 >>> David Harrington >>> ietfdbh@comcast.net >>> +1-603-828-1401 >>>=20 >>>> -----Original Message----- >>>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >>>> Behalf Of Ladislav Lhotka >>>> Sent: Wednesday, July 03, 2013 8:55 AM >>>> To: Netconf >>>> Subject: Re: [Netconf] I-D Action: = draft-ietf-netconf-reverse-ssh-00.txt >>>>=20 >>>> [NETCONF list only] >>>>=20 >>>> Hi, >>>>=20 >>>> a colleague of mine proposed to define XMPP as a new transport for >>>> NETCONF. This would certainly solve the "calling home" issue, and = may have >>>> other use cases, such as offloading authentication from the = devices. The >>> idea >>>> is to use a (dedicated) XMPP server as a proxy to which both = NETCONF >>>> server and client connect as XMPP clients. >>>>=20 >>>> Looking into XMPP spec (RFC 6120), the protocols seems to be a = perfect fit >>>> for transporting NETCONF. Strictly speaking, it doesn't satisfy the >>>> requirements of 6241 in that there is no direct connection between = the >>>> NETCONF server and client, but IMO it could work fine even without = it. >>>>=20 >>>> So I wonder - has anybody considered this option? At least one = router >>>> vendor (Arista) does this, though not with NETCONF. >>>>=20 >>>> Lada >>>>=20 >>>> On Jun 29, 2013, at 1:23 PM, t.petch wrote: >>>>=20 >>>>> ---- Original Message ----- >>>>> From: "Kent Watsen" >>>>> To: "t.petch" ; "Martin Bjorklund" >>>>> >>>>> Cc: ; >>>>> Sent: Friday, June 28, 2013 10:26 PM >>>>> On 6/26/13 1:36 PM, "t.petch" wrote: >>>>>=20 >>>>>> Yes, that I understand. >>>>>>=20 >>>>>> But ... the firewalls I know, at least the better ones, can look = for >>>>> and >>>>>> reject PDU of protocols such as SSH, regardless of which ports = the >>>>>> TCP connection is using. So in that sense, a device behind a >>>>>> firewall that filters SSH connections still cannot be accessed. = Is >>>>>> this an >>>>> acceptable >>>>>> limitation? >>>>>=20 >>>>> I would think so - this is what Juniper has been doing for almost = a >>>>> decade now and I've never heard this raised as an issue before. >>>>>=20 >>>>>> My other point is that I cannot see how this is a generic = solution as >>>>>> the I-D claims. You need something to signal that this three-way = TCP >>>>>> handshake is for Netconf over SSH and the only parameter I can = see is >>>>>> the port number, so this I-D cannot be used for anything else = over >>>>>> anything else; each combination of protocols will need a = different >>>>>> port number. >>>>>=20 >>>>> By "generic", the draft is trying to say that the solution applied = to >>>>> solve this problem can equally well be applied to other protocols = that >>>>> use SSH for their transport. >>>>>=20 >>>>> >>>>> OK, so it is limited to reverse SSH (as opposed to a generic call >>>>> home) and that is what the I-D says, so that is ok. >>>>>=20 >>>>> But ... I would like to see a note added that the server/device = must >>>>> be prepared to receive any SSH PDU and act appropriately and not = just >>>>> assume it is netconf. I am wondering if there is a Security >>>>> Consideration in there somewhere but cannot put my finger on one. >>>>>=20 >>>>> Tom Petch >>>>>=20 >>>>> >>>>>=20 >>>>> That said, I'll just add that the port number does not have to be >>>>> bound to how the application might use the SSH connection. For >>>>> instance, when a Junos device connects to our management server, = yes, >>>>> it knows it can open the "netconf" subsystem, but it also knows = all >>>>> the other subsystems it can start...and it does! For instance, it >>>>> will open additional SSH channels for SFTP, notifications, packet >>>>> captures, etc. It would've been easier if SSH defined a >>>>> subsystem-discovery mechanism, but we worked around that too. >>>>>=20 >>>>> Thanks, >>>>> Kent >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Netconf mailing list >>>>> Netconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netconf >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>>=20 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From stpeter@stpeter.im Wed Jul 3 13:16:19 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877C521F9A7A for ; Wed, 3 Jul 2013 13:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGn1VqCXgryt for ; Wed, 3 Jul 2013 13:16:12 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 64C7521F9A71 for ; Wed, 3 Jul 2013 13:16:12 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1248841360; Wed, 3 Jul 2013 14:16:55 -0600 (MDT) Message-ID: <51D4868A.6020408@stpeter.im> Date: Wed, 03 Jul 2013 14:16:10 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ladislav Lhotka References: <006b01ce77f9$dc933500$95b99f00$@comcast.net> <2D2F00CD-A567-4AC2-8636-5F21023E6558@nic.cz> In-Reply-To: <2D2F00CD-A567-4AC2-8636-5F21023E6558@nic.cz> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Netconf Subject: Re: [Netconf] XMPP as transport X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 20:16:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ahoj. ;-) David Harrington alerted me to this discussion (as author of RFC 6120 etc.), so I've joined the list. On 7/3/13 11:57 AM, Ladislav Lhotka wrote: > > On Jul 3, 2013, at 7:36 PM, Andy Bierman > wrote: > >> Hi, >> >> The "must therefore be mediated by one or more XMPP servers" >> part doesn't sound too great. Perhaps somebody should implement >> a prototype and compare the performance characteristics to >> NETCONF/SSH or NETCONF/TLS for multi-client provisioning. Then >> write an I-D explaining why we need another NETCONF transport, >> and it should be XMPP. Pardon my ignorance of NETCONF, but it seems that even using ssh or some other transport would require some form of mediation, no? It's not as if NETCONF clients and servers talk to each other directly, do they? > Yes, that's my plan, unless somebody convinces me that it's a > nonsense. I would be willing to at least advise you in that work. > It may be more effective than bending ssh and facing the opposition > of ssh and security folks. I have no opinion there. > Performance-wise, I don't think a XMPP server could be a > bottleneck. There are several XMPP server implementations that have been tested up to 100,000 concurrent sessions and beyond. I don't think this should be a problem for NETCONF. > Of course, it's an extra box to care about. Well, the xmpp daemon could be co-located with the NETCONF server (I'm not clear on the usual deployment scenarios for NETCONF). >> On Wed, Jul 3, 2013 at 9:33 AM, Ladislav Lhotka >> wrote: >>> >>> On Jul 3, 2013, at 4:30 PM, "ietfdbh" >>> wrote: >>> >>>> Hi Lada, >>>> >>>> I would be interested in your analysis of how XMPP does/does >>>> not meet the rfc6241 requirements for transport. I will endeavor to read RFC 6241 before long. But it might not happen until after IETF 87. >>> XMPP streams are secure and authenticated, typically via TLS & >>> SASL. However, the endpoints of each stream are a XMPP server >>> and client, so the messaging between NETCONF client and server >>> must therefore be mediated by one or more XMPP servers, and >>> the NETCONF parties must trust those XMPP servers. >>> >>> NETCONF usernames can be derived either from JID, or just from >>> its local part. >>> >>> The "iq" stanza can be used for wrapping NETCONF RPC requests >>> and replies, and "message" for notifications. An XMPP server >>> must ensure in-order processing of the stanzas from a connected >>> client (sec. 10.1 in RFC 6120). That's all correct. >>>> For example, can Netconf reliably determine if a connection >>>> is terminated, so it knows to release locks? >>> >>> It could be done using the same mechanism that Jabber clients >>> use for determining the presence of their peers. Or, if the NETCONF server is integrated with the XMPP server properly, it might have that knowledge based on the status of connections from clients. This, for example, is how folks are using XMPP in the SmartGrid space (see the spec for OpenADR 2.0). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR1IaJAAoJEOoGpJErxa2pLEEP/2N2UXW/ho6HM//fPi0pu172 MVFE6dyKbZuzw1awn4Oc1Gf6XnQvNtkRjwbMHBj59c3oyqI4RhLvBel/qT7oDNMh jLCKdwhyi4LuZsHlb2qV8qDQnUsTxRIW2MMAb9HLG92KKNxMogRd9DBJWWBY3udE BUIq4nUCfIZSUWXBPigNH9TMPw7IO/UQJh67oyVWTeVU0dLdP9eTvWvElb7aA5vD djYAWAcVTw+w0JTBnIJfHuXQK0IwubxPS1oND6DM03V6o1oXnyiLKg8WSsEcQ+8B tWliRyYNH3qo+8M/EnzM7tV8MTCnzCwcxLxiO9vi+xV0HfbOoEjCUTTA49Nk2zui Jhi7Knof/R5FKNZk+p6xC8c7K/uqrURz0YzeVEj8N35SkPTw0/5gx9iZLDGwgRPK uunLy6tBdlDg20q2ly8tkeeeR73v9Ny4mGjnKCds6zgAoQTk3YGaxAva77Uu9yls jG4RhKH5dX26WVpDN5AWoQv1FuVYWn1LaBdC02ucnkr88y+AZyxkvGuPIE2ZwGGp D7uSr4nAJzKYt1jVfGtc3aUSPfLQVv/bvE2inGPF9S3AfKdKtnNYAdk6JaRCClT8 /XIIPnjUnHtsyMlbVyoXhqBRwMO6/StG7FzSZCCJ8M/E1szM2Lt7p5qI+rWkm12y gQx9QqjybIAlPgeZdqkz =uFhG -----END PGP SIGNATURE----- From andy@yumaworks.com Wed Jul 3 15:06:15 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDB611E824A for ; Wed, 3 Jul 2013 15:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnlBvV5CHcxa for ; Wed, 3 Jul 2013 15:06:10 -0700 (PDT) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id BCBAE11E80F6 for ; Wed, 3 Jul 2013 15:06:10 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so551193pbc.35 for ; Wed, 03 Jul 2013 15:06:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=NJ9ce934Hr9OK94BT9VDG0PV6fiSMReVdk+j0uI7V3s=; b=JNe+2OBNCsltJ65dHCsMGoLZd/Jd7u+62cD8H67JIRXeKgQsPCtRv8jASlGhXQI0Ku lZcmvyCev+bKm03ITyigKDl/RoklJ55VGXKdRnJ0KDI+QcZImL1R72W+VpIGdIb1K5Za ODX3p7aTECAk9jiw6BcyywLBC8wnfTaz3/PmX9QBJUMSbgMdmim6HUeWCutBlHyxGxFQ OMiHZ4mLteuvUBzkfADPnGlJ2FKNfLk+rNQeKxQXfmwH/su83NHUhQJtN4b9WzBUpf7N IMkC/igu5U6FJYbhWjlnT2Cc0ChXbHODeRl8f7YwTelwvAIaNWza33VX82BzOhDQB5Px dccQ== MIME-Version: 1.0 X-Received: by 10.68.171.162 with SMTP id av2mr2692780pbc.104.1372889170333; Wed, 03 Jul 2013 15:06:10 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Wed, 3 Jul 2013 15:06:10 -0700 (PDT) In-Reply-To: <51D4868A.6020408@stpeter.im> References: <006b01ce77f9$dc933500$95b99f00$@comcast.net> <2D2F00CD-A567-4AC2-8636-5F21023E6558@nic.cz> <51D4868A.6020408@stpeter.im> Date: Wed, 3 Jul 2013 15:06:10 -0700 Message-ID: From: Andy Bierman To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm0j6hBRhsUDHvIGJTnSPhsZbx6CsPTLYB+ERlKEJjTOSFvmZRKUECtHkpXVO5KzbRRi19e Cc: Netconf Subject: Re: [Netconf] XMPP as transport X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 22:06:15 -0000 On Wed, Jul 3, 2013 at 1:16 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ahoj. ;-) David Harrington alerted me to this discussion (as author of > RFC 6120 etc.), so I've joined the list. > > On 7/3/13 11:57 AM, Ladislav Lhotka wrote: >> >> On Jul 3, 2013, at 7:36 PM, Andy Bierman >> wrote: >> >>> Hi, >>> >>> The "must therefore be mediated by one or more XMPP servers" >>> part doesn't sound too great. Perhaps somebody should implement >>> a prototype and compare the performance characteristics to >>> NETCONF/SSH or NETCONF/TLS for multi-client provisioning. Then >>> write an I-D explaining why we need another NETCONF transport, >>> and it should be XMPP. > > Pardon my ignorance of NETCONF, but it seems that even using ssh or > some other transport would require some form of mediation, no? It's > not as if NETCONF clients and servers talk to each other directly, do > they? A NETCONF client connects directly to a NETCONF server. A common implementation strategy for SSH is to use OpenSSH and have the NETCONF server be invoked as a subsystem. The subsystem has to be a local executable, but I suppose that could in turn open a new back-end connection to a remote server. I'm still not clear why I would want to tear out old code and put in new code. Reverse SSH seems to be a reasonable incremental cost for NETCONF. Andy > >> Yes, that's my plan, unless somebody convinces me that it's a >> nonsense. > > I would be willing to at least advise you in that work. > >> It may be more effective than bending ssh and facing the opposition >> of ssh and security folks. > > I have no opinion there. > >> Performance-wise, I don't think a XMPP server could be a >> bottleneck. > > There are several XMPP server implementations that have been tested up > to 100,000 concurrent sessions and beyond. I don't think this should > be a problem for NETCONF. > >> Of course, it's an extra box to care about. > > Well, the xmpp daemon could be co-located with the NETCONF server (I'm > not clear on the usual deployment scenarios for NETCONF). > >>> On Wed, Jul 3, 2013 at 9:33 AM, Ladislav Lhotka >>> wrote: >>>> >>>> On Jul 3, 2013, at 4:30 PM, "ietfdbh" >>>> wrote: >>>> >>>>> Hi Lada, >>>>> >>>>> I would be interested in your analysis of how XMPP does/does >>>>> not meet the rfc6241 requirements for transport. > > I will endeavor to read RFC 6241 before long. But it might not happen > until after IETF 87. > >>>> XMPP streams are secure and authenticated, typically via TLS & >>>> SASL. However, the endpoints of each stream are a XMPP server >>>> and client, so the messaging between NETCONF client and server >>>> must therefore be mediated by one or more XMPP servers, and >>>> the NETCONF parties must trust those XMPP servers. >>>> >>>> NETCONF usernames can be derived either from JID, or just from >>>> its local part. >>>> >>>> The "iq" stanza can be used for wrapping NETCONF RPC requests >>>> and replies, and "message" for notifications. An XMPP server >>>> must ensure in-order processing of the stanzas from a connected >>>> client (sec. 10.1 in RFC 6120). > > That's all correct. > >>>>> For example, can Netconf reliably determine if a connection >>>>> is terminated, so it knows to release locks? >>>> >>>> It could be done using the same mechanism that Jabber clients >>>> use for determining the presence of their peers. > > Or, if the NETCONF server is integrated with the XMPP server properly, > it might have that knowledge based on the status of connections from > clients. This, for example, is how folks are using XMPP in the > SmartGrid space (see the spec for OpenADR 2.0). > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJR1IaJAAoJEOoGpJErxa2pLEEP/2N2UXW/ho6HM//fPi0pu172 > MVFE6dyKbZuzw1awn4Oc1Gf6XnQvNtkRjwbMHBj59c3oyqI4RhLvBel/qT7oDNMh > jLCKdwhyi4LuZsHlb2qV8qDQnUsTxRIW2MMAb9HLG92KKNxMogRd9DBJWWBY3udE > BUIq4nUCfIZSUWXBPigNH9TMPw7IO/UQJh67oyVWTeVU0dLdP9eTvWvElb7aA5vD > djYAWAcVTw+w0JTBnIJfHuXQK0IwubxPS1oND6DM03V6o1oXnyiLKg8WSsEcQ+8B > tWliRyYNH3qo+8M/EnzM7tV8MTCnzCwcxLxiO9vi+xV0HfbOoEjCUTTA49Nk2zui > Jhi7Knof/R5FKNZk+p6xC8c7K/uqrURz0YzeVEj8N35SkPTw0/5gx9iZLDGwgRPK > uunLy6tBdlDg20q2ly8tkeeeR73v9Ny4mGjnKCds6zgAoQTk3YGaxAva77Uu9yls > jG4RhKH5dX26WVpDN5AWoQv1FuVYWn1LaBdC02ucnkr88y+AZyxkvGuPIE2ZwGGp > D7uSr4nAJzKYt1jVfGtc3aUSPfLQVv/bvE2inGPF9S3AfKdKtnNYAdk6JaRCClT8 > /XIIPnjUnHtsyMlbVyoXhqBRwMO6/StG7FzSZCCJ8M/E1szM2Lt7p5qI+rWkm12y > gQx9QqjybIAlPgeZdqkz > =uFhG > -----END PGP SIGNATURE----- From lhotka@nic.cz Thu Jul 4 00:18:05 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E77B21F9F25 for ; Thu, 4 Jul 2013 00:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icP1YIvl7+FH for ; Thu, 4 Jul 2013 00:18:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE3421F9F1C for ; Thu, 4 Jul 2013 00:18:04 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6D99F13F8B3; Thu, 4 Jul 2013 09:18:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1372922283; bh=sHhs45lkb/aGxObkHK8T/mAzWO+VNEWP9sfWOAsen0s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Zn2z+Sm5KTFrOFeyp3jU3IG6b1wZZOEVYpCG62A1petcGPcxRgkNv0Z1SeLmkR/NS KjF6+KKW/m88HZReBCHGd0vZUp2RrAZMC0zUtIhDGd+ttxnppfJOBn3yYoTw/RHZdz pnYOvjGtoosaLtj/qbjp3pqca/4ZB9DzS1sze8QA= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <51D4868A.6020408@stpeter.im> Date: Thu, 4 Jul 2013 09:18:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <006b01ce77f9$dc933500$95b99f00$@comcast.net> <2D2F00CD-A567-4AC2-8636-5F21023E6558@nic.cz> <51D4868A.6020408@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] XMPP as transport X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 07:18:05 -0000 Ahoj Peter! Thank you for your support, please see my comment inline. On Jul 3, 2013, at 10:16 PM, Peter Saint-Andre = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Ahoj. ;-) David Harrington alerted me to this discussion (as author of > RFC 6120 etc.), so I've joined the list. >=20 > On 7/3/13 11:57 AM, Ladislav Lhotka wrote: >>=20 >> On Jul 3, 2013, at 7:36 PM, Andy Bierman >> wrote: >>=20 >>> Hi, >>>=20 >>> The "must therefore be mediated by one or more XMPP servers" >>> part doesn't sound too great. Perhaps somebody should implement >>> a prototype and compare the performance characteristics to=20 >>> NETCONF/SSH or NETCONF/TLS for multi-client provisioning. Then=20 >>> write an I-D explaining why we need another NETCONF transport, >>> and it should be XMPP. >=20 > Pardon my ignorance of NETCONF, but it seems that even using ssh or > some other transport would require some form of mediation, no? It's > not as if NETCONF clients and servers talk to each other directly, do > they? NETCONF essentially assumes a TCP connection between the client and = server, with additional goodies. I think the security context is also = different. >=20 >> Yes, that's my plan, unless somebody convinces me that it's a=20 >> nonsense. >=20 > I would be willing to at least advise you in that work. Great, thanks! >=20 >> It may be more effective than bending ssh and facing the opposition >> of ssh and security folks. >=20 > I have no opinion there. In any case, this way of using XMPP seems very natural, and most = security-related issues are already handled by XMPP. Actually, XEPs = 0323-0326 describe a very similar approach for "Internet of Things". >=20 >> Performance-wise, I don't think a XMPP server could be a >> bottleneck. >=20 > There are several XMPP server implementations that have been tested up > to 100,000 concurrent sessions and beyond. I don't think this should > be a problem for NETCONF. >=20 >> Of course, it's an extra box to care about. >=20 > Well, the xmpp daemon could be co-located with the NETCONF server (I'm > not clear on the usual deployment scenarios for NETCONF). In NETCONF terminology, server is the networking device that is being = configured. This can be a big iron, such as a router, where running an = XMPP server might be an option. But quite often, NETCONF servers run on = constrained boxes where this might be difficult. Such devices could = actually benefit from having an XMPP server as an external proxy that = performs authentication of clients, and can also be a well-known = destination for calling home. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From balazs.lengyel@ericsson.com Thu Jul 4 08:42:11 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9165021F9E83 for ; Thu, 4 Jul 2013 08:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvQry3ISW8XE for ; Thu, 4 Jul 2013 08:42:06 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC5021F9E72 for ; Thu, 4 Jul 2013 08:42:05 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-28-51d597cc3922 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7B.B9.05990.CC795D15; Thu, 4 Jul 2013 17:42:05 +0200 (CEST) Received: from [159.107.197.195] (153.88.183.16) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.2.328.9; Thu, 4 Jul 2013 17:42:04 +0200 Message-ID: <51D597CB.80201@ericsson.com> Date: Thu, 4 Jul 2013 17:42:03 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvre7Z6VcDDXr3M1t8uHOFxWLqptus DkweS5b8ZPL4uf4qewBTFJdNSmpOZllqkb5dAlfGzbYzbAU9ghU3r/awNTCe5u1i5OSQEDCR WH3mGzuELSZx4d56ti5GLg4hgcOMEiuvNLBAOKsZJX5/6WEGqeIV0JQ4cKUNzGYRUJG4Of03 C4jNJmAkMbX/PJgtKhAl0do7FapeUOLkzCdgcRGBVImPT5rZQGxhAW+JCRtPMUMs6GeUmPQA IsEp4CfRs/c3mM0sYCtxYc51FghbXmL72zlgQ4UENCQeXvjLOoFRYBaSHbOQtMxC0rKAkXkV I3tuYmZOernRJkZg+B3c8lt1B+OdcyKHGKU5WJTEeTfrnQkUEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwMjocuqSckLv3XWLDBaUrTORr939RNBrqvbmKcpTZk6OWX8sRcNrbrhOTHPj0fkb nPwefN+6WGH/kzUOASF956V4ZIQDZOo9J0kX7JvXJu0TpPVS/5DeNZsG14LipyyXX85+Z/vn 9IpHvKW+t2q+/GB3Ktjge+6FfEbyvhqROj4WpZKjurzzmJVYijMSDbWYi4oTAa2CY80NAgAA Subject: Re: [Netconf] Agenda Preparation for the Netconf Session in Berlin X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 15:42:11 -0000 Hello Mehmet, The get2 draft would be interesting. News about any other groups using Netconf would also be interesting. (IRS, other IETF workgroups, any outside industry groups, uptake of Netconf by OSS vendors) regards Balazs On 2013-07-01 12:59, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear All, > > we would like to poll the WG opinion on the priority of open issues and possible agenda items. > > The two chartered items will for sure have their discussion, where the Reverse SSH slot will be most likely attended by the SSH/SAAG people. > > Some time ago we discussed different topics and their priorities (http://www.ietf.org/mail-archive/web/netconf/current/msg08044.html). For IETF #87 we asked for a Netconf session on a later day of the week to enable adhoc discussions and consolidate the different views. > > Which topics do you see as important and should be discussed in the Netconf session? > Would a side meeting e.g. on Monday be useful to prepare a possible way forward? > > Mehmet & Bert > > >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext >> Ersue, Mehmet (NSN - DE/Munich) >> Sent: Friday, June 28, 2013 6:16 PM >> To: netconf@ietf.org >> Subject: [Netconf] netconf - Requested session has been scheduled for IETF 87 >> >> Hi All, >> >> the Netconf sessions have been scheduled as shown below: >> >> netconf Session 1+2 (2:00:00) >> >> Wednesday, Afternoon Session III 1620-1720 >> Room Name: Charlottenburg 1 >> >> Wednesday, Afternoon Session III 1620-1720 >> Room Name: Charlottenburg 1 >> >> Cheers, >> Mehmet >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From andy@yumaworks.com Sat Jul 6 09:26:47 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F5221F9C5E for ; Sat, 6 Jul 2013 09:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.84 X-Spam-Level: X-Spam-Status: No, score=-2.84 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iLntEs5gfaH for ; Sat, 6 Jul 2013 09:26:42 -0700 (PDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1A121F9B94 for ; Sat, 6 Jul 2013 09:26:41 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so2999737pbb.33 for ; Sat, 06 Jul 2013 09:26:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=MjHkr1/pdohLzQ86O8uEcPSAe9kE4rfPspxi2uKVchk=; b=nP+0MBlqD5pPPgTjUQlirZY56OADNeUx8u5gVgyEZY9iy++BgziIFsJ/4EAAkJdveC MBgFQEb/I6xs4o0A2dHaV5Nu3E1d67ZEveBsXR0mE2yxnNV75ojzc2XhRI84QiToDOCV b3C8GKtVsR+jQA7/+PfF1crhwHuuqqdoLnT1muS0T8xd29feFS5tM+QBG+S6qGkbvvy3 drrt0plpz2/YERwAlrcRj7UIwsDfm9MhA30QC6uZ+MngcjYpxWRTFBPgBvSJg7Rs74uJ hOg5qmTKxIZQV4utz3g6J7Ya5V3nKDjtE7iMjbeDvWeR7D5f9DpiZYs0iEu8FOtuicrl IAmQ== MIME-Version: 1.0 X-Received: by 10.66.149.40 with SMTP id tx8mr16072611pab.38.1373128001739; Sat, 06 Jul 2013 09:26:41 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Sat, 6 Jul 2013 09:26:41 -0700 (PDT) Date: Sat, 6 Jul 2013 09:26:41 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQme+0wfgwg5vEWsh+4EINp1aV91+wws8zu2laVZX1RwzMW1lPjDXrwBLiuBPnjAZIR7g9B2 Subject: [Netconf] standard YANG RFC publication (was 5539bis comments) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 16:26:47 -0000 Hi, Martin cited this text from the 5539bis-03 draft: If new definitions need to be added to the NETCONF configuration data model, either an existing YANG submodule can be updated or a new YANG submodule can be written. In both cases, the new document will carry an updated version of the "ietf-netconf-config" module importing the submodules. And had this comment: So, if you add a new submodule, you would update the ietf-netconf-config module, but not NETCONF over TLS. This publication procedure is at best under-specified and at worst, completely unworkable. IMO there MUST be at most 1 RFC containing the current revision of the ietf-netconf-config module. This proposal seems to obsolete the previous ietf-netconf-config module, but not the sub-modules that were published in each RFC. So let's walk through an example of how this publication procedure works from an RFC Editor POV. Time-0) first module - RFC 5539bis is published with revision 2013-xx-xx of ietf-netconf-config. - Obsoletes: RFC 5539 Time-1) add new submodule to configure some other feature (e.g. multiple candidates) as RFC XXXX. - the main module must maintain the most current normative reference for each submodule that is included. - the new main module revision is 2014-xx-xx. At this point the main module in RFC 5539bis is obsolete, but not the submodules. RFC XXXX has a normative reference to RFC5539bis. - Updates: RFC 5539bis (cannot be Obsoletes because of the submodules) Each time any change in any submodule is needed, the new RFC becomes the latest ietf-netconf-config home, with the latest revision. Every normative reference from every include-stmt in the main module is a normative reference for each newest RFC. IMO, this is a really bad idea. The goal of modular data modeling is to prevent a spaghetti bowl of dependencies. Every time 1 submodule is changed, the entire module revision is updated. There are no submodule revisions advertised in the NETCONF message, and the 'schema' list from ietf-netconf-monitoring is optional to implement. Therefore there is no reliable mechanism for an NMS developer to use to identify submodule revisions. This kitchen-sink approach is bad for modular version management. I want to understand how well this RFC publication process is going to work for the next 10 years. The purpose of using submodules is to avoid "the high cost of using an XML namespace". IMO the RFC publication issues are far worse than the message overhead incurred by using an additional namespace. The solution is worse than the original problem. Andy From j.schoenwaelder@jacobs-university.de Sat Jul 6 11:43:24 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0339721F9B8E for ; Sat, 6 Jul 2013 11:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.032 X-Spam-Level: X-Spam-Status: No, score=-103.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqQoMkmQAQ9h for ; Sat, 6 Jul 2013 11:43:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 872C421F9A23 for ; Sat, 6 Jul 2013 11:43:17 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 68E2A20BF0; Sat, 6 Jul 2013 20:43:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id EVNr9Ayg6evo; Sat, 6 Jul 2013 20:43:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E9A120BEB; Sat, 6 Jul 2013 20:43:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D21872729BF7; Sat, 6 Jul 2013 20:43:12 +0200 (CEST) Date: Sat, 6 Jul 2013 20:43:12 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130706184312.GA51144@elstar.local> Mail-Followup-To: Andy Bierman , Netconf References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] standard YANG RFC publication (was 5539bis comments) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 18:43:24 -0000 On Sat, Jul 06, 2013 at 09:26:41AM -0700, Andy Bierman wrote: > So let's walk through an example of how this publication procedure > works from an RFC Editor POV. > > Time-0) first module > - RFC 5539bis is published with revision 2013-xx-xx of > ietf-netconf-config. > - Obsoletes: RFC 5539 > > Time-1) add new submodule to configure some other feature > (e.g. multiple candidates) as RFC XXXX. > - the main module must maintain the most current normative reference > for each submodule that is included. > - the new main module revision is 2014-xx-xx. At this point the > main module > in RFC 5539bis is obsolete, but not the submodules. RFC XXXX > has a normative > reference to RFC5539bis. > - Updates: RFC 5539bis (cannot be Obsoletes because of the submodules) > > Each time any change in any submodule is needed, the new RFC becomes > the latest ietf-netconf-config home, with the latest revision. Every normative > reference from every include-stmt in the main module is a normative reference > for each newest RFC. IMO, this is a really bad idea. The goal of > modular data modeling is to prevent a spaghetti bowl of dependencies. Lets say MvX is a module at revision X and S1, S2, ... are submodules and lets assume the worst case (each submodule is published as a separate RFC). This leads to: | RFC | Content | Comment | |-------+-----------+---------------| | RFC_1 | (Mv1, S1) | | | RFC_2 | (Mv2, S2) | updates RFC_1 | | RFC_3 | (Mv3, S3) | updates RFC_2 | | ... | ... | ... | > Every time 1 submodule is changed, the entire module revision is updated. Yes. > There are no submodule revisions advertised in the NETCONF message, > and the 'schema' list from ietf-netconf-monitoring is optional to implement. > Therefore there is no reliable mechanism for an NMS developer to use to > identify submodule revisions. This kitchen-sink approach is bad for > modular version management. The module uses include by revision. In fact, I think for an NMS developer, this is essentially the same as if there would have been only a flat module with stuff added at each revision. > I want to understand how well this RFC publication process is going > to work for the next 10 years. The purpose of using submodules is > to avoid "the high cost of using an XML namespace". IMO the RFC > publication issues are far worse than the message overhead incurred > by using an additional namespace. The solution is worse than the > original problem. Like with many things in life there are trade-offs and judgements may differ as well. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Sat Jul 6 13:09:42 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110C321F99D0 for ; Sat, 6 Jul 2013 13:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oErjAdJw2pP3 for ; Sat, 6 Jul 2013 13:09:37 -0700 (PDT) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id DDF2B21F99C6 for ; Sat, 6 Jul 2013 13:09:36 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz11so3133437pad.2 for ; Sat, 06 Jul 2013 13:09:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=gxxlI11IsubX943TypOsLH+R5pu9f2QAZHPEtysyYao=; b=f7Tffxjsfeg//Li0GR8NZsHQjdhSbqfK9lRx24+ZxZaM/eADczxTQNi13n8GE8Apiw 2OmAjbqdaAjqbHzE84gfSdkicOXGYzCIaKMQ6vLEsmzeVAxwgGE1HHxs1gTrifP1lwvv 00aMTaunE1fQE/s/YpcvsdwMGoUxjMntw+KttUUziFaH0jGQ9nDn7u4o4oXmZxPazBJ9 Y1CG3LIUdAKqPCvEIs1iyGaEtEr6Sv9WwXWZDFQC69g/HNNIQorIIFDGDAzu9WSZ8qxK dMxj1gaTow4vOamzhbrhCzr8DaDBOSbPKN/+Tbbu8XbyyJEj2ullokXC52m+xkhzv2ws HROQ== MIME-Version: 1.0 X-Received: by 10.66.232.101 with SMTP id tn5mr16422959pac.132.1373141376348; Sat, 06 Jul 2013 13:09:36 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Sat, 6 Jul 2013 13:09:36 -0700 (PDT) In-Reply-To: <20130706184312.GA51144@elstar.local> References: <20130706184312.GA51144@elstar.local> Date: Sat, 6 Jul 2013 13:09:36 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Netconf Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkdVb10EnUFZXt4xd2U6y/79zONedqUpi97a9IXPL/SBwRWrNJPDJFToi69yPT3FuIY5Aww Subject: Re: [Netconf] standard YANG RFC publication (was 5539bis comments) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 20:09:42 -0000 ... >> Each time any change in any submodule is needed, the new RFC becomes >> the latest ietf-netconf-config home, with the latest revision. Every normative >> reference from every include-stmt in the main module is a normative reference >> for each newest RFC. IMO, this is a really bad idea. The goal of >> modular data modeling is to prevent a spaghetti bowl of dependencies. > > Lets say MvX is a module at revision X and S1, S2, ... are submodules > and lets assume the worst case (each submodule is published as a > separate RFC). This leads to: > > | RFC | Content | Comment | > |-------+-----------+---------------| > | RFC_1 | (Mv1, S1) | | > | RFC_2 | (Mv2, S2) | updates RFC_1 | > | RFC_3 | (Mv3, S3) | updates RFC_2 | Each RFC_n contains Mv[n], which includes S[1] .. S[n-1], so there are normative references for RFC_1 .. RFC_n-1. I think the use of submodules in ietf-netconf-snmp is fine because there is strong cohesion between the submodules. In this case ietf-netconf-config exhibits weak cohesion (anything config=true related to the NETCONF protocol). Using one giant module and "if-feature submodule-A' seems complicated. YANG modules naturally provide that level of granularity for independent software features. If we had started out this way, then that would be different. Since we didn't, most NETCONF config will not be under /netconf. How does this scale to the rest of the IETF? If the IETF standardizes 8 or 10 different routing related YANG modules, where will these modules be rooted? Under /routing from ietf-routing.yang? Under the WG name? (e.g., /i2rs/???). Whatever top-level node they want? Let's say it is ietf-routing. Do these WGs need to republish the ietf-routing RFC and add their submodule include (so their RFC becomes the new home of /ietf-routing)? IMO it is much more stable and clean to just augment /ietf-routing from a different RFC because it does not require any republication of the augmented module. I think the same approach works best for the /netconf container as well. I suspect future RFCs will just augment this container and not bother with more sub-modules. > | ... | ... | ... | >... > /js > Andy From j.schoenwaelder@jacobs-university.de Sat Jul 6 13:22:42 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EC221F9B60 for ; Sat, 6 Jul 2013 13:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.763 X-Spam-Level: X-Spam-Status: No, score=-102.763 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iayw4KzjyvAS for ; Sat, 6 Jul 2013 13:22:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2AC21F9BC1 for ; Sat, 6 Jul 2013 13:22:28 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21C2020BEB; Sat, 6 Jul 2013 22:22:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WJFH9yRiIEl9; Sat, 6 Jul 2013 22:22:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3CA320AFA; Sat, 6 Jul 2013 22:22:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1E3C52729DE0; Sat, 6 Jul 2013 22:22:26 +0200 (CEST) Date: Sat, 6 Jul 2013 22:22:26 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130706202225.GA51435@elstar.local> Mail-Followup-To: Andy Bierman , Netconf References: <20130706184312.GA51144@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] standard YANG RFC publication (was 5539bis comments) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 20:22:43 -0000 On Sat, Jul 06, 2013 at 01:09:36PM -0700, Andy Bierman wrote: > Each RFC_n contains Mv[n], which includes S[1] .. S[n-1], > so there are normative references for RFC_1 .. RFC_n-1. Yep. > I think the use of submodules in ietf-netconf-snmp is fine because there is > strong cohesion between the submodules. In this case ietf-netconf-config > exhibits weak cohesion (anything config=true related to the NETCONF protocol). ietf-netmod-snmp anything config=true related to the SNMP protocol ietf-netconf-config anything config=true related to the NETCONF protocol > Using one giant module and "if-feature submodule-A' seems complicated. > YANG modules naturally provide that level of granularity for independent > software features. Not sure what is easier: Only having to deal with features or having to deal with a combination of modules and features. > If we had started out this way, then that would be different. > Since we didn't, most NETCONF config will not be under /netconf. Except nacm, there is no standardized NETCONF config. > How does this scale to the rest of the IETF? > If the IETF standardizes 8 or 10 different routing related YANG modules, > where will these modules be rooted? Under /routing from ietf-routing.yang? > Under the WG name? (e.g., /i2rs/???). Whatever top-level node they want? > > Let's say it is ietf-routing. > Do these WGs need to republish the ietf-routing RFC and add their > submodule include (so their RFC becomes the new home of /ietf-routing)? I assume routing will have routing technology specific data models, e.g. a config model for BGP, OSPF, ... These might consist of submodules. > IMO it is much more stable and clean to just augment /ietf-routing > from a different RFC because it does not require any republication > of the augmented module. I think the same approach works best > for the /netconf container as well. I suspect future RFCs will just > augment this container and not bother with more sub-modules. I think you are comparing apples with oranges (but you will not subscribe to that view). The generic routing infrastructure has been designed to be augmented since the generic model provides the glue between different technology specific routing config models. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Sat Jul 6 13:44:23 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236ED21F99E9 for ; Sat, 6 Jul 2013 13:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqdrbYRf9Qyk for ; Sat, 6 Jul 2013 13:44:18 -0700 (PDT) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id C2C7C21F9923 for ; Sat, 6 Jul 2013 13:44:18 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id t12so2887427pdi.35 for ; Sat, 06 Jul 2013 13:44:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=qukpQqZSKxYL6nkjryNpg9VI1YAHuxtWVTIvGQQ1RRU=; b=QzFAp+zAGwb7hkG7GSNewWDsUkVZ6cxLqaChLWFMaKLwDSTmJF21sURosMakyosBf2 hSYELy0YkqFiIMbYwfx9PW4ciP87CJA5t8BgOeHW1OdROxEE3GwbdxdS/1fljkUBzZKT MZAElVkn+8LCRoJQ7czdI4rs/4hMnxZA9mHqFK/zker0WpK3DJqQkAdtkfABpe623QJk NCsn+WlJFMNmPzAjjycGK4wnwHoVwpnCwf7TvV5n5UsTXxx6IfiDMqM89ihmAQRUrFoW VqROG+OanZHMExt5t71DwvOkoFXgOsl/JMsXclknZf1+iJTyTad0RQu9W4EeWEWqwwY+ /D0A== MIME-Version: 1.0 X-Received: by 10.68.35.131 with SMTP id h3mr14908526pbj.140.1373143456376; Sat, 06 Jul 2013 13:44:16 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Sat, 6 Jul 2013 13:44:16 -0700 (PDT) In-Reply-To: <20130706202225.GA51435@elstar.local> References: <20130706184312.GA51144@elstar.local> <20130706202225.GA51435@elstar.local> Date: Sat, 6 Jul 2013 13:44:16 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Netconf Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkM9rNZ/uXyqnwXS8ABe2dAlGOT9jiYL/kDxLjzVT+UIHHLKf+5aOB9ZgsIX1cEGbLh0wgk Subject: Re: [Netconf] standard YANG RFC publication (was 5539bis comments) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 20:44:23 -0000 Hi, I don't mind the /netconf container. The disagreement is really over sub-modules vs. augment. IMO, augment is cleaner because the extended RFC does not have to be re-published, and the has the revision date. Andy On Sat, Jul 6, 2013 at 1:22 PM, Juergen Schoenwaelder wrote: > On Sat, Jul 06, 2013 at 01:09:36PM -0700, Andy Bierman wrote: > >> Each RFC_n contains Mv[n], which includes S[1] .. S[n-1], >> so there are normative references for RFC_1 .. RFC_n-1. > > Yep. > >> I think the use of submodules in ietf-netconf-snmp is fine because there is >> strong cohesion between the submodules. In this case ietf-netconf-config >> exhibits weak cohesion (anything config=true related to the NETCONF protocol). > > ietf-netmod-snmp anything config=true related to the SNMP protocol > ietf-netconf-config anything config=true related to the NETCONF protocol > >> Using one giant module and "if-feature submodule-A' seems complicated. >> YANG modules naturally provide that level of granularity for independent >> software features. > > Not sure what is easier: Only having to deal with features or having > to deal with a combination of modules and features. > >> If we had started out this way, then that would be different. >> Since we didn't, most NETCONF config will not be under /netconf. > > Except nacm, there is no standardized NETCONF config. > >> How does this scale to the rest of the IETF? >> If the IETF standardizes 8 or 10 different routing related YANG modules, >> where will these modules be rooted? Under /routing from ietf-routing.yang? >> Under the WG name? (e.g., /i2rs/???). Whatever top-level node they want? >> >> Let's say it is ietf-routing. >> Do these WGs need to republish the ietf-routing RFC and add their >> submodule include (so their RFC becomes the new home of /ietf-routing)? > > I assume routing will have routing technology specific data models, > e.g. a config model for BGP, OSPF, ... These might consist of > submodules. > >> IMO it is much more stable and clean to just augment /ietf-routing >> from a different RFC because it does not require any republication >> of the augmented module. I think the same approach works best >> for the /netconf container as well. I suspect future RFCs will just >> augment this container and not bother with more sub-modules. > > I think you are comparing apples with oranges (but you will not > subscribe to that view). The generic routing infrastructure has been > designed to be augmented since the generic model provides the glue > between different technology specific routing config models. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From andy@yumaworks.com Sun Jul 7 09:01:56 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805C121F9C2C for ; Sun, 7 Jul 2013 09:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CccG3bNyx2rm for ; Sun, 7 Jul 2013 09:01:51 -0700 (PDT) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4786121F9B86 for ; Sun, 7 Jul 2013 09:01:51 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id p10so3285388pdj.36 for ; Sun, 07 Jul 2013 09:01:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding:x-gm-message-state; bh=vdq0il1dDgbqEMKCL98yMGKtloifgTS/YRTx3F3ywKo=; b=kRyXEYTr+O7tt2Qft68odmvQYGs3ch3ZygeXHse2V4s/RTHOiSK7wDSc6i/LXSzTVB jp0ErN5KfF8SqhLO4R7/w7/7eyFzmGafdR1Fhudw9rxhjQBkKQsknSUpHCq1D31Y8FPK WSnrakbM1Jk+S18XARrX8xdC2h6BMZ5eLQ2BPwdqdGQaev7LLO3vlR1VoWLByzO96Y6Y 2dBZe7YFyDNXcjc+4+6ED/3o3wyWbQpVFQdISSBnUdSw9gAwu2xjqvaZ6zMptF2i5B4A 03wAk6DfWtgFfUwpMXtp2SGPE/K72VtzEk3rFbfFdcUdj5J0L8erPzI490yucXt6nSnw yERA== MIME-Version: 1.0 X-Received: by 10.68.35.131 with SMTP id h3mr17696518pbj.140.1373212906141; Sun, 07 Jul 2013 09:01:46 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Sun, 7 Jul 2013 09:01:46 -0700 (PDT) Date: Sun, 7 Jul 2013 09:01:46 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlO85WnSC7J7ii4BuAx2JQxops7pJzYzEtN+CYsNWJDomHTsI1VcNA0DNKF7C4Svl0+PC2s Subject: [Netconf] Are namespaces required for extra attributes? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 16:01:56 -0000 Hi, According to my interpretation of the text and XSD in RFC 6241, and the XSD definition of 'anyAttribute' and 'processContents', the client is allowed to send extra attributes in the element even if the namespaces are not used: Is this interpretation correct? Either way the next NETCONF update should clarify this detail in sec. 4.1. RFC 6241:, sec 4.1, para 3: If additional attributes are present in an element, a NETCONF peer MUST return them unmodified in the element. This includes any "xmlns" attributes. RFC 6241, XSD, page 81: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#process_= contents lax: If the item has a uniquely determined declaration available, it must be =B7valid=B7 with respect to that definition, that is, =B7validate=B7 if you can, don't worry if you can't. Andy From lhotka@nic.cz Mon Jul 8 00:10:18 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA1D11E8190 for ; Mon, 8 Jul 2013 00:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.946 X-Spam-Level: X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfk5AzpwiQAO for ; Mon, 8 Jul 2013 00:10:14 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id D4E2211E8193 for ; Mon, 8 Jul 2013 00:10:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 2ADF8540200; Mon, 8 Jul 2013 09:10:03 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmWrgfJNNxN1; Mon, 8 Jul 2013 09:09:55 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 49C44540198; Mon, 8 Jul 2013 09:09:50 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Juergen Schoenwaelder , Andy Bierman , Netconf In-Reply-To: References: <20130706184312.GA51144@elstar.local> <20130706202225.GA51435@elstar.local> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Date: Mon, 08 Jul 2013 09:09:49 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Netconf] standard YANG RFC publication (was 5539bis comments) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 07:10:18 -0000 Andy Bierman writes: > Hi, > > I don't mind the /netconf container. > The disagreement is really over sub-modules vs. augment. > IMO, augment is cleaner because the extended RFC does > not have to be re-published, and the has the revision date. +1. Lada > > > Andy > > > > On Sat, Jul 6, 2013 at 1:22 PM, Juergen Schoenwaelder > wrote: >> On Sat, Jul 06, 2013 at 01:09:36PM -0700, Andy Bierman wrote: >> >>> Each RFC_n contains Mv[n], which includes S[1] .. S[n-1], >>> so there are normative references for RFC_1 .. RFC_n-1. >> >> Yep. >> >>> I think the use of submodules in ietf-netconf-snmp is fine because there is >>> strong cohesion between the submodules. In this case ietf-netconf-config >>> exhibits weak cohesion (anything config=true related to the NETCONF protocol). >> >> ietf-netmod-snmp anything config=true related to the SNMP protocol >> ietf-netconf-config anything config=true related to the NETCONF protocol >> >>> Using one giant module and "if-feature submodule-A' seems complicated. >>> YANG modules naturally provide that level of granularity for independent >>> software features. >> >> Not sure what is easier: Only having to deal with features or having >> to deal with a combination of modules and features. >> >>> If we had started out this way, then that would be different. >>> Since we didn't, most NETCONF config will not be under /netconf. >> >> Except nacm, there is no standardized NETCONF config. >> >>> How does this scale to the rest of the IETF? >>> If the IETF standardizes 8 or 10 different routing related YANG modules, >>> where will these modules be rooted? Under /routing from ietf-routing.yang? >>> Under the WG name? (e.g., /i2rs/???). Whatever top-level node they want? >>> >>> Let's say it is ietf-routing. >>> Do these WGs need to republish the ietf-routing RFC and add their >>> submodule include (so their RFC becomes the new home of /ietf-routing)? >> >> I assume routing will have routing technology specific data models, >> e.g. a config model for BGP, OSPF, ... These might consist of >> submodules. >> >>> IMO it is much more stable and clean to just augment /ietf-routing >>> from a different RFC because it does not require any republication >>> of the augmented module. I think the same approach works best >>> for the /netconf container as well. I suspect future RFCs will just >>> augment this container and not bother with more sub-modules. >> >> I think you are comparing apples with oranges (but you will not >> subscribe to that view). The generic routing infrastructure has been >> designed to be augmented since the generic model provides the glue >> between different technology specific routing config models. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From dew@tx.technion.ac.il Mon Jul 8 00:48:31 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA2C11E819D for ; Mon, 8 Jul 2013 00:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xj6V3PXJsOu9 for ; Mon, 8 Jul 2013 00:48:23 -0700 (PDT) Received: from mailgw13.technion.ac.il (mailgw13.technion.ac.il [132.68.225.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3639611E81A5 for ; Mon, 8 Jul 2013 00:48:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYXAMtm2lGERAEi/2dsb2JhbABagwkyTYMIqV6NLYZOgQ4WdIJNFUE1AiYCLohTDKdIiEiIBoEmjkUdgj6BHAOJH44zgSqOUIFPgxQ X-IronPort-AV: E=Sophos;i="4.87,1018,1363125600"; d="scan'208";a="78921441" Received: from webmail.technion.ac.il ([132.68.1.34]) by mailgw13.technion.ac.il with ESMTP; 08 Jul 2013 10:48:19 +0300 Received: by webmail.technion.ac.il (Postfix, from userid 48) id 6D796100107; Mon, 8 Jul 2013 10:48:18 +0300 (IDT) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by webmail.technion.ac.il (Horde Framework) with HTTP; Mon, 08 Jul 2013 10:48:18 +0300 Date: Mon, 08 Jul 2013 10:48:18 +0300 Message-ID: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> From: Tal Mizrahi To: netconf@ietf.org User-Agent: Internet Messaging Program (IMP) H5 (6.0.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: moses@ee.technion.ac.il Subject: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 07:48:31 -0000 Hi, We have submitted a new draft titled =E2=80=9CTime Capability in NETCONF=E2= =80=9D. http://tools.ietf.org/html/draft-mm-netconf-time-capability-00 Any comments will be welcome. Thanks, Tal Mizrahi. From jonathan@hansfords.net Mon Jul 8 03:23:20 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD96621F9DEB for ; Mon, 8 Jul 2013 03:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0a2fV7bwNri for ; Mon, 8 Jul 2013 03:23:15 -0700 (PDT) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id A06D021F9DC1 for ; Mon, 8 Jul 2013 03:23:13 -0700 (PDT) Received: from webmail.plus.net ([84.93.237.98]) by avasout04 with smtp id xmPB1l004283uBY01mPCnG; Mon, 08 Jul 2013 11:23:12 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=KrN0hwmN c=1 sm=1 tr=0 a=BJaFPv9AyABFDM2hXLRoEA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=lxldWUwtbAkA:10 a=dYCPD3cKDi0A:10 a=NcAD8sljVzcA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=Mt64Go7XSLcA:10 a=48vgC7mUAAAA:8 a=fsskktixqsxRzEWV2fAA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=JV55wDpii8bjlDr6nYcA:9 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Mon, 08 Jul 2013 11:23:11 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_5b25416c37781c1c1f0c936120852c2d" Date: Mon, 08 Jul 2013 11:23:11 +0100 From: Jonathan Hansford To: In-Reply-To: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> Message-ID: <0381995405c6459bd78d095ade79da7a@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 10:23:21 -0000 --=_5b25416c37781c1c1f0c936120852c2d Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Hi Tal, Like the idea of this capability. A couple of points on first reading: * p3, scheduled time: this is defined as "the time at which the RPC should be completed", however scheduling (p4) states "the server ... executes the RPC at the scheduled time". Though many (most?) RPCs may complete in a short period of time, wouldn't it be more appropriate to define the scheduled time as "the time at which the RPC should be executed"? As you state later, there are a number of factors that can impact on the time to complete. Though some may be predictable, allowing the server to estimate when to start execution, others will not be. * p9, 5.2: s/5.1. ,/5.1, * How would you see this working when supporting the configuration of a set of network elements in a robust and transaction-oriented way, where the operation should complete on all devices or be fully reversed? Jonathan On 2013-07-08 08:48, Tal Mizrahi wrote: > Hi, > > We have submitted a new draft titled "Time Capability in NETCONF". > http://tools.ietf.org/html/draft-mm-netconf-time-capability-00 > > Any comments will be welcome. > Thanks, > Tal Mizrahi. > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=_5b25416c37781c1c1f0c936120852c2d Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Tal,

Like the idea of this capability. A couple of points on first reading:

  • p3, scheduled time: this is defined as "the time at which the RPC shoul= d be completed", however scheduling (p4) states "the server ... executes th= e RPC at the scheduled time". Though many (most?) RPCs may complete in a sh= ort period of time, wouldn't it be more appropriate to define the scheduled= time as "the time at which the RPC should be executed"? As you state later= , there are a number of factors that can impact on the time to complete. Th= ough some may be predictable, allowing the server to estimate when to start= execution, others will not be.
  • p9, 5.2: s/5.1. ,/5.1,
  • How would you see this working when supporting the configuration of a s= et of network elements in a robust and transaction-oriented way, where the = operation should complete on all devices or be fully reversed?

Jonathan

On 2013-07-08 08:48, Tal Mizrahi wrote:

Hi,

We have submitted a new draft titled “Time Capability in NETCONF&rdqu=
o;.
=
http://tools.ietf.org/html/draft-mm-netconf-time-capability-00

Any comments will be welcome.
Thanks,
Tal Mizrahi.

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf=
=2Eorg/mailman/listinfo/netconf
--=_5b25416c37781c1c1f0c936120852c2d-- From j.schoenwaelder@jacobs-university.de Mon Jul 8 05:01:24 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8917321F9EC2 for ; Mon, 8 Jul 2013 05:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.049 X-Spam-Level: X-Spam-Status: No, score=-103.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id expswSmKQNQb for ; Mon, 8 Jul 2013 05:01:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C772421F935A for ; Mon, 8 Jul 2013 05:01:10 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C76BC20968; Mon, 8 Jul 2013 14:01:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FGcpjnKUhy9i; Mon, 8 Jul 2013 14:01:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 776352090B; Mon, 8 Jul 2013 14:01:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 19EFB272BEF9; Mon, 8 Jul 2013 14:01:04 +0200 (CEST) Date: Mon, 8 Jul 2013 14:01:04 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130708120104.GA55763@elstar.local> Mail-Followup-To: Andy Bierman , Netconf References: <20130706184312.GA51144@elstar.local> <20130706202225.GA51435@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] standard YANG RFC publication (was 5539bis comments) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 12:01:24 -0000 On Sat, Jul 06, 2013 at 01:44:16PM -0700, Andy Bierman wrote: > Hi, > > I don't mind the /netconf container. > The disagreement is really over sub-modules vs. augment. > IMO, augment is cleaner because the extended RFC does > not have to be re-published, and the has the revision date. > Let me at least clarify that * submodules do augment - see the examples * there is no need to republish an extended RFC, you republish the main module; a WG can of course at their discretion choose to republish everything * the updated module of course has a new revision date which is carried in the (and it uses import by revision) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Mon Jul 8 07:27:50 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775DD21F991E for ; Mon, 8 Jul 2013 07:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPJksSTgCQxT for ; Mon, 8 Jul 2013 07:27:46 -0700 (PDT) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) by ietfa.amsl.com (Postfix) with ESMTP id 65A3721F8F09 for ; Mon, 8 Jul 2013 07:27:46 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id p10so4107221pdj.8 for ; Mon, 08 Jul 2013 07:27:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=QMysdFXYYCWNii+8v2WMTYVJI02ddOCQ3kQ4lI70wv0=; b=Q63Div9Ja+Af6XSNNaN16RTSHYnLSTH/0rfGdmyynynicxX7Ykc5HV+jWVDW0M/nKu 94MzWkhGFZqX6t0KR0cWQyygtEYFsMSC/9UyJMw4yX5dcdsxguU1nKjjLqQJWOhm3OOy 6yfdBSF6AQawF1IHeCZ2iT6qKp4H14DHc8Rjf7Spq1u94lr/snA5XKS/hXf/ZSftXnwg cT3DuBGj7M1a3v6+2ka25DYCZNgwr1eZS1zWrO3HOueXEudtjhUgQVbEk/gpoW9tnZeO PE+PymgLA3AXBFFzqV8VniFKdJAuGlPu62vH6w1gfXKeK/MHfWJx6STkf0HwUVuBBw7a ObjA== MIME-Version: 1.0 X-Received: by 10.68.60.132 with SMTP id h4mr21596451pbr.177.1373293665817; Mon, 08 Jul 2013 07:27:45 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Mon, 8 Jul 2013 07:27:45 -0700 (PDT) In-Reply-To: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> Date: Mon, 8 Jul 2013 07:27:45 -0700 Message-ID: From: Andy Bierman To: Tal Mizrahi Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnkGH92Btbxnvew9w2vywUJsdjEZ6B65caoZkj86YotiVkP12Cod4mLeL0aTmqYDuS3/kNc Cc: netconf@ietf.org, moses@ee.technion.ac.il Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:27:50 -0000 Hi, I do not support a general time-scheduled protocol operation mechanism for all NETCONF operations. There is one interesting use-case mentioned: synchronized (or on :writable-running) operations across multiple servers. The proposal doesn't actually work within NETCONF because requests within a single session are serialized. This solution seems to send 1 when the operation is finally executed. How does the client know the opera= tion was scheduled successfully? IMO, a better solution would be an immediate (scheduled OK) and the execution results sent in a . How do clients monitor what operations are pending? What if the NACM rules change while the operation is pending? Does access control get checked twice? Clients should not be able to schedule operations they are not permitted to execute. What if a session is lost or closed before its scheduled operation is start= ed? What if the server reboots while operations are pending? IMO, YANG date-and-time is better time parameter than 'seconds since 1970'. It is already supported by NETCONF servers. How does a client cancel an operation? Can client A cancel operations for client B, assuming client A is allowed to invoke ? Andy On Mon, Jul 8, 2013 at 12:48 AM, Tal Mizrahi wrote: > Hi, > > We have submitted a new draft titled =93Time Capability in NETCONF=94. > http://tools.ietf.org/html/draft-mm-netconf-time-capability-00 > > Any comments will be welcome. > Thanks, > Tal Mizrahi. > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From dew@tx.technion.ac.il Mon Jul 8 14:24:38 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB4A21F9E08 for ; Mon, 8 Jul 2013 14:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8FaOmfVx9Kj for ; Mon, 8 Jul 2013 14:24:33 -0700 (PDT) Received: from mailgw13.technion.ac.il (mailgw13.technion.ac.il [132.68.225.13]) by ietfa.amsl.com (Postfix) with ESMTP id B7EE921F9DF1 for ; Mon, 8 Jul 2013 14:24:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAJAK8r21GERAEi/2dsb2JhbABZgwkyTYMIqXaUBIEZFnSCIwEBAQMBAQEBIBU2CwULCxgCAiYCAicFKwYTiAkGBAinZIkgiAaBJo4SMweCVIEcA4kfjjOBKo5QgU+DFA X-IronPort-AV: E=Sophos;i="4.87,1022,1363125600"; d="scan'208";a="79009536" Received: from webmail.technion.ac.il ([132.68.1.34]) by mailgw13.technion.ac.il with ESMTP; 09 Jul 2013 00:24:24 +0300 Received: by webmail.technion.ac.il (Postfix, from userid 48) id 1D597100107; Tue, 9 Jul 2013 00:24:24 +0300 (IDT) Received: from bzq-109-67-164-151.red.bezeqint.net (bzq-109-67-164-151.red.bezeqint.net [109.67.164.151]) by webmail.technion.ac.il (Horde Framework) with HTTP; Tue, 09 Jul 2013 00:24:24 +0300 Date: Tue, 09 Jul 2013 00:24:24 +0300 Message-ID: <20130709002424.Horde.XLv2jNWmimcLqrv5hZm0Ew7@webmail.technion.ac.il> From: Tal Mizrahi To: Jonathan Hansford References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <0381995405c6459bd78d095ade79da7a@imap.plus.net> In-Reply-To: <0381995405c6459bd78d095ade79da7a@imap.plus.net> User-Agent: Internet Messaging Program (IMP) H5 (6.0.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: netconf@ietf.org, "moses@ee.technion.ac.il" Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:24:38 -0000 Hi Jonathan, Thanks for your prompt comments. > * p3, scheduled time: this is defined as "the time at > which the RPC should be completed", however scheduling (p4) states "the > server ... executes the RPC at the scheduled time". Though many (most?) > RPCs may complete in a short period of time, wouldn't it be more > appropriate to define the scheduled time as "the time at which the RPC > should be executed"? As you state later, there are a number of factors > that can impact on the time to complete. Though some may be predictable, > allowing the server to estimate when to start execution, others will not > be. As you point out, while some RPCs complete in a short time, others may take a while. So if the RPC simply writes the value of a single leaf, its execution time may be negligible compared to the execution accuracy. However, if the RPC is, for example a operation, it may take a while. Hence, we tried to generally be clear and accurate in what we mean by =E2=80=9Cexecutes the RPC at the scheduled time=E2=80=9D= . I take your note that we need to make sure we are consistent in our phrasing. > * How would you see this working when > supporting the configuration of a set of network elements in a robust > and transaction-oriented way, where the operation should complete on all > devices or be fully reversed? The time capability we propose should work well in networks with a high degree of reliability, where you can benefit from a coordinated update at the (small) cost of (rare) failures. But your point is well taken, and similar points have also been raised by Andy in his comments from today, so we will consider it further. Thanks, Tal. Quoting Jonathan Hansford : > Hi Tal, > > Like the idea of this capability. A couple of points on > first reading: > > * p3, scheduled time: this is defined as "the time at > which the RPC should be completed", however scheduling (p4) states "the > server ... executes the RPC at the scheduled time". Though many (most?) > RPCs may complete in a short period of time, wouldn't it be more > appropriate to define the scheduled time as "the time at which the RPC > should be executed"? As you state later, there are a number of factors > that can impact on the time to complete. Though some may be predictable, > allowing the server to estimate when to start execution, others will not > be. > * p9, 5.2: s/5.1. ,/5.1, > * How would you see this working when > supporting the configuration of a set of network elements in a robust > and transaction-oriented way, where the operation should complete on all > devices or be fully reversed? > > Jonathan > > On 2013-07-08 08:48, Tal > Mizrahi wrote: > >> Hi, >> >> We have submitted a new draft titled "Time > Capability in NETCONF". >> > http://tools.ietf.org/html/draft-mm-netconf-time-capability-00 >> >> Any > comments will be welcome. >> Thanks, >> Tal Mizrahi. >> >> > _______________________________________________ >> Netconf mailing list >> > Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf From dew@tx.technion.ac.il Mon Jul 8 14:31:32 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9CA21F9BC3 for ; Mon, 8 Jul 2013 14:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNfDszerXXjA for ; Mon, 8 Jul 2013 14:31:16 -0700 (PDT) Received: from mailgw13.technion.ac.il (mailgw13.technion.ac.il [132.68.225.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8D81221F92BB for ; Mon, 8 Jul 2013 14:30:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEJAK8r21GERAEi/2dsb2JhbABZgwkyTYMIqXaUBIEZFnSCIwEBAQMBAQEBIBU2CwULCxgCAiYCAicFKwYTG4duBgQIp2SJIIgGgSaOEjMHglSBHAOJH44zgSqOUIFPgxQ X-IronPort-AV: E=Sophos;i="4.87,1022,1363125600"; d="scan'208";a="79009867" Received: from webmail.technion.ac.il ([132.68.1.34]) by mailgw13.technion.ac.il with ESMTP; 09 Jul 2013 00:30:47 +0300 Received: by webmail.technion.ac.il (Postfix, from userid 48) id 5FCFF100107; Tue, 9 Jul 2013 00:30:47 +0300 (IDT) Received: from bzq-109-67-164-151.red.bezeqint.net (bzq-109-67-164-151.red.bezeqint.net [109.67.164.151]) by webmail.technion.ac.il (Horde Framework) with HTTP; Tue, 09 Jul 2013 00:30:47 +0300 Date: Tue, 09 Jul 2013 00:30:47 +0300 Message-ID: <20130709003047.Horde.23QgiHPWhnmFavvNTQ0UYg1@webmail.technion.ac.il> From: Tal Mizrahi To: Andy Bierman References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.0.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: netconf@ietf.org, moses@ee.technion.ac.il Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:31:32 -0000 Hi Andy, We appreciate your comments. Most of your comments (although they end with a question mark :) ) are issues that have not been addressed in the current draft, and we take them as inputs to the next draft. > IMO, YANG date-and-time is better time parameter than 'seconds since 1970= '. Unfortunately, the IETF does not have a single standard way to represent time. The date-and-time format you refer to (RFC 3339) is one way to go, but it only allows a 10th of a second resolution (correct me if I am missing something), and we are hoping to allow significantly finer-grained coordination. The IETF also has other methods of representing time; RFC 6374 emphasizes this confusion by allowing two different ways to represent time: the NTP time format and the PTP time format. In this draft we propose the PTP time format. Thanks, Tal. Quoting Andy Bierman : > Hi, > > I do not support a general time-scheduled protocol operation mechanism fo= r > all NETCONF operations. There is one interesting use-case mentioned: > synchronized (or on :writable-running) operations > across multiple servers. > > The proposal doesn't actually work within NETCONF because requests > within a single session are serialized. This solution seems to send 1 > > when the operation is finally executed. How does the client know > the operation > was scheduled successfully? IMO, a better solution would be an immediate > (scheduled OK) and the execution results sent in a > . > > How do clients monitor what operations are pending? > > What if the NACM rules change while the operation is pending? > Does access control get checked twice? Clients should not be able > to schedule operations they are not permitted to execute. > > What if a session is lost or closed before its scheduled operation > is started? > > What if the server reboots while operations are pending? > > IMO, YANG date-and-time is better time parameter than 'seconds since 1970= '. > It is already supported by NETCONF servers. > > How does a client cancel an operation? > Can client A cancel operations for client B, > assuming client A is allowed to invoke ? > > > > Andy > > On Mon, Jul 8, 2013 at 12:48 AM, Tal Mizrahi wrot= e: >> Hi, >> >> We have submitted a new draft titled =E2=80=9CTime Capability in NETCONF= =E2=80=9D. >> http://tools.ietf.org/html/draft-mm-netconf-time-capability-00 >> >> Any comments will be welcome. >> Thanks, >> Tal Mizrahi. >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf From andy@yumaworks.com Mon Jul 8 15:38:10 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9A421F9E9A for ; Mon, 8 Jul 2013 15:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVFpYrPWV0RY for ; Mon, 8 Jul 2013 15:38:06 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id CCE0B21F9EAC for ; Mon, 8 Jul 2013 15:38:01 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id lj1so4837933pab.31 for ; Mon, 08 Jul 2013 15:38:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=AGXP3FT7h4vVYWHx19yM+2Z2vs8DvYf1QL75f6WQCm4=; b=n1piRCneFl/fKYDWB2mO0YNBy4IciCSQud0uHuyOgdDj81vCCTn3e5W6380hkb6Afw Xy77NErt+md3Z6739/9Dct6DX2qFmfI2opjWKiMhoK4rptcTd02TPfwMWVHnGl6ounrI 98EGUZIjAdSCCcbBwkF9AqXjYUN1k7g7p7Ljh4dY0//quuVAnWDBKIpfHIaJWcO6DxmK pzU2dfY9maA/xArT83aFvRWMj4aDyo7fugGbWath8Fv/LZegmQ/CB406nIdhKGoN/jyL kUNcsLC5mXtB/RzOK10+6N97y6wkKuh7PFSa9VmD7ZkNnaizlggvq3Q+xCxB58lc2iXE W7eg== MIME-Version: 1.0 X-Received: by 10.68.131.133 with SMTP id om5mr23496610pbb.148.1373323081433; Mon, 08 Jul 2013 15:38:01 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Mon, 8 Jul 2013 15:38:01 -0700 (PDT) In-Reply-To: <20130709002424.Horde.XLv2jNWmimcLqrv5hZm0Ew7@webmail.technion.ac.il> References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <0381995405c6459bd78d095ade79da7a@imap.plus.net> <20130709002424.Horde.XLv2jNWmimcLqrv5hZm0Ew7@webmail.technion.ac.il> Date: Mon, 8 Jul 2013 15:38:01 -0700 Message-ID: From: Andy Bierman To: Tal Mizrahi Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmpPtuBrNs9/mSazQPZWjUFAvrOI8nTbVA/p76HhGKyXE3zjr8n0QhqukLxFYoHWK0Q+a9l Cc: netconf@ietf.org, "moses@ee.technion.ac.il" Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 22:38:10 -0000 Hi, Can you explain why the server returns the execution time for operations since that doesn't seem to have anything to do with the problem statement of starting operations at a coordinated time? Andy On Mon, Jul 8, 2013 at 2:24 PM, Tal Mizrahi wrote: > Hi Jonathan, > > Thanks for your prompt comments. > >> * p3, scheduled time: this is defined as "the time at >> which the RPC should be completed", however scheduling (p4) states "the >> server ... executes the RPC at the scheduled time". Though many (most?) >> RPCs may complete in a short period of time, wouldn't it be more >> appropriate to define the scheduled time as "the time at which the RPC >> should be executed"? As you state later, there are a number of factors >> that can impact on the time to complete. Though some may be predictable, >> allowing the server to estimate when to start execution, others will not >> be. > > > As you point out, while some RPCs complete in a short time, others may ta= ke > a while. So if the RPC simply writes the value of a single leaf, its > execution time may be negligible compared to the execution accuracy. > However, if the RPC is, for example a operation, it may take a > while. Hence, we tried to generally be clear and accurate in what we mea= n > by =93executes the RPC at the scheduled time=94. I take your note that we= need > to make sure we are consistent in our phrasing. > > >> * How would you see this working when >> supporting the configuration of a set of network elements in a robust >> and transaction-oriented way, where the operation should complete on all >> devices or be fully reversed? > > > The time capability we propose should work well in networks with a high > degree of reliability, where you can benefit from a coordinated update at > the (small) cost of (rare) failures. But your point is well taken, and > similar points have also been raised by Andy in his comments from today, = so > we will consider it further. > > > Thanks, > Tal. > > > Quoting Jonathan Hansford : > >> Hi Tal, >> >> Like the idea of this capability. A couple of points on >> first reading: >> >> * p3, scheduled time: this is defined as "the time at >> which the RPC should be completed", however scheduling (p4) states "the >> server ... executes the RPC at the scheduled time". Though many (most?) >> RPCs may complete in a short period of time, wouldn't it be more >> appropriate to define the scheduled time as "the time at which the RPC >> should be executed"? As you state later, there are a number of factors >> that can impact on the time to complete. Though some may be predictable, >> allowing the server to estimate when to start execution, others will not >> be. >> * p9, 5.2: s/5.1. ,/5.1, >> * How would you see this working when >> supporting the configuration of a set of network elements in a robust >> and transaction-oriented way, where the operation should complete on all >> devices or be fully reversed? >> >> Jonathan >> >> On 2013-07-08 08:48, Tal >> Mizrahi wrote: >> >>> Hi, >>> >>> We have submitted a new draft titled "Time >> >> Capability in NETCONF". >>> >>> >> http://tools.ietf.org/html/draft-mm-netconf-time-capability-00 >>> >>> >>> Any >> >> comments will be welcome. >>> >>> Thanks, >>> Tal Mizrahi. >>> >>> >> _______________________________________________ >>> >>> Netconf mailing list >>> >> Netconf@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From dew@tx.technion.ac.il Tue Jul 9 00:06:47 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA4221F9F0B for ; Tue, 9 Jul 2013 00:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmpxXaVGTh1T for ; Tue, 9 Jul 2013 00:06:42 -0700 (PDT) Received: from mailgw13.technion.ac.il (mailgw13.technion.ac.il [132.68.225.13]) by ietfa.amsl.com (Postfix) with ESMTP id 37EE121F91CA for ; Tue, 9 Jul 2013 00:06:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAJAE+x21GERAEi/2dsb2JhbABagwkyTYMIqXaUBIEdFnSCIwEBAQMBAQEBIBU2CwULCxgCAiYCAicFKwYTiAkGDKc0iUGIBoEmjhIuBQeCVIEcA4kfjjOBKo5QgU+DFA X-IronPort-AV: E=Sophos;i="4.87,1026,1363125600"; d="scan'208";a="79043148" Received: from webmail.technion.ac.il ([132.68.1.34]) by mailgw13.technion.ac.il with ESMTP; 09 Jul 2013 10:06:36 +0300 Received: by webmail.technion.ac.il (Postfix, from userid 48) id 9F958100107; Tue, 9 Jul 2013 10:06:35 +0300 (IDT) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by webmail.technion.ac.il (Horde Framework) with HTTP; Tue, 09 Jul 2013 10:06:35 +0300 Date: Tue, 09 Jul 2013 10:06:35 +0300 Message-ID: <20130709100635.Horde.6GDL5_onBj7uUnOXNyCLvQ1@webmail.technion.ac.il> From: Tal Mizrahi To: Andy Bierman References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <0381995405c6459bd78d095ade79da7a@imap.plus.net> <20130709002424.Horde.XLv2jNWmimcLqrv5hZm0Ew7@webmail.technion.ac.il> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.0.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: netconf@ietf.org, "moses@ee.technion.ac.il" Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 07:06:47 -0000 Hi Andy, > Can you explain why the server returns the execution time for operations > since that doesn't seem to have anything to do with the problem statement > of starting operations at a coordinated time? The can provide the client with feedback about the actual execution time compared to the scheduled time sent by the client (see Figure 3 in the draft). For example, if the server was heavily utilized with other tasks and consequently performed the RPC half a second later than scheduled, this information may be important to the client. Another benefit of the is that it allows to attach a timestamp to the information the server sends to the client (Figure 2 in the draft). For example, when the client sends a request for statistics, it may be useful to attach a timestamp specifying when these statistics were captured. As you point out, the latter benefit has nothing to do with the problem statement. Thanks, Tal. Quoting Andy Bierman : > Hi, > > Can you explain why the server returns the execution time for operations > since that doesn't seem to have anything to do with the problem statement > of starting operations at a coordinated time? > > > Andy > > > On Mon, Jul 8, 2013 at 2:24 PM, Tal Mizrahi wrote= : >> Hi Jonathan, >> >> Thanks for your prompt comments. >> >>> * p3, scheduled time: this is defined as "the time at >>> which the RPC should be completed", however scheduling (p4) states "the >>> server ... executes the RPC at the scheduled time". Though many (most?) >>> RPCs may complete in a short period of time, wouldn't it be more >>> appropriate to define the scheduled time as "the time at which the RPC >>> should be executed"? As you state later, there are a number of factors >>> that can impact on the time to complete. Though some may be predictable= , >>> allowing the server to estimate when to start execution, others will no= t >>> be. >> >> >> As you point out, while some RPCs complete in a short time, others may t= ake >> a while. So if the RPC simply writes the value of a single leaf, its >> execution time may be negligible compared to the execution accuracy. >> However, if the RPC is, for example a operation, it may take a >> while. Hence, we tried to generally be clear and accurate in what we me= an >> by =E2=80=9Cexecutes the RPC at the scheduled time=E2=80=9D. I take your= note that we need >> to make sure we are consistent in our phrasing. >> >> >>> * How would you see this working when >>> supporting the configuration of a set of network elements in a robust >>> and transaction-oriented way, where the operation should complete on al= l >>> devices or be fully reversed? >> >> >> The time capability we propose should work well in networks with a high >> degree of reliability, where you can benefit from a coordinated update a= t >> the (small) cost of (rare) failures. But your point is well taken, and >> similar points have also been raised by Andy in his comments from today,= so >> we will consider it further. >> >> >> Thanks, >> Tal. >> >> >> Quoting Jonathan Hansford : >> >>> Hi Tal, >>> >>> Like the idea of this capability. A couple of points on >>> first reading: >>> >>> * p3, scheduled time: this is defined as "the time at >>> which the RPC should be completed", however scheduling (p4) states "the >>> server ... executes the RPC at the scheduled time". Though many (most?) >>> RPCs may complete in a short period of time, wouldn't it be more >>> appropriate to define the scheduled time as "the time at which the RPC >>> should be executed"? As you state later, there are a number of factors >>> that can impact on the time to complete. Though some may be predictable= , >>> allowing the server to estimate when to start execution, others will no= t >>> be. >>> * p9, 5.2: s/5.1. ,/5.1, >>> * How would you see this working when >>> supporting the configuration of a set of network elements in a robust >>> and transaction-oriented way, where the operation should complete on al= l >>> devices or be fully reversed? >>> >>> Jonathan >>> >>> On 2013-07-08 08:48, Tal >>> Mizrahi wrote: >>> >>>> Hi, >>>> >>>> We have submitted a new draft titled "Time >>> >>> Capability in NETCONF". >>>> >>>> >>> http://tools.ietf.org/html/draft-mm-netconf-time-capability-00 >>>> >>>> >>>> Any >>> >>> comments will be welcome. >>>> >>>> Thanks, >>>> Tal Mizrahi. >>>> >>>> >>> _______________________________________________ >>>> >>>> Netconf mailing list >>>> >>> Netconf@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/netconf >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf From Tina.Tsou.Zouting@huawei.com Tue Jul 9 11:02:54 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8326821F9EB9 for ; Tue, 9 Jul 2013 11:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.248 X-Spam-Level: X-Spam-Status: No, score=-5.248 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqIXMGWbgNqs for ; Tue, 9 Jul 2013 11:02:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 01EFB21F9E63 for ; Tue, 9 Jul 2013 11:02:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATG92662; Tue, 09 Jul 2013 18:02:46 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 9 Jul 2013 19:02:11 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 9 Jul 2013 19:02:41 +0100 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.217]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Tue, 9 Jul 2013 11:02:39 -0700 From: Tina TSOU To: "netconf@ietf.org" Thread-Topic: Rpc-error Thread-Index: Ac58zny1hj566QMjQY+O5zrwF1ysSA== Date: Tue, 9 Jul 2013 18:02:38 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.169] Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A8168560D3dfweml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Netconf] Rpc-error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 18:02:54 -0000 --_000_C0E0A32284495243BDE0AC8A066631A8168560D3dfweml513mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Mehmet asked me to move below offline discussion to the mailing list. My co-author and I who are preparing an Internet Draft about the extension = of rpc-error to support multiple language, refer the rfc6243 and several ot= her RFCs, there is no YANG Module definition for rpc-error, it's defined in= details in the netconf.xsd. It seems YANG module for RPC in current RFCs mainly takes care the input, b= ut pays less attention on output, we are wondering if there is any backgrou= nd or reasons. What do you think about this? Thank you, Tina --_000_C0E0A32284495243BDE0AC8A066631A8168560D3dfweml513mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

Mehmet asked me to move below offline discussion to = the mailing list.

My co-author and I who are preparing an Internet Dra= ft about the extension of rpc-error to support multiple language, refer the= rfc6243 and several other RFCs, there is no YANG Module definition for rpc= -error, it's defined in details in the netconf.xsd.

It seems YANG module for RPC in current RFCs mainly = takes care the input, but pays less attention on output, we are wondering i= f there is any background or reasons.

What do you think about this?

 

Thank you,

Tina

 

--_000_C0E0A32284495243BDE0AC8A066631A8168560D3dfweml513mbschi_-- From andy@yumaworks.com Tue Jul 9 11:25:55 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7CA21F9CCC for ; Tue, 9 Jul 2013 11:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efhrscCcoWjs for ; Tue, 9 Jul 2013 11:25:51 -0700 (PDT) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id AAB0121F9CA7 for ; Tue, 9 Jul 2013 11:25:45 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id tj12so5825387pac.26 for ; Tue, 09 Jul 2013 11:25:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=B+UL4qi7NVuxvTwl5mW1R7NDouA+zMOBzE5goXUp4yk=; b=Km62o51F46TxrNB+1DlQq6dXpFOo6GLjTfGThZC9f6vImo5dY/TyZtz7Vbjc+J2akX hloXqDBnn1jTWq9UtnMfWhNdrRO37tqGUg2Wce+0L1mkrmkPYc2be1+DW+VJ78hvjrp3 jIUtco6rPfO7QRQjlvlTcWX/+G1tIyeruCBPaNn5lUGjCpLIs13JmLhJgnaAYmnyJUe3 s8qVn+Qlriv6qt4/32M/6twkkGw7RUTX/yMVMkvIlTRdoJQUT9aVweObje/JvIHkbLtJ NaiLVHQLmKjWOIVhNprOXPk8VulvX/6RZKyNHMALmUbZr5isBgFaplIGP+ATPVhIc9Hv jAkg== MIME-Version: 1.0 X-Received: by 10.66.249.202 with SMTP id yw10mr29038835pac.145.1373394344951; Tue, 09 Jul 2013 11:25:44 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 9 Jul 2013 11:25:44 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Jul 2013 11:25:44 -0700 Message-ID: From: Andy Bierman To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmwk7qnMiUecXbyPKOzQesFYdlVpl2ZY697xfLxdXulx8cPB1qP1CoroC+6uAi2aRosXh5n Cc: "netconf@ietf.org" Subject: Re: [Netconf] Rpc-error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 18:25:56 -0000 On Tue, Jul 9, 2013 at 11:02 AM, Tina TSOU wrote: > Dear all, > > Mehmet asked me to move below offline discussion to the mailing list. > > My co-author and I who are preparing an Internet Draft about the extension > of rpc-error to support multiple language, refer the rfc6243 and several > other RFCs, there is no YANG Module definition for rpc-error, it's defined > in details in the netconf.xsd. > > It seems YANG module for RPC in current RFCs mainly takes care the input, > but pays less attention on output, we are wondering if there is any > background or reasons. > I wanted something like this, because it is in yuma-netconf.yang, and ietf-netconf.yang was derived from that module: http://www.netconfcentral.org/modulereport/yuma-netconf#RpcDataReplyType.659 There is already a definition of contents (rpcErrorType grouping) and I needed a YANG extension to define the xml:lang attribute: http://www.netconfcentral.org/modulereport/yuma-netconf#LangString.210 > What do you think about this? NETCONF error-message already supports the xml:lang attribute. Are you proposing to apply this attribute to other fields? That is the only one of type 'string'. error-message: Contains a string suitable for human display that describes the error condition. This element will not be present if no appropriate message is provided for a particular error condition. This element SHOULD include an "xml:lang" attribute as defined in [W3C.REC-xml-20001006] and discussed in [RFC3470]. > > > > Thank you, > > Tina > > Andy From robert.varga@pantheon.sk Wed Jul 10 23:22:51 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE1421F9D31 for ; Wed, 10 Jul 2013 23:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfDE+6iDyZJo for ; Wed, 10 Jul 2013 23:22:46 -0700 (PDT) Received: from amalka.pantheon.sk (amalka.pantheon.sk [81.89.59.174]) by ietfa.amsl.com (Postfix) with ESMTP id B149C21F9D2A for ; Wed, 10 Jul 2013 23:22:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id 6A2B2203C3 for ; Thu, 11 Jul 2013 08:22:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at pantheon.sk Authentication-Results: amalka.pantheon.sk (amavisd-new); dkim=pass (1024-bit key) header.d=pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caCtL0wxzcd0 for ; Thu, 11 Jul 2013 08:22:36 +0200 (CEST) Received: from cipisek.dmz.pantheon.local (cipisek.pantheon.sk [81.89.59.176]) by amalka.pantheon.sk (Postfix) with ESMTP for ; Thu, 11 Jul 2013 08:22:36 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 4371110634D for ; Thu, 11 Jul 2013 08:22:36 +0200 (CEST) Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Tztrn6fW7K6b for ; Thu, 11 Jul 2013 08:22:35 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 18A00106E4A for ; Thu, 11 Jul 2013 08:22:35 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.7.1 cipisek.dmz.pantheon.local 18A00106E4A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.sk; s=D7204E10-2735-11E2-9595-0BDFE9028503; t=1373523755; bh=Eoe/uKUwRlW0HiP+x9VXYQFFmIXERn8br9rTalmmhxo=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=XJe0U6yUGvIcXSpA03NiEulqfPy24JpRB2zM7RseLkcU7UecT5rlRHRNh0POWEKyi BZk2hDMtrmY+0Ns9FjzgGtlufmGSH5cEl6b8WB3ft2kqs+12cx7dd9d/V8Z179OggX tJeuV2AT2EIUIENDB8EplkTrU/2H/szrfARq5bZI= X-Virus-Scanned: amavisd-new at pantheon.sk Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6ZpbMSGViCuE for ; Thu, 11 Jul 2013 08:22:34 +0200 (CEST) Received: from [10.132.148.44] (unknown [85.237.227.44]) by cipisek.dmz.pantheon.local (Postfix) with ESMTPSA id C799510634D for ; Thu, 11 Jul 2013 08:22:33 +0200 (CEST) Message-ID: <51DE4F1F.1040207@pantheon.sk> Date: Thu, 11 Jul 2013 08:22:23 +0200 From: Robert Varga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: netconf@ietf.org References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> In-Reply-To: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 06:22:51 -0000 Hi everyone, I have just uploaded a new draft specifying an extension to NETCONF protocol which allows the message encoding to be switched to Efficient XML Interchange (EXI). Any comments/feedback are welcome. Thanks, Robert -------- Original Message -------- Subject: New Version Notification for draft-varga-netconf-exi-capability-00.txt Date: Wed, 10 Jul 2013 23:11:48 -0700 From: internet-drafts@ietf.org To: Robert Varga A new version of I-D, draft-varga-netconf-exi-capability-00.txt has been successfully submitted by Robert Varga and posted to the IETF repository. Filename: draft-varga-netconf-exi-capability Revision: 00 Title: Efficient XML Interchange Capability for NETCONF Creation date: 2013-07-11 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-varga-netconf-exi-capability-00.txt Status: http://datatracker.ietf.org/doc/draft-varga-netconf-exi-capability Htmlized: http://tools.ietf.org/html/draft-varga-netconf-exi-capability-00 Abstract: The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices via exchange of XML messages in textual representation. Efficient XML Interchange (EXI) is a W3C-recommended binary representation of XML Information Set, which is more efficient from both CPU and bandwidth utilization perspective. This document defines a capability-based extension to the NETCONF protocol that allows peers to agree to exchange protocol messages using EXI encoding. The IETF Secretariat From j.schoenwaelder@jacobs-university.de Thu Jul 11 00:23:46 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F7621F9D7A for ; Thu, 11 Jul 2013 00:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.116 X-Spam-Level: X-Spam-Status: No, score=-103.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ldGlVM0RLQJ for ; Thu, 11 Jul 2013 00:23:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 11B9621F938E for ; Thu, 11 Jul 2013 00:23:41 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A33A20BE8; Thu, 11 Jul 2013 09:23:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eEY6-AhEOAge; Thu, 11 Jul 2013 09:23:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB4E820BDC; Thu, 11 Jul 2013 09:23:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C8F012732138; Thu, 11 Jul 2013 09:23:14 +0200 (CEST) Date: Thu, 11 Jul 2013 09:23:14 +0200 From: Juergen Schoenwaelder To: Robert Varga Message-ID: <20130711072314.GA69009@elstar.local> Mail-Followup-To: Robert Varga , netconf@ietf.org References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51DE4F1F.1040207@pantheon.sk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 07:23:46 -0000 On Thu, Jul 11, 2013 at 08:22:23AM +0200, Robert Varga wrote: > Hi everyone, > > I have just uploaded a new draft specifying an extension to NETCONF > protocol which allows the message encoding to be switched to > Efficient XML Interchange (EXI). Did you implement this? If so, what is the gain in a) consumed bandwidth, b) reduced code size, c) runtime overhead? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From michal.vaner@nic.cz Thu Jul 11 00:44:48 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A26D21F9DAF for ; Thu, 11 Jul 2013 00:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTNHoXxuG48X for ; Thu, 11 Jul 2013 00:44:47 -0700 (PDT) Received: from lair.vorner.cz (mail.vorner.cz [IPv6:2a02:2b88:2:1::10b3:1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DC321F963F for ; Thu, 11 Jul 2013 00:44:47 -0700 (PDT) Received: by lair.vorner.cz (Postfix, from userid 1000) id DC1FE3FE26; Thu, 11 Jul 2013 09:44:46 +0200 (CEST) Date: Thu, 11 Jul 2013 09:44:46 +0200 From: Michal 'vorner' Vaner To: netconf@ietf.org Message-ID: <20130711074446.GA23993@ruth> References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130711072314.GA69009@elstar.local> Jabber-ID: michal.vaner@nic.cz User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 07:44:48 -0000 Good morning On Thu, Jul 11, 2013 at 09:23:14AM +0200, Juergen Schoenwaelder wrote: > On Thu, Jul 11, 2013 at 08:22:23AM +0200, Robert Varga wrote: > > I have just uploaded a new draft specifying an extension to NETCONF > > protocol which allows the message encoding to be switched to > > Efficient XML Interchange (EXI). > > Did you implement this? If so, what is the gain in > > a) consumed bandwidth, > b) reduced code size, > c) runtime overhead? May I suggest to compare it with enabling compression in the underlying ssh connection, with `ssh -C` or equivalent? With regards -- Michal 'vorner' Vaner From ietfdbh@comcast.net Thu Jul 11 03:51:11 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84AD21F9AEE for ; Thu, 11 Jul 2013 03:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.382 X-Spam-Level: X-Spam-Status: No, score=-100.382 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BN4lVjzPXXY for ; Thu, 11 Jul 2013 03:51:07 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id D56BB21F92BB for ; Thu, 11 Jul 2013 03:51:06 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta14.westchester.pa.mail.comcast.net with comcast id yyo21l0020vyq2s5Eyr5w5; Thu, 11 Jul 2013 10:51:05 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta05.westchester.pa.mail.comcast.net with comcast id yyr41l00u2yZEBF3Ryr5ov; Thu, 11 Jul 2013 10:51:05 +0000 From: "ietfdbh" To: References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local> <20130711074446.GA23993@ruth> In-Reply-To: <20130711074446.GA23993@ruth> Date: Thu, 11 Jul 2013 06:50:31 -0400 Message-ID: <00a201ce7e24$76a04360$63e0ca20$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE9s2whASc+vELrC7tVkkVUJViL3AKO6h0eAlWZ5t8ChG5RKJpFjE/w Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373539865; bh=bVpYEZpUsRHSKxRtcgvAD/7d6/08hyb1850k9iv82Dg=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=F0joZMHiDeVdwlaoBa3djzr9Boof5EdI/YTfI7mXdT7cIasiO5Smk4YOQqftao9+9 fFCq8wvfqRfp/jnqpSqb1EELCq5LDfVK6Z2J3emFiwGDevvp7DErJUM6LxfBszG1rw qWfzehF4slKzXG0x4BZ88WLvMZ0m3Q1+0zlj5hD5lS1+T/r1/GUWQ0xcXG9BUQArW7 nga5TRoEzbKNYphr6/kGRqgFj2adDCNVpD2qGcbFPQIECTA+zdQ+UAEubSCdeU/r67 QLKXNSc146FOayFQQwXZnvpm5C5vK/+orqIL/HRHdoDBHuK6hzTmmiMFUx4soF6Jhl CbtsT3YnOZD5Q== Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 10:51:11 -0000 Hi, A major reason for moving from SNMP's ASN.1 binary encoding to XML's text-based encoding was operator request. Operators preferred a solution that was readable on-the-wire, so they could look at packet-dumps and see the information being passed. Operators found that SNMP packets had to be decoded by (non-standard) applications to make the data human-readable, and often an application UI never showed the raw varbinds; and the information presented to the operator might have been cached, or might have been "interpreted" before being shown to the operator. Even when the decoded raw varbinds were shown, such as with a MIB browser, the OIDs were not human-friendly. By having the data encoded in XML, the on-the-wire packet content was readable in a packet dump, and the labels were meaningful. (Of course, with encryption, the content was unreadable.) I would be interested in seeing a discussion of these points in a comparison of XML, EXI, and "ssh -C" encodings. Such discussion should probably include whether popular packet sniffing tools, both commercial and open source, supported the formats, and at what level in the transfer of information between systems (i.e. in the network stack and/or the Netconf architecture) an operator can access something human-readable. It would also be interesting to discuss the adoption level of each approach. EXI was approved in 2011; When was "ssh -C" approved as a standard? Do we have any information about how many commercial/open-source toolkits support the standards? I don't know EXI. Wikipedia indicates EXI uses "schema-informed" compression, and the decoder needs a copy of the same schema that the encoder used . How would this potentially affect Netconf? Assuming multiple Netconf clients (NMSes) talk to multiple Netconf servers, does that mean that each client must have the managed-device-specific schema for each device, and each netconf server must have a copy of the schema used by each client? While such an approach might be viable for a web browser/web server relationship, where each is hosted on a device that is not very resource constrained, but what impact would this have on devices with significant resource constraints (as is common with Netconf)? David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Michal 'vorner' Vaner > Sent: Thursday, July 11, 2013 3:45 AM > To: netconf@ietf.org > Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga- > netconf-exi-capability-00.txt > > Good morning > > On Thu, Jul 11, 2013 at 09:23:14AM +0200, Juergen Schoenwaelder wrote: > > On Thu, Jul 11, 2013 at 08:22:23AM +0200, Robert Varga wrote: > > > I have just uploaded a new draft specifying an extension to NETCONF > > > protocol which allows the message encoding to be switched to > > > Efficient XML Interchange (EXI). > > > > Did you implement this? If so, what is the gain in > > > > a) consumed bandwidth, > > b) reduced code size, > > c) runtime overhead? > > May I suggest to compare it with enabling compression in the underlying ssh > connection, with `ssh -C` or equivalent? > > With regards > > -- > Michal 'vorner' Vaner > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From dbharrington@comcast.net Thu Jul 11 04:25:36 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B3D21F935A for ; Thu, 11 Jul 2013 04:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.77 X-Spam-Level: X-Spam-Status: No, score=0.77 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkffgFdU5F6c for ; Thu, 11 Jul 2013 04:25:31 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 9164621F99E2 for ; Thu, 11 Jul 2013 04:25:30 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta10.westchester.pa.mail.comcast.net with comcast id yzGZ1l0051swQuc5AzRVzo; Thu, 11 Jul 2013 11:25:29 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta15.westchester.pa.mail.comcast.net with comcast id yzRV1l00m2yZEBF3bzRVsM; Thu, 11 Jul 2013 11:25:29 +0000 From: "David Harrington" To: "'ietfdbh'" , References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local> <20130711074446.GA23993@ruth> <00a201ce7e24$76a04360$63e0ca20$@comcast.net> In-Reply-To: <00a201ce7e24$76a04360$63e0ca20$@comcast.net> Date: Thu, 11 Jul 2013 07:24:55 -0400 Message-ID: <00a601ce7e29$4555c190$d00144b0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE9s2whASc+vELrC7tVkkVUJViL3AKO6h0eAlWZ5t8ChG5RKAH8OmYNmjW9jJA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373541930; bh=sU1V3FhXdbnpPFnYc8AhM7BfWC2lRyXMx+5Zmm2+Jg0=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=MEjbiGcNLDqehlJ44dMlMUQYsY01iOyPN5ui9JUfRqzbtxSGib9ftsQXunbWiLU5r nRKBQ9yZDJAFPBQ4awUCFBtBQ2IVG5VCAC9gGt0z5WUMrI38s0IYFXj8bfpxBCP6Qh vSzUNhLc3W3vIKf2nvjahIKm6cyn5pToBcMy6VbztdXGX66yOSi0pkfxNZRUk9IdKb YVehRLtwrvqRx5Q341WH8g8qsFGvwvCvJlat8mkicKN0iiFs6dXhMPUFsTca+xNEU3 dRXaj16vU2iaeEXZfHo66g+phCUSI3DzwksoW9eAta14MMZNzFV/3jTgCCLT54n2ES M/u7jzrx+53WQ== Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 11:25:36 -0000 Hi, Since EXI is schema-informed, would a EXI-standard-compliant implementation work with a YANG schema, or would a compliant implementation require a particular type of schema, such as W3C-standard XML Schema (XSD)? At what point in the process does EXI becomes schema-informed? Is this a special schema that is used only during the encode/decode steps, totally independent of where in the process a YANG schema or RELAX-NG schema would get used with Netconf? David Harrington dbharrington@comcast.net +1-603-828-1401 > -----Original Message----- > From: ietfdbh [mailto:ietfdbh@comcast.net] > Sent: Thursday, July 11, 2013 6:51 AM > To: netconf@ietf.org > Subject: RE: [Netconf] Fwd: New Version Notification for draft-varga- > netconf-exi-capability-00.txt > > Hi, > > A major reason for moving from SNMP's ASN.1 binary encoding to XML's > text-based encoding was operator request. > > Operators preferred a solution that was readable on-the-wire, so they could > look at packet-dumps and see the information being passed. > Operators found that SNMP packets had to be decoded by (non-standard) > applications to make the data human-readable, and often an application UI > never showed the raw varbinds; and the information presented to the > operator might have been cached, or might have been "interpreted" before > being shown to the operator. Even when the decoded raw varbinds were > shown, such as with a MIB browser, the OIDs were not human-friendly. By > having the data encoded in XML, the on-the-wire packet content was > readable in a packet dump, and the labels were meaningful. (Of course, with > encryption, the content was > unreadable.) > > I would be interested in seeing a discussion of these points in a comparison > of XML, EXI, and "ssh -C" encodings. Such discussion should probably include > whether popular packet sniffing tools, both commercial and open source, > supported the formats, and at what level in the transfer of information > between systems (i.e. in the network stack and/or the Netconf architecture) > an operator can access something human-readable. > > It would also be interesting to discuss the adoption level of each approach. > EXI was approved in 2011; When was "ssh -C" approved as a standard? > Do we have any information about how many commercial/open-source > toolkits support the standards? > > I don't know EXI. Wikipedia indicates EXI uses "schema-informed" > compression, and the decoder needs a copy of the same schema that the > encoder used . How would this potentially affect Netconf? Assuming multiple > Netconf clients (NMSes) talk to multiple Netconf servers, does that mean > that each client must have the managed-device-specific schema for each > device, and each netconf server must have a copy of the schema used by > each client? While such an approach might be viable for a web browser/web > server relationship, where each is hosted on a device that is not very > resource constrained, but what impact would this have on devices with > significant resource constraints (as is common with Netconf)? > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > Behalf Of Michal 'vorner' Vaner > > Sent: Thursday, July 11, 2013 3:45 AM > > To: netconf@ietf.org > > Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga- > > netconf-exi-capability-00.txt > > > > Good morning > > > > On Thu, Jul 11, 2013 at 09:23:14AM +0200, Juergen Schoenwaelder wrote: > > > On Thu, Jul 11, 2013 at 08:22:23AM +0200, Robert Varga wrote: > > > > I have just uploaded a new draft specifying an extension to > > > > NETCONF protocol which allows the message encoding to be switched > > > > to Efficient XML Interchange (EXI). > > > > > > Did you implement this? If so, what is the gain in > > > > > > a) consumed bandwidth, > > > b) reduced code size, > > > c) runtime overhead? > > > > May I suggest to compare it with enabling compression in the > > underlying > ssh > > connection, with `ssh -C` or equivalent? > > > > With regards > > > > -- > > Michal 'vorner' Vaner > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf From lhotka@nic.cz Thu Jul 11 04:31:24 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A5921F9C25 for ; Thu, 11 Jul 2013 04:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeWBqCyXVKYv for ; Thu, 11 Jul 2013 04:31:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39121F9D0F for ; Thu, 11 Jul 2013 04:31:21 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:8c45:4a1d:a7a5:52c2] (unknown [IPv6:2001:1488:ac14:1400:8c45:4a1d:a7a5:52c2]) by mail.nic.cz (Postfix) with ESMTPSA id 351DC13FA25; Thu, 11 Jul 2013 13:31:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1373542278; bh=BtJu3qvtK374ATaCFkI9uKFaVoZWyUGlKva/KVkRKks=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ePvBD+wliP8i5XtMXwkRVvirNIBMFMzD21OdmTcxyfb90I32HXKFgaglEOv88tuwW +DIeIrE/qCuUWn3bGgSyBv5iUc9MahWLkUSAMmNg2ZVrcmK3FaAYzqe/6XeuP9euLh raWUAWUxOmGp7bD21MneCMHKttYyfy3k4a9AjVEw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <00a601ce7e29$4555c190$d00144b0$@comcast.net> Date: Thu, 11 Jul 2013 13:31:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local> <20130711074446.GA23993@ruth> <00a201ce7e24$76a04360$63e0ca20$@comcast.net> <00a601ce7e29$4555c190$d00144b0$@comcast.net> To: "David Harrington" X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netconf@ietf.org Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 11:31:24 -0000 On Jul 11, 2013, at 1:24 PM, "David Harrington" = wrote: > Hi, >=20 > Since EXI is schema-informed, would a EXI-standard-compliant = implementation > work with a YANG schema, or would a compliant implementation require a > particular type of schema, such as W3C-standard XML Schema (XSD)? It seems the mapping to RELAX NG (RFC 6020) could be used for this = purpose. Lada >=20 >=20 > At what point in the process does EXI becomes schema-informed? Is this = a > special schema that is used only during the encode/decode steps, = totally > independent of where in the process a YANG schema or RELAX-NG schema = would > get used with Netconf? >=20 > David Harrington > dbharrington@comcast.net > +1-603-828-1401 >=20 >> -----Original Message----- >> From: ietfdbh [mailto:ietfdbh@comcast.net] >> Sent: Thursday, July 11, 2013 6:51 AM >> To: netconf@ietf.org >> Subject: RE: [Netconf] Fwd: New Version Notification for draft-varga- >> netconf-exi-capability-00.txt >>=20 >> Hi, >>=20 >> A major reason for moving from SNMP's ASN.1 binary encoding to XML's >> text-based encoding was operator request. >>=20 >> Operators preferred a solution that was readable on-the-wire, so they > could >> look at packet-dumps and see the information being passed. >> Operators found that SNMP packets had to be decoded by (non-standard) >> applications to make the data human-readable, and often an = application UI >> never showed the raw varbinds; and the information presented to the >> operator might have been cached, or might have been "interpreted" = before >> being shown to the operator. Even when the decoded raw varbinds were >> shown, such as with a MIB browser, the OIDs were not human-friendly. = By >> having the data encoded in XML, the on-the-wire packet content was >> readable in a packet dump, and the labels were meaningful. (Of = course, > with >> encryption, the content was >> unreadable.) >>=20 >> I would be interested in seeing a discussion of these points in a > comparison >> of XML, EXI, and "ssh -C" encodings. Such discussion should probably > include >> whether popular packet sniffing tools, both commercial and open = source, >> supported the formats, and at what level in the transfer of = information >> between systems (i.e. in the network stack and/or the Netconf > architecture) >> an operator can access something human-readable. >>=20 >> It would also be interesting to discuss the adoption level of each > approach. >> EXI was approved in 2011; When was "ssh -C" approved as a standard? >> Do we have any information about how many commercial/open-source >> toolkits support the standards? >>=20 >> I don't know EXI. Wikipedia indicates EXI uses "schema-informed" >> compression, and the decoder needs a copy of the same schema that the >> encoder used . How would this potentially affect Netconf? Assuming > multiple >> Netconf clients (NMSes) talk to multiple Netconf servers, does that = mean >> that each client must have the managed-device-specific schema for = each >> device, and each netconf server must have a copy of the schema used = by >> each client? While such an approach might be viable for a web = browser/web >> server relationship, where each is hosted on a device that is not = very >> resource constrained, but what impact would this have on devices with >> significant resource constraints (as is common with Netconf)? >>=20 >> David Harrington >> ietfdbh@comcast.net >> +1-603-828-1401 >>=20 >>> -----Original Message----- >>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >>> Behalf Of Michal 'vorner' Vaner >>> Sent: Thursday, July 11, 2013 3:45 AM >>> To: netconf@ietf.org >>> Subject: Re: [Netconf] Fwd: New Version Notification for = draft-varga- >>> netconf-exi-capability-00.txt >>>=20 >>> Good morning >>>=20 >>> On Thu, Jul 11, 2013 at 09:23:14AM +0200, Juergen Schoenwaelder = wrote: >>>> On Thu, Jul 11, 2013 at 08:22:23AM +0200, Robert Varga wrote: >>>>> I have just uploaded a new draft specifying an extension to >>>>> NETCONF protocol which allows the message encoding to be switched >>>>> to Efficient XML Interchange (EXI). >>>>=20 >>>> Did you implement this? If so, what is the gain in >>>>=20 >>>> a) consumed bandwidth, >>>> b) reduced code size, >>>> c) runtime overhead? >>>=20 >>> May I suggest to compare it with enabling compression in the >>> underlying >> ssh >>> connection, with `ssh -C` or equivalent? >>>=20 >>> With regards >>>=20 >>> -- >>> Michal 'vorner' Vaner >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Thu Jul 11 06:49:21 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7B911E8172 for ; Thu, 11 Jul 2013 06:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5cUGfFfYbH5 for ; Thu, 11 Jul 2013 06:49:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 620D111E816E for ; Thu, 11 Jul 2013 06:49:16 -0700 (PDT) Received: from [192.168.42.250] (89-24-12-224.i4g.tmcz.cz [89.24.12.224]) by mail.nic.cz (Postfix) with ESMTPSA id E23FF13F65D; Thu, 11 Jul 2013 15:49:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1373550554; bh=IXg43ngK2g7b9Bfpb3KzfZ6lQH8+QNF6UvZ9pc9OzhM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nyt7NpWWXOMcwTgsjBsVBxf5sUfdnmdQkcqyVgQvvDDPZR8hiPYa19bTAB0IXMNlQ fvDEP9rxTBOgJgcPklsjHoZ2499QvWFqudHUsdVR9DfrPdTIXOR0H8ljWxNtJ+qkW3 gozDOEvaiOcrlBczaTfui8P8vup79ZaXjOmFJvKQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 11 Jul 2013 15:49:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1385E39C-8CC3-4AF7-968A-24E56D7A2CE9@nic.cz> References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local> <20130711074446.GA23993@ruth> <00a201ce7e24$76a04360$63e0ca20$@comcast.net> <00a601ce7e29$4555c190$d00144b0$@comcast.net> To: "David Harrington" X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netconf@ietf.org Subject: Re: [Netconf] New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 13:49:22 -0000 On Jul 11, 2013, at 1:31 PM, Ladislav Lhotka wrote: >=20 > On Jul 11, 2013, at 1:24 PM, "David Harrington" = wrote: >=20 >> Hi, >>=20 >> Since EXI is schema-informed, would a EXI-standard-compliant = implementation >> work with a YANG schema, or would a compliant implementation require = a >> particular type of schema, such as W3C-standard XML Schema (XSD)? >=20 > It seems the mapping to RELAX NG (RFC 6020) could be used for this = purpose. Oh, the RFC number was supposed to be 6110 (what a shame:-). Lada >=20 > Lada >=20 >>=20 >>=20 >> At what point in the process does EXI becomes schema-informed? Is = this a >> special schema that is used only during the encode/decode steps, = totally >> independent of where in the process a YANG schema or RELAX-NG schema = would >> get used with Netconf? >>=20 >> David Harrington >> dbharrington@comcast.net >> +1-603-828-1401 >>=20 >>> -----Original Message----- >>> From: ietfdbh [mailto:ietfdbh@comcast.net] >>> Sent: Thursday, July 11, 2013 6:51 AM >>> To: netconf@ietf.org >>> Subject: RE: [Netconf] Fwd: New Version Notification for = draft-varga- >>> netconf-exi-capability-00.txt >>>=20 >>> Hi, >>>=20 >>> A major reason for moving from SNMP's ASN.1 binary encoding to XML's >>> text-based encoding was operator request. >>>=20 >>> Operators preferred a solution that was readable on-the-wire, so = they >> could >>> look at packet-dumps and see the information being passed. >>> Operators found that SNMP packets had to be decoded by = (non-standard) >>> applications to make the data human-readable, and often an = application UI >>> never showed the raw varbinds; and the information presented to the >>> operator might have been cached, or might have been "interpreted" = before >>> being shown to the operator. Even when the decoded raw varbinds were >>> shown, such as with a MIB browser, the OIDs were not human-friendly. = By >>> having the data encoded in XML, the on-the-wire packet content was >>> readable in a packet dump, and the labels were meaningful. (Of = course, >> with >>> encryption, the content was >>> unreadable.) >>>=20 >>> I would be interested in seeing a discussion of these points in a >> comparison >>> of XML, EXI, and "ssh -C" encodings. Such discussion should probably >> include >>> whether popular packet sniffing tools, both commercial and open = source, >>> supported the formats, and at what level in the transfer of = information >>> between systems (i.e. in the network stack and/or the Netconf >> architecture) >>> an operator can access something human-readable. >>>=20 >>> It would also be interesting to discuss the adoption level of each >> approach. >>> EXI was approved in 2011; When was "ssh -C" approved as a standard? >>> Do we have any information about how many commercial/open-source >>> toolkits support the standards? >>>=20 >>> I don't know EXI. Wikipedia indicates EXI uses "schema-informed" >>> compression, and the decoder needs a copy of the same schema that = the >>> encoder used . How would this potentially affect Netconf? Assuming >> multiple >>> Netconf clients (NMSes) talk to multiple Netconf servers, does that = mean >>> that each client must have the managed-device-specific schema for = each >>> device, and each netconf server must have a copy of the schema used = by >>> each client? While such an approach might be viable for a web = browser/web >>> server relationship, where each is hosted on a device that is not = very >>> resource constrained, but what impact would this have on devices = with >>> significant resource constraints (as is common with Netconf)? >>>=20 >>> David Harrington >>> ietfdbh@comcast.net >>> +1-603-828-1401 >>>=20 >>>> -----Original Message----- >>>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >>>> Behalf Of Michal 'vorner' Vaner >>>> Sent: Thursday, July 11, 2013 3:45 AM >>>> To: netconf@ietf.org >>>> Subject: Re: [Netconf] Fwd: New Version Notification for = draft-varga- >>>> netconf-exi-capability-00.txt >>>>=20 >>>> Good morning >>>>=20 >>>> On Thu, Jul 11, 2013 at 09:23:14AM +0200, Juergen Schoenwaelder = wrote: >>>>> On Thu, Jul 11, 2013 at 08:22:23AM +0200, Robert Varga wrote: >>>>>> I have just uploaded a new draft specifying an extension to >>>>>> NETCONF protocol which allows the message encoding to be switched >>>>>> to Efficient XML Interchange (EXI). >>>>>=20 >>>>> Did you implement this? If so, what is the gain in >>>>>=20 >>>>> a) consumed bandwidth, >>>>> b) reduced code size, >>>>> c) runtime overhead? >>>>=20 >>>> May I suggest to compare it with enabling compression in the >>>> underlying >>> ssh >>>> connection, with `ssh -C` or equivalent? >>>>=20 >>>> With regards >>>>=20 >>>> -- >>>> Michal 'vorner' Vaner >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Fri Jul 12 13:13:26 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9776421F9F31 for ; Fri, 12 Jul 2013 13:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.708 X-Spam-Level: X-Spam-Status: No, score=-2.708 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UocYlNj2ZMVI for ; Fri, 12 Jul 2013 13:13:22 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6D721F9F32 for ; Fri, 12 Jul 2013 13:13:22 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id uo1so9392582pbc.17 for ; Fri, 12 Jul 2013 13:13:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Y7UcXMJJNsTRzNLV50vU773AWIv2fImRl93R9SMma5Y=; b=iDycEa9WMMKrgnVpMklGkx6Z+daQD3tui7l0GRBEcIOlMOihplcH/EAmsHrZ9JPy1n g3Lzqx+x3o5rvWTy3JwzSL9k0HqcPyMfh59xO2HLqKDTm4u5/hxZdPg9KxshQMMnylDd 2zUt/0T9hN2AP4QQGKkwiD2gTZs8fMY+IqxfoY3+0Mi1b1mMEjGpihr+nsw0bWxsJDPz 0OWjVpVHe3Sfp/mDcGqbS4TJLuoOXCoEDTIgEEndk+pfoxHKk/1DsrGShNq9Vfyy628U eMz2gsfBsibRaNPSPRP7mfvJtUSrl4euhYqPSgIllqdIRZRi0EuXIoqO6ZXG9VnxL8ef GbwA== MIME-Version: 1.0 X-Received: by 10.66.19.229 with SMTP id i5mr44209754pae.158.1373660001845; Fri, 12 Jul 2013 13:13:21 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Fri, 12 Jul 2013 13:13:21 -0700 (PDT) In-Reply-To: <00a201ce7e24$76a04360$63e0ca20$@comcast.net> References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local> <20130711074446.GA23993@ruth> <00a201ce7e24$76a04360$63e0ca20$@comcast.net> Date: Fri, 12 Jul 2013 13:13:21 -0700 Message-ID: From: Andy Bierman To: ietfdbh Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmC9Yd6g6B4ZXHh5sRqAmefv3bxICb1I9L77w3N8gDH9WBMltdkweA8Q2+DJfxNfAN3oDYc Cc: netconf@ietf.org Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 20:13:26 -0000 Hi, some comments inline... On Thu, Jul 11, 2013 at 3:50 AM, ietfdbh wrote: > Hi, > > A major reason for moving from SNMP's ASN.1 binary encoding to XML's > text-based encoding was operator request. > > Operators preferred a solution that was readable on-the-wire, so they could > look at packet-dumps and see the information being passed. > Operators found that SNMP packets had to be decoded by (non-standard) > applications to make the data human-readable, and often an application UI > never showed the raw varbinds; and the information presented to the operator > might have been cached, or might have been "interpreted" before being shown > to the operator. Even when the decoded raw varbinds were shown, such as with > a MIB browser, the OIDs were not human-friendly. By having the data encoded > in XML, the on-the-wire packet content was readable in a packet dump, and > the labels were meaningful. (Of course, with encryption, the content was > unreadable.) I don't think operators asked for monitoring data to be returned in readable format. That was a config-related request. I have not studied this draft or EXI in detail yet. One question: what are the use-cases for enabling and disabling an "EXI mode"? I prefer the same encoding for the whole session. FYI: Efficient XML Interchange http://www.w3.org/TR/2011/REC-exi-20110310/ IMO, plain and binary JSON looks easier to implement: Binary Encodings for JSON http://www.ietf.org/id/draft-hallambaker-jsonbcd-00.txt > > I would be interested in seeing a discussion of these points in a comparison > of XML, EXI, and "ssh -C" encodings. Such discussion should probably include > whether popular packet sniffing tools, both commercial and open source, > supported the formats, and at what level in the transfer of information > between systems (i.e. in the network stack and/or the Netconf architecture) > an operator can access something human-readable. > An operator might have to enable plain encoding, in addition to providing keys to the sniffer so it can decode the SSH packets. (I can't see XML in wireshark for NETCONF sessions). > It would also be interesting to discuss the adoption level of each approach. > EXI was approved in 2011; When was "ssh -C" approved as a standard? > Do we have any information about how many commercial/open-source toolkits > support the standards? > > I don't know EXI. Wikipedia indicates EXI uses "schema-informed" > compression, and the decoder needs a copy of the same schema that the > encoder used . How would this potentially affect Netconf? Assuming multiple > Netconf clients (NMSes) talk to multiple Netconf servers, does that mean > that each client must have the managed-device-specific schema for each > device, and each netconf server must have a copy of the schema used by each > client? While such an approach might be viable for a web browser/web server > relationship, where each is hosted on a device that is not very resource > constrained, but what impact would this have on devices with significant > resource constraints (as is common with Netconf)? > IMO, the encoding is a second order problem. Real efficiency is derived from the appropriate set of protocol operations. The standards are behind industry in this area. (If you are scrubbing the floor with a toothbrush, you might be inclined to invest in better bristle technology ;-) > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > Andy From Tina.Tsou.Zouting@huawei.com Fri Jul 12 13:19:50 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D711121F9EDA for ; Fri, 12 Jul 2013 13:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaVVzRHQgNzW for ; Fri, 12 Jul 2013 13:19:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1768B21F9E6E for ; Fri, 12 Jul 2013 13:19:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUY76680; Fri, 12 Jul 2013 20:19:44 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 21:19:03 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 21:19:42 +0100 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.217]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Fri, 12 Jul 2013 13:19:39 -0700 From: Tina TSOU To: Andy Bierman Thread-Topic: [Netconf] Rpc-error Thread-Index: Ac58zny1hj566QMjQY+O5zrwF1ysSAAPekAAAIwvJmY= Date: Fri, 12 Jul 2013 20:19:38 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C0BAAF6D8CEF4BE3987C969D6C37172Fhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "netconf@ietf.org" Subject: Re: [Netconf] Rpc-error X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 20:19:51 -0000 --_000_C0BAAF6D8CEF4BE3987C969D6C37172Fhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Andy et al, Here is the draft. Begin forwarded message: From: > Date: July 11, 2013, 5:59:49 AM PDT To: Tina Tsou >, Xiaofeng Ji >, = Shouchuan Yang >,= Ting Zou >, Gang Yan > Subject: New Version Notification for draft-ysc-netconf-rpc-error-extension= -00.txt A new version of I-D, draft-ysc-netconf-rpc-error-extension-00.txt has been successfully submitted by Shouchuan Yang and posted to the IETF repository. Filename: draft-ysc-netconf-rpc-error-extension Revision: 00 Title: NETCONF rpc-error extension Creation date: 2013-07-11 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-ysc-netconf-rpc-= error-extension-00.txt Status: http://datatracker.ietf.org/doc/draft-ysc-netconf-rpc-erro= r-extension Htmlized: http://tools.ietf.org/html/draft-ysc-netconf-rpc-error-ext= ension-00 Abstract: The NETCONF is a machine-machine interface, it is easy to expand. This document will expand the rpc-error message to make multiple language support easily. The IETF Secretariat Thank you, Tina On Jul 9, 2013, at 11:25 AM, "Andy Bierman" > wrote: On Tue, Jul 9, 2013 at 11:02 AM, Tina TSOU > wrote: Dear all, Mehmet asked me to move below offline discussion to the mailing list. My co-author and I who are preparing an Internet Draft about the extension of rpc-error to support multiple language, refer the rfc6243 and several other RFCs, there is no YANG Module definition for rpc-error, it's defined in details in the netconf.xsd. It seems YANG module for RPC in current RFCs mainly takes care the input, but pays less attention on output, we are wondering if there is any background or reasons. I wanted something like this, because it is in yuma-netconf.yang, and ietf-netconf.yang was derived from that module: http://www.netconfcentral.org/modulereport/yuma-netconf#RpcDataReplyType.65= 9 There is already a definition of contents (rpcErrorType groupin= g) and I needed a YANG extension to define the xml:lang attribute: http://www.netconfcentral.org/modulereport/yuma-netconf#LangString.210 What do you think about this? NETCONF error-message already supports the xml:lang attribute. Are you proposing to apply this attribute to other fields? That is the only one of type 'string'. error-message: Contains a string suitable for human display that describes the error condition. This element will not be present if no appropriate message is provided for a particular error condition. This element SHOULD include an "xml:lang" attribute as defined in [W3C.REC-xml-20001006] and discussed in [RFC3470]. Thank you, Tina Andy --_000_C0BAAF6D8CEF4BE3987C969D6C37172Fhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Andy et al,
Here is the draft.

Begin forwarded message:

From: <internet-= drafts@ietf.org>
Date: July 11, 2013, 5:59:49 AM PDT
To: Tina Tsou <tina.tsou.zouting@huawei.com>, Xiaofeng Ji <jixiaofeng@huawei.com>, Shouchuan Yang <yangshouchuan@huawei.com>, Ting Zou <tina.tsou.zou= ting@huawei.com>, Gang Yan <yangang@huawei.com>
Subject: New Version Notification for draft-ysc-netconf-rpc-= error-extension-00.txt


A new version of I-D, draft-ysc-netconf-rpc-error-extension-00.txt
has been successfully submitted by Shouchuan Yang and posted to the
IETF repository.

Filename:     draft-ysc-netconf-rpc-error-extension
Revision:     00
Title:         NETCONF rpc-error extension
Creation date:     2013-07-11
Group:         Individual Submission
Number of pages: 9
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-ysc-netconf-r= pc-error-extension-00.txt
Status:          http:/= /datatracker.ietf.org/doc/draft-ysc-netconf-rpc-error-extension
Htmlized:        http://tools.ietf.= org/html/draft-ysc-netconf-rpc-error-extension-00


Abstract:
  The NETCONF is a machine-machine interface, it is easy to expan= d.
  This document will expand the rpc-error message to make multipl= e
  language support easily.





The IETF Secretariat

Thank you,
Tina

On Jul 9, 2013, at 11:25 AM, "Andy Bierman" <andy@yumaworks.com> wrote:

On Tue, Jul 9, 2013 at 11:02 AM, Tina TSOU <Tina.Tsou.Zouting@huawei.com> wrote:<= /span>
Dear all,

Mehmet asked me to move below offline discu= ssion to the mailing list.

My co-author and I who are preparing an Int= ernet Draft about the extension
of rpc-error to support multiple language, = refer the rfc6243 and several
other RFCs, there is no YANG Module definit= ion for rpc-error, it's defined
in details in the netconf.xsd.

It seems YANG module for RPC in current RFC= s mainly takes care the input,
but pays less attention on output, we are w= ondering if there is any
background or reasons.


I wanted something like this, because it is in yuma-netconf.yang,
and ietf-netconf.yang was derived from that module:

http://www.netconfcentral.org/modulereport/yuma-netconf= #RpcDataReplyType.659

There is already a definition of <rpc-error> contents (rpcError= Type grouping)
and I needed a YANG extension to define the xml:lang attribute:

http://www.netconfcentral.org/modulereport/yuma-netconf#LangS= tring.210


What do you think about this?

NETCONF error-message already supports the xml:lang attribute.=
Are you proposing to apply this attribute to other fields?
That is the only one of type 'string'.

 error-message:  Contains a string suitable for human displ= ay that
     describes the error condition.  Th= is element will not be present
     if no appropriate message is provided f= or a particular error
     condition.  This element SHOULD in= clude an "xml:lang" attribute as
     defined in [W3C.REC-xml-20001006] and d= iscussed in [RFC3470].





Thank you,

Tina



Andy
--_000_C0BAAF6D8CEF4BE3987C969D6C37172Fhuaweicom_-- From dew@tx.technion.ac.il Sun Jul 14 06:43:22 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A7011E8124 for ; Sun, 14 Jul 2013 06:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4i9G3Ha1wti for ; Sun, 14 Jul 2013 06:43:17 -0700 (PDT) Received: from mailgw13.technion.ac.il (mailgw13.technion.ac.il [132.68.225.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFF421F9D9A for ; Sun, 14 Jul 2013 06:43:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsCAF+k4lGERAEijGdsb2JhbABagzpPgwa+RYEHFg4BAQEnPIIjAQEEASMVQQULCxoCJgICLCsZiAoGDKUjiFmIB4EmjgszBxaCQjNtA4khjjqBKo5VhGQ X-IronPort-AV: E=Sophos;i="4.89,663,1367960400"; d="scan'208";a="79592305" Received: from webmail.technion.ac.il ([132.68.1.34]) by mailgw13.technion.ac.il with ESMTP; 14 Jul 2013 16:43:13 +0300 Received: by webmail.technion.ac.il (Postfix, from userid 48) id 5D21D1000F6; Sun, 14 Jul 2013 16:43:12 +0300 (IDT) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by webmail.technion.ac.il (Horde Framework) with HTTP; Sun, 14 Jul 2013 16:43:12 +0300 Date: Sun, 14 Jul 2013 16:43:12 +0300 Message-ID: <20130714164312.Horde.AzrPeb0xoaGgwcSDCfcvlA1@webmail.technion.ac.il> From: Tal Mizrahi To: netconf@ietf.org References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> In-Reply-To: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> User-Agent: Internet Messaging Program (IMP) H5 (6.0.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: moses@ee.technion.ac.il Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 13:43:22 -0000 Hello, We plan to present this draft in Berlin. Any further comments/questions will be welcome - we will try to address the major issues in our presentation. Thanks, Tal. Quoting Tal Mizrahi : > Hi, > > We have submitted a new draft titled =E2=80=9CTime Capability in NETCONF= =E2=80=9D. > http://tools.ietf.org/html/draft-mm-netconf-time-capability-00 > > Any comments will be welcome. > Thanks, > Tal Mizrahi. From robert.varga@pantheon.sk Mon Jul 15 02:36:16 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9704021F9FAA for ; Mon, 15 Jul 2013 02:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bNFF5-rA0iG for ; Mon, 15 Jul 2013 02:36:09 -0700 (PDT) Received: from amalka.pantheon.sk (amalka.pantheon.sk [81.89.59.174]) by ietfa.amsl.com (Postfix) with ESMTP id DDBFB21F9E6B for ; Mon, 15 Jul 2013 02:36:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id 5DFC7226D8 for ; Mon, 15 Jul 2013 11:36:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at pantheon.sk Authentication-Results: amalka.pantheon.sk (amavisd-new); dkim=pass (1024-bit key) header.d=pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwZnUrRl-KjJ for ; Mon, 15 Jul 2013 11:35:56 +0200 (CEST) Received: from cipisek.dmz.pantheon.local (cipisek.pantheon.sk [81.89.59.176]) by amalka.pantheon.sk (Postfix) with ESMTP for ; Mon, 15 Jul 2013 11:35:56 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 424E1FF6AE for ; Mon, 15 Jul 2013 11:35:56 +0200 (CEST) Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xdBoS2laRjtI for ; Mon, 15 Jul 2013 11:35:55 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 96F151068B1 for ; Mon, 15 Jul 2013 11:35:55 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.7.1 cipisek.dmz.pantheon.local 96F151068B1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.sk; s=D7204E10-2735-11E2-9595-0BDFE9028503; t=1373880955; bh=+PhyoOEHEUKrjfasMvu/dvo3fVRZ4CWG3WTzEQot4O8=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=RNEJM6eDNKMQK8BN5zoG6jImMQBvzZIdL2svC778bstWXhTOC5FsyUKbGD7cEbr9s FRTunwbnZEvwyTiY/FcfmjehwXh3cj1bVVFjUsqXsO1ZVb7VeMbO13oVqxDl8TsB8n O2v9Bg4PE9YRhgUpWq1nYBVyKdCM6CYLP7XdEqtQ= X-Virus-Scanned: amavisd-new at pantheon.sk Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XJ3dxFWbmDPF for ; Mon, 15 Jul 2013 11:35:55 +0200 (CEST) Received: from [172.16.4.80] (unknown [172.16.4.80]) by cipisek.dmz.pantheon.local (Postfix) with ESMTPSA id 63E95FF6AE for ; Mon, 15 Jul 2013 11:35:55 +0200 (CEST) Message-ID: <51E3C275.7090109@pantheon.sk> Date: Mon, 15 Jul 2013 11:35:49 +0200 From: Robert Varga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: netconf@ietf.org References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local> In-Reply-To: <20130711072314.GA69009@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 09:36:16 -0000 On 07/11/2013 09:23 AM, Juergen Schoenwaelder wrote: > On Thu, Jul 11, 2013 at 08:22:23AM +0200, Robert Varga wrote: >> Hi everyone, >> >> I have just uploaded a new draft specifying an extension to NETCONF >> protocol which allows the message encoding to be switched to >> Efficient XML Interchange (EXI). > Did you implement this? If so, what is the gain in We do have a limited prototype. > a) consumed bandwidth, Message sizes are reduced by 28-92% in our testing, depending on payload and whether schema-informed grammar was used. > b) reduced code size, We cannot really measure this, as both XML and EXI codec are external libraries. > c) runtime overhead? We have not measured this one yet. Thanks, Robert From robert.varga@pantheon.sk Mon Jul 15 03:11:21 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D60E21E80A5 for ; Mon, 15 Jul 2013 03:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2P1DcUV8aPw for ; Mon, 15 Jul 2013 03:11:17 -0700 (PDT) Received: from amalka.pantheon.sk (amalka.pantheon.sk [81.89.59.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3AA21E8055 for ; Mon, 15 Jul 2013 03:11:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id 3805520A64 for ; Mon, 15 Jul 2013 12:11:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at pantheon.sk Authentication-Results: amalka.pantheon.sk (amavisd-new); dkim=neutral (1024-bit key) reason="invalid (public key: unsupported version)" header.d=pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vokTqcGGAta1 for ; Mon, 15 Jul 2013 12:11:06 +0200 (CEST) Received: from cipisek.dmz.pantheon.local (cipisek.pantheon.sk [81.89.59.176]) by amalka.pantheon.sk (Postfix) with ESMTP for ; Mon, 15 Jul 2013 12:11:06 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 19D60FFA8B for ; Mon, 15 Jul 2013 12:11:06 +0200 (CEST) Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id lyhCq4X1KaGE for ; Mon, 15 Jul 2013 12:11:04 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 6BEDFFF603 for ; Mon, 15 Jul 2013 12:11:04 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.7.1 cipisek.dmz.pantheon.local 6BEDFFF603 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.sk; s=D7204E10-2735-11E2-9595-0BDFE9028503; t=1373883064; bh=gMxa3U6i1bgayTNgHBafN8U9tosTAe62LBiNtnr75Yc=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=XOljDTR97Exl3J/FRVyb/1suqv756FLn6jJB1nHIYFl+hhnFZS3yT2uVV2W/K21ah 1FF5PvS1Do1lf4WMF+sUAOPMnk9CDIVJyQSqZLgh6sdmqBQVEwqmYU1Q6Jv2BjlGgy KZPCYytdvH4ZPxKUqX2eLh7h+lQG06rL82kaVpBY= X-Virus-Scanned: amavisd-new at pantheon.sk Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 79eaVqGDNfBS for ; Mon, 15 Jul 2013 12:11:04 +0200 (CEST) Received: from [172.16.4.80] (unknown [172.16.4.80]) by cipisek.dmz.pantheon.local (Postfix) with ESMTPSA id 40729FF600 for ; Mon, 15 Jul 2013 12:11:04 +0200 (CEST) Message-ID: <51E3CAB2.2040307@pantheon.sk> Date: Mon, 15 Jul 2013 12:10:58 +0200 From: Robert Varga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: netconf@ietf.org References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local> <20130711074446.GA23993@ruth> <00a201ce7e24$76a04360$63e0ca20$@comcast.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 10:11:21 -0000 On 07/12/2013 10:13 PM, Andy Bierman wrote: > Hi, Hi, > some comments inline... > > On Thu, Jul 11, 2013 at 3:50 AM, ietfdbh wrote: >> Hi, >> >> A major reason for moving from SNMP's ASN.1 binary encoding to XML's >> text-based encoding was operator request. >> >> Operators preferred a solution that was readable on-the-wire, so they could >> look at packet-dumps and see the information being passed. >> Operators found that SNMP packets had to be decoded by (non-standard) >> applications to make the data human-readable, and often an application UI >> never showed the raw varbinds; and the information presented to the operator >> might have been cached, or might have been "interpreted" before being shown >> to the operator. Even when the decoded raw varbinds were shown, such as with >> a MIB browser, the OIDs were not human-friendly. By having the data encoded >> in XML, the on-the-wire packet content was readable in a packet dump, and >> the labels were meaningful. (Of course, with encryption, the content was >> unreadable.) > I don't think operators asked for monitoring data to be returned > in readable format. That was a config-related request. > > I have not studied this draft or EXI in detail yet. > One question: what are the use-cases for enabling > and disabling an "EXI mode"? I prefer the same encoding > for the whole session. There is not definite use case driving it. I was looking for the simplest way to extend NETCONF. Unfortunately, the number of useful EXI encoding parameters and deployment concerns made pure hello-based negotiation quite verbose and ugly. After defining the operation, it seemed a good idea to keep the symmetry and provide a way of going back to plain XML. > FYI: > > Efficient XML Interchange > http://www.w3.org/TR/2011/REC-exi-20110310/ > > IMO, plain and binary JSON looks easier to implement: > > Binary Encodings for JSON > http://www.ietf.org/id/draft-hallambaker-jsonbcd-00.txt It may. On the other hand, you need to translate XML infoset into JSON first, which is not necessary with EXI. > [snip] >> It would also be interesting to discuss the adoption level of each approach. >> EXI was approved in 2011; When was "ssh -C" approved as a standard? >> Do we have any information about how many commercial/open-source toolkits >> support the standards? >> >> I don't know EXI. Wikipedia indicates EXI uses "schema-informed" >> compression, and the decoder needs a copy of the same schema that the >> encoder used . How would this potentially affect Netconf? Assuming multiple >> Netconf clients (NMSes) talk to multiple Netconf servers, does that mean >> that each client must have the managed-device-specific schema for each >> device, and each netconf server must have a copy of the schema used by each >> client? While such an approach might be viable for a web browser/web server >> relationship, where each is hosted on a device that is not very resource >> constrained, but what impact would this have on devices with significant >> resource constraints (as is common with Netconf)? >> > IMO, the encoding is a second order problem. > Real efficiency is derived from the appropriate set > of protocol operations. The standards are behind > industry in this area. > > (If you are scrubbing the floor with a toothbrush, you might > be inclined to invest in better bristle technology ;-) Agreed. It may still prove useful to grow the toothbrush 30% ;-) Thanks, Robert From robert.varga@pantheon.sk Mon Jul 15 05:41:16 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F6211E810A for ; Mon, 15 Jul 2013 05:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpZsG-jJS-r6 for ; Mon, 15 Jul 2013 05:41:11 -0700 (PDT) Received: from amalka.pantheon.sk (amalka.pantheon.sk [81.89.59.174]) by ietfa.amsl.com (Postfix) with ESMTP id 64BA811E80F9 for ; Mon, 15 Jul 2013 05:41:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id 27635211B4 for ; Mon, 15 Jul 2013 14:41:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at pantheon.sk Authentication-Results: amalka.pantheon.sk (amavisd-new); dkim=pass (1024-bit key) header.d=pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8-o1JULVngG for ; Mon, 15 Jul 2013 14:41:05 +0200 (CEST) Received: from cipisek.dmz.pantheon.local (cipisek.pantheon.sk [81.89.59.176]) by amalka.pantheon.sk (Postfix) with ESMTP for ; Mon, 15 Jul 2013 14:41:05 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 2811DFF60D for ; Mon, 15 Jul 2013 14:41:05 +0200 (CEST) Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id BE4XNT0La0xf for ; Mon, 15 Jul 2013 14:41:04 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 8E4F2108036 for ; Mon, 15 Jul 2013 14:41:04 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.7.1 cipisek.dmz.pantheon.local 8E4F2108036 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.sk; s=D7204E10-2735-11E2-9595-0BDFE9028503; t=1373892064; bh=LzFPUDv+kjKetKRtUmZAL+eCcsSmD6IxIIlLRYho5SU=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=pozKb61RLWEWXGaZxPfo4NDjf9HwYPu8lWeppEYKbxCM5GNZYGflqBwnrhq6Qx4v0 tDGw7X10PAZQ4Wbh9EM4gTvzbL4XG28X6ouCX/9n4jI+GurJPBrQ1XxuRTSFX/ERX8 qD1ZIEZTl8TCJI1aVojNC2SteSgGC9SbmEl+v/oI= X-Virus-Scanned: amavisd-new at pantheon.sk Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id r3Eek16SPAYB for ; Mon, 15 Jul 2013 14:41:04 +0200 (CEST) Received: from [172.16.4.49] (unknown [172.16.4.49]) by cipisek.dmz.pantheon.local (Postfix) with ESMTPSA id 6FAF1FF60D for ; Mon, 15 Jul 2013 14:41:04 +0200 (CEST) Message-ID: <51E3EDDB.1030309@pantheon.sk> Date: Mon, 15 Jul 2013 14:40:59 +0200 From: Robert Varga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: netconf@ietf.org References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local> <20130711074446.GA23993@ruth> In-Reply-To: <20130711074446.GA23993@ruth> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 12:41:16 -0000 On 07/11/2013 09:44 AM, Michal 'vorner' Vaner wrote: > Good morning > > On Thu, Jul 11, 2013 at 09:23:14AM +0200, Juergen Schoenwaelder wrote: >> On Thu, Jul 11, 2013 at 08:22:23AM +0200, Robert Varga wrote: >>> I have just uploaded a new draft specifying an extension to NETCONF >>> protocol which allows the message encoding to be switched to >>> Efficient XML Interchange (EXI). >> Did you implement this? If so, what is the gain in >> >> a) consumed bandwidth, >> b) reduced code size, >> c) runtime overhead? > May I suggest to compare it with enabling compression in the underlying ssh > connection, with `ssh -C` or equivalent? Noted, I'll try to get the numbers, though it's gonna take some time. Thanks, Robert From robert.varga@pantheon.sk Mon Jul 15 06:28:34 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17AB21F9971 for ; Mon, 15 Jul 2013 06:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBHzmQprfmww for ; Mon, 15 Jul 2013 06:28:30 -0700 (PDT) Received: from amalka.pantheon.sk (amalka.pantheon.sk [81.89.59.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6A36121F8FD5 for ; Mon, 15 Jul 2013 06:28:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id B8DAF21171 for ; Mon, 15 Jul 2013 15:28:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at pantheon.sk Authentication-Results: amalka.pantheon.sk (amavisd-new); dkim=pass (1024-bit key) header.d=pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyZxd75DqGDY for ; Mon, 15 Jul 2013 15:28:24 +0200 (CEST) Received: from cipisek.dmz.pantheon.local (cipisek.pantheon.sk [81.89.59.176]) by amalka.pantheon.sk (Postfix) with ESMTP for ; Mon, 15 Jul 2013 15:28:24 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 9F933108981 for ; Mon, 15 Jul 2013 15:28:24 +0200 (CEST) Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id VOC-rc6dxbov for ; Mon, 15 Jul 2013 15:28:23 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id B6DB71089A7 for ; Mon, 15 Jul 2013 15:28:23 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.7.1 cipisek.dmz.pantheon.local B6DB71089A7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.sk; s=D7204E10-2735-11E2-9595-0BDFE9028503; t=1373894903; bh=ktWiEi2+TkM3VZdJu1CZhBt3d6aTE+I8B+BLfYxGkwQ=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=pxSujSo1JNGCCevFEvYpu/7hKGxq0kTQLquI7JbNM+i5qTSyA7oyG0ESiSrVqE9Vn 4HXg/L6nMA91JJ4vHUWU0OGTB4auIPBn9Q4+RWKc5b4NzTBDnn052ndM8IYxLq9dN4 ghqUaOQjEd0YlMMHKlnyaBwuV/dldiCg29PZPUmQ= X-Virus-Scanned: amavisd-new at pantheon.sk Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KVBrQ0DBZ2TP for ; Mon, 15 Jul 2013 15:28:23 +0200 (CEST) Received: from [172.16.4.49] (unknown [172.16.4.49]) by cipisek.dmz.pantheon.local (Postfix) with ESMTPSA id 9028BFF8EC for ; Mon, 15 Jul 2013 15:28:23 +0200 (CEST) Message-ID: <51E3F8F2.7070508@pantheon.sk> Date: Mon, 15 Jul 2013 15:28:18 +0200 From: Robert Varga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: netconf@ietf.org References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local> <20130711074446.GA23993@ruth> <00a201ce7e24$76a04360$63e0ca20$@comcast.net> In-Reply-To: <00a201ce7e24$76a04360$63e0ca20$@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 13:28:34 -0000 On 07/11/2013 12:50 PM, ietfdbh wrote: > Hi, Hi, > A major reason for moving from SNMP's ASN.1 binary encoding to XML's > text-based encoding was operator request. > > Operators preferred a solution that was readable on-the-wire, so they could > look at packet-dumps and see the information being passed. > Operators found that SNMP packets had to be decoded by (non-standard) > applications to make the data human-readable, and often an application UI > never showed the raw varbinds; and the information presented to the operator > might have been cached, or might have been "interpreted" before being shown > to the operator. Even when the decoded raw varbinds were shown, such as with > a MIB browser, the OIDs were not human-friendly. By having the data encoded > in XML, the on-the-wire packet content was readable in a packet dump, and > the labels were meaningful. (Of course, with encryption, the content was > unreadable.) > > I would be interested in seeing a discussion of these points in a comparison > of XML, EXI, and "ssh -C" encodings. Such discussion should probably include > whether popular packet sniffing tools, both commercial and open source, > supported the formats, and at what level in the transfer of information > between systems (i.e. in the network stack and/or the Netconf architecture) > an operator can access something human-readable. > > It would also be interesting to discuss the adoption level of each approach. > EXI was approved in 2011; When was "ssh -C" approved as a standard? > Do we have any information about how many commercial/open-source toolkits > support the standards? SSH compression is described in RFC4253 (2006), zlib compression in RFC1950(1996). I am not sure about commercial toolkits, but openssh supported it as far back as I remember (~2002). As for EXI, existing implementations are listed at http://www.w3.org/XML/EXI/. There are three open-source (GPLv2, BSD-3 for Java, Apache 2.0 for C/C++) and one commercial product. > I don't know EXI. Wikipedia indicates EXI uses "schema-informed" > compression, and the decoder needs a copy of the same schema that the > encoder used . How would this potentially affect Netconf? Assuming multiple > Netconf clients (NMSes) talk to multiple Netconf servers, does that mean > that each client must have the managed-device-specific schema for each > device, and each netconf server must have a copy of the schema used by each > client? While such an approach might be viable for a web browser/web server > relationship, where each is hosted on a device that is not very resource > constrained, but what impact would this have on devices with significant > resource constraints (as is common with Netconf)? Fortunately, EXI can work in absence of schemas, Current document defines two modes of schema-informed operation, one of which relies only on EXI-specified XML schema. The questions you raise are completely valid and need a full state synchronization mechanism to solve. XEP-0322 (http://xmpp.org/extensions/xep-0322.html) tries to do that for XMPP, but honestly I could not figure out a clean&easy way of doing the equivalent within NETCONF. There is a informational I-D dealing with schema synchronization, https://tools.ietf.org/html/draft-doi-exi-messaging-requirements-01, but I am afraid it is not applicable to NETCONF at this stage. My preference would be to keep things simple for now and deal with schema synchronization in a separate document, Thanks, Robert From robert.varga@pantheon.sk Mon Jul 15 12:28:04 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B8821E8129 for ; Mon, 15 Jul 2013 12:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.094 X-Spam-Level: X-Spam-Status: No, score=-0.094 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0YuPzFG816r for ; Mon, 15 Jul 2013 12:27:58 -0700 (PDT) Received: from amalka.pantheon.sk (amalka.pantheon.sk [81.89.59.174]) by ietfa.amsl.com (Postfix) with ESMTP id 08DB011E81FD for ; Mon, 15 Jul 2013 12:27:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id A34CF1FF4F for ; Mon, 15 Jul 2013 21:27:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at pantheon.sk Authentication-Results: amalka.pantheon.sk (amavisd-new); dkim=neutral reason="invalid (public key: unsupported version)" header.d=pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-7eRECIA_nI for ; Mon, 15 Jul 2013 21:27:39 +0200 (CEST) Received: from cipisek.dmz.pantheon.local (cipisek.pantheon.sk [81.89.59.176]) by amalka.pantheon.sk (Postfix) with ESMTP for ; Mon, 15 Jul 2013 21:27:39 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id CC11CF53A0 for ; Mon, 15 Jul 2013 21:27:39 +0200 (CEST) Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Qi-Ua-YJo2vR for ; Mon, 15 Jul 2013 21:27:39 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 41556FF58E for ; Mon, 15 Jul 2013 21:27:39 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.7.1 cipisek.dmz.pantheon.local 41556FF58E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.sk; s=D7204E10-2735-11E2-9595-0BDFE9028503; t=1373916459; bh=Aai6NsOSINh36ghnw1+xEf01BQECqzD2ZYuLifTHUT4=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=lDnYe0PvN5f0suUVg1xcSkd4cTlTZvH2d5pdsb9DuNNCDGM9bFTamsnFWa5HsfeMG ZwfMCe1/idM2HIjzv5ht+h9CpJbHIL8Fg+jbn6Ydb39z82D0VPqEprYzgxtkh07Rap Aa3WDm/QPtl/b8g5nVuwoUByeMOrLtqr/dYQ5Ta4= X-Virus-Scanned: amavisd-new at pantheon.sk Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qreDGF5WtOhd for ; Mon, 15 Jul 2013 21:27:39 +0200 (CEST) Received: from [172.16.0.226] (188-167-34-16.dynamic.chello.sk [188.167.34.16]) by cipisek.dmz.pantheon.local (Postfix) with ESMTPSA id D03FEF53A0 for ; Mon, 15 Jul 2013 21:27:38 +0200 (CEST) Message-ID: <51E44D24.90808@pantheon.sk> Date: Mon, 15 Jul 2013 21:27:32 +0200 From: Robert Varga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: netconf@ietf.org References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local> <20130711074446.GA23993@ruth> <00a201ce7e24$76a04360$63e0ca20$@comcast.net> <00a601ce7e29$4555c190$d00144b0$@comcast.net> In-Reply-To: <00a601ce7e29$4555c190$d00144b0$@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:28:04 -0000 On 07/11/2013 01:24 PM, David Harrington wrote: > Hi, > > Since EXI is schema-informed, would a EXI-standard-compliant implementation > work with a YANG schema, or would a compliant implementation require a > particular type of schema, such as W3C-standard XML Schema (XSD)? EXI as an encoding format itself is not tied to a particular schema language, but the EXI format specification (1.0) only defines how to derive EXI grammars from an XML Schema. > At what point in the process does EXI becomes schema-informed? Is this a > special schema that is used only during the encode/decode steps, totally > independent of where in the process a YANG schema or RELAX-NG schema would > get used with Netconf? I am not sure I understand the question. EXI does not require the entire data set to be covered by a schema -- it will happily generate dynamic grammar to cover for parts which lie outside of the schema being used. What this means is that we can use these options, listed in order of increasing size efficiency: - schema-less EXI - schema-less EXI with built-in XML schema types - schema-informed EXI with static protocol schema (e.g. just use netconf.xsd from RFC6241) - schema-informed EXI with dynamic data-dependent schemas The current document covers the first three options. Bye, Robert From andy@yumaworks.com Tue Jul 16 09:13:21 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F56821E8050 for ; Tue, 16 Jul 2013 09:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTyIZjaW7Ccg for ; Tue, 16 Jul 2013 09:13:16 -0700 (PDT) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0260211E80D5 for ; Tue, 16 Jul 2013 09:13:15 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb1so949466pad.9 for ; Tue, 16 Jul 2013 09:13:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=gG8oyLKR+OPcx8gM4GsW9GARupc+Xp3ditg4+8r9D7U=; b=cXAvXmCEcUMJx3Hgo3lz/RFj5sq5f1Bka1GHc5D01VUN9p0Y4u5sDI+Tt+tpul2MAE qsBwjEp1kotX4sov2P27XZdTqrozh3/hnax4KwBGjivlg4/s8DNS3Na9oHvEgZ9kGScR 6MdtUa4DYkwT0hmk08KcLqmQKyo/rofBnpCTK7drW6SU2oBnsE0Gt2WZ/2bgAUltV5nw sSvCf4ZgOfHvBU+uvW941ow7uGcyGQdcsWZzrHPUlGJRuFfAj8k4bSI2mnInoIc1D9ap BQAfoewA5iNjyy8iyXC9bvAXzZ57zer9Ps1b1mh5C/PaYPhRyVe133L1NV94CtQ5VOuz L48Q== MIME-Version: 1.0 X-Received: by 10.68.201.98 with SMTP id jz2mr2317840pbc.56.1373991195734; Tue, 16 Jul 2013 09:13:15 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 16 Jul 2013 09:13:15 -0700 (PDT) In-Reply-To: <20130708120104.GA55763@elstar.local> References: <20130706184312.GA51144@elstar.local> <20130706202225.GA51435@elstar.local> <20130708120104.GA55763@elstar.local> Date: Tue, 16 Jul 2013 09:13:15 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Netconf Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlFSlaciIiSj/vsRCewxaKMhcl+zbVUU+ePF29NVPlJ2Zrobog1AdJGdX+VYxb6t9XXgpb4 Subject: Re: [Netconf] standard YANG RFC publication (was 5539bis comments) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:13:21 -0000 On Mon, Jul 8, 2013 at 5:01 AM, Juergen Schoenwaelder wrote: > On Sat, Jul 06, 2013 at 01:44:16PM -0700, Andy Bierman wrote: >> Hi, >> >> I don't mind the /netconf container. >> The disagreement is really over sub-modules vs. augment. >> IMO, augment is cleaner because the extended RFC does >> not have to be re-published, and the has the revision date. >> > > Let me at least clarify that > > * submodules do augment - see the examples > I meant external module augment. I understand the draft uses an augment-stmt to add all its contents to a container node in another submodule. An external module augment does not require that an include-stmt be added to the main module. > * there is no need to republish an extended RFC, you republish the > main module; a WG can of course at their discretion choose to > republish everything this is the most acceptable approach. > > * the updated module of course has a new revision date which is > carried in the (and it uses import by revision) What if a WG using this approach needs to update more than 1 submodule at a time, or it takes so long another new submodule starts before the other "new main module" is published? Are all drafts combined into 1 RFC or are 2 main modules in progress at the same time? Keeping all submodules in 1 RFC makes the most sense. In this case, using submodules is purely for style. So I am changing my objection -- if all new NETCONF config objects are kept in the same RFC (Obsoletes, not Updates), then using submodules is not a problem. > > /js > Andy From j.schoenwaelder@jacobs-university.de Tue Jul 16 11:19:08 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FD921E8083 for ; Tue, 16 Jul 2013 11:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.126 X-Spam-Level: X-Spam-Status: No, score=-103.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suSFkNIwWWkx for ; Tue, 16 Jul 2013 11:18:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9A21E8056 for ; Tue, 16 Jul 2013 11:18:50 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDBFF20A6D; Tue, 16 Jul 2013 20:18:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0iSlEWNApr21; Tue, 16 Jul 2013 20:18:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FA4020968; Tue, 16 Jul 2013 20:18:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C1C8E273EE39; Tue, 16 Jul 2013 20:18:45 +0200 (CEST) Date: Tue, 16 Jul 2013 20:18:45 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130716181845.GB85215@elstar.local> Mail-Followup-To: Andy Bierman , Netconf References: <20130706184312.GA51144@elstar.local> <20130706202225.GA51435@elstar.local> <20130708120104.GA55763@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] standard YANG RFC publication (was 5539bis comments) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 18:19:09 -0000 On Tue, Jul 16, 2013 at 09:13:15AM -0700, Andy Bierman wrote: > > * the updated module of course has a new revision date which is > > carried in the (and it uses import by revision) > > What if a WG using this approach needs to update more than > 1 submodule at a time, or it takes so long another new submodule > starts before the other "new main module" is published? > Are all drafts combined into 1 RFC or are 2 main modules > in progress at the same time? The idea is that WGs have the flexibility to do whatever makes most sense. Even in the extreme cases when there are multiple concurrent I-Ds sitting in the RFC editor queue and they get processed together, I assume the RFC editor with the help of the authors and chairs will figure out how to serialize things properly. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From balazs.lengyel@ericsson.com Wed Jul 17 04:14:59 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D5B21F9C70 for ; Wed, 17 Jul 2013 04:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yAWJC9e4xRO for ; Wed, 17 Jul 2013 04:14:53 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8D19C21F9C68 for ; Wed, 17 Jul 2013 04:14:52 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-e9-51e67cab9229 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3A.AD.06741.BAC76E15; Wed, 17 Jul 2013 13:14:51 +0200 (CEST) Received: from [159.107.197.37] (153.88.183.147) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.2.328.9; Wed, 17 Jul 2013 13:14:50 +0200 Message-ID: <51E67CAA.5000604@ericsson.com> Date: Wed, 17 Jul 2013 13:14:50 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andy Bierman , Netconf References: <20130706184312.GA51144@elstar.local> <20130706202225.GA51435@elstar.local> <20130708120104.GA55763@elstar.local> <20130716181845.GB85215@elstar.local> In-Reply-To: <20130716181845.GB85215@elstar.local> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvre7qmmeBBmd6lCweHJnFbjF1021W ByaPJUt+Mnm09F9kCWCK4rJJSc3JLEst0rdL4MrYdbKHrWAub8W15x+YGxj7uboYOTkkBEwk 7hyYyA5hi0lcuLeerYuRi0NI4DCjxNk/z9ghnDWMEj8mTmMCqeIV0JY4PeExI4jNIqAqcXzu chYQm03ASGJq/3kwW1QgSqK1dyozRL2gxMmZT8DiIgKOEnu+TgDbJizgLfH34jeoBduZJba0 dQIVcXBwAg1a/T0epIZZwFbiwpzrLBC2vMT2t3PAZgoJaEg8vPCXdQKjwCwkK2YhaZmFpGUB I/MqRvbcxMyc9HLDTYzA4Du45bfuDsZT50QOMUpzsCiJ827SOxMoJJCeWJKanZpakFoUX1Sa k1p8iJGJg1OqgTFDUfjTptXJizIm7Z9SG9bOFXvUf33opvqW5RdnfvTM2euketJt6swAbZ++ mPSiOdyysk8W/d1vJCof+kUuKKBVK3bXqtt61czn/5p+z9B/HjdldoQW0z/XnTIrtvD/6PRI VlbSPt1b8+eoYinH01Q/5++z7JQZXn9kkgidkh2Vn7rTf+Kcx0osxRmJhlrMRcWJAM2o2U4M AgAA Subject: Re: [Netconf] standard YANG RFC publication (was 5539bis comments) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 11:14:59 -0000 Hello, Having the same module published in many RFCs is a recipe for mistakes. People will keep using the module from the incorrect RFC. Also why bother people with keeping track of the correct version if it does not need to be done. AFAIK one of the main reasons for having the augment statement was that ONLY the augmenting module needs to be touched. If we thought that was an important idea, why are we not following it now. (I don't really see any advantages of the submodule approach.) So I would like a separate /netconf module that is not republished. Balazs On 2013-07-16 20:18, Juergen Schoenwaelder wrote: > On Tue, Jul 16, 2013 at 09:13:15AM -0700, Andy Bierman wrote: > >>> * the updated module of course has a new revision date which is >>> carried in the (and it uses import by revision) >> What if a WG using this approach needs to update more than >> 1 submodule at a time, or it takes so long another new submodule >> starts before the other "new main module" is published? >> Are all drafts combined into 1 RFC or are 2 main modules >> in progress at the same time? > The idea is that WGs have the flexibility to do whatever makes most > sense. Even in the extreme cases when there are multiple concurrent > I-Ds sitting in the RFC editor queue and they get processed together, > I assume the RFC editor with the help of the authors and chairs will > figure out how to serialize things properly. > > /js > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From balazs.lengyel@ericsson.com Thu Jul 18 05:35:39 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D8021E80CA for ; Thu, 18 Jul 2013 05:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WOUAZLvwujO for ; Thu, 18 Jul 2013 05:35:34 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F2AD521E80DA for ; Thu, 18 Jul 2013 05:35:33 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-fe-51e7e114aa21 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 05.45.06741.411E7E15; Thu, 18 Jul 2013 14:35:32 +0200 (CEST) Received: from [159.107.197.93] (153.88.183.147) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.328.9; Thu, 18 Jul 2013 14:35:28 +0200 Message-ID: <51E7E10F.7060209@ericsson.com> Date: Thu, 18 Jul 2013 14:35:27 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andy Bierman References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvra7Iw+eBBluuGVg8ODKL3WLR5ZNs FhMXf2eymLrpNqsDi8f2aQ/ZPZYs+cnkMenhNyaPlv6LLAEsUVw2Kak5mWWpRfp2CVwZbRe/ sxTcV6jo2nGYqYFxiVQXIyeHhICJxPPL+9ghbDGJC/fWs3UxcnEICRxmlLj7eRczhLOGUWLK /9nMIFW8AtoSe9oawWwWAVWJrrVPwGw2ASOJqf3nWUBsUYEoidbeqVD1ghInZz4Bi4sA1V+Y OxEsziwQIbHp2V82EFtYwFXi5ek7UMumMUr0zJwCdhKnQKDE04XrWLsYOYAa7CUebC2D6JWX aN4KcY+QgIbEwwt/WScwCs5Csm4WQscsJB0LGJlXMbLnJmbmpJcbbmIEhu7BLb91dzCeOidy iFGag0VJnHeT3plAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYw1suuVlrru/KraV73plCZH iWXCnufTz6wwWJc6O9yx+/Dtq6djErOVM/6GzQ6/PO2+0+NTL/0Zg0sL+rOnZS6cdUn75DTT acqPX9f/K0vanLE5QoFPZ+eiyTZ1JZfnPb6Xtc+vaefT7yFuk5x4b/07opHIJfR2lnbCpmXL dPyKnrF+FVWbFa2qxFKckWioxVxUnAgAmISZMysCAAA= Cc: netconf@ietf.org, moses@ee.technion.ac.il Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 12:35:39 -0000 Hello, - The idea that scheduled time should be the required completion time for an operation is unfortunate. That assumes a device can estimate how long a complex configuration operation will take. That is already a a risky assumption. Even worse some operations might depend on external factors like traffic load, I/O related delays, interaction with external nodes. It is impossible to estimate these delays. - because of the above IMO nanosecond precision for timing is not realistic. The YANG time types are good enough. Anyway in many protocols we have timers on the scale of seconds, so coordinating configuration changes between nodes with milli/nanosecond precision does not look like a sensible goal. - there must be a way to check pending scheduled operations. This has some interesting access control issues as well. Can I see other peoples pending operations? Even if I can read them, what if I do not have rights to a managed object included in a pending operation? I should not be able to read it. - there must be a way to remove pending scheduled operations. - often a configuration session will consist of multiple operations: (lock, edit-config, unlock), (lock, discard-changes, edit-config, commit, unlock). If I can only schedule single operations does that mean I can not use lock? If I want to schedule commit, should I keep the running and the candidate configurations locked to ensure I commit, what I really want? What if my session is closed e.g. by a network timeout? - if a management user is removed/undefined will his pending operations also be removed, or will they stand there and fail at the scheduled execution time? The latter case will confuse people that do not know the user was removed. - generally timed operations work nicely if no one else configures the node while my changes are pending. What is the proposed method to ensure this? regards Balazs On 2013-07-08 16:27, Andy Bierman wrote: > Hi, > > I do not support a general time-scheduled protocol operation mechanism for > all NETCONF operations. There is one interesting use-case mentioned: > synchronized (or on :writable-running) operations > across multiple servers. > > The proposal doesn't actually work within NETCONF because requests > within a single session are serialized. This solution seems to send 1 > > when the operation is finally executed. How does the client know the operation > was scheduled successfully? IMO, a better solution would be an immediate > (scheduled OK) and the execution results sent in a . > > How do clients monitor what operations are pending? > > What if the NACM rules change while the operation is pending? > Does access control get checked twice? Clients should not be able > to schedule operations they are not permitted to execute. > > What if a session is lost or closed before its scheduled operation is started? > > What if the server reboots while operations are pending? > > IMO, YANG date-and-time is better time parameter than 'seconds since 1970'. > It is already supported by NETCONF servers. > > How does a client cancel an operation? > Can client A cancel operations for client B, > assuming client A is allowed to invoke ? > > > > Andy > > On Mon, Jul 8, 2013 at 12:48 AM, Tal Mizrahi wrote: >> Hi, >> >> We have submitted a new draft titled “Time Capability in NETCONF”. >> http://tools.ietf.org/html/draft-mm-netconf-time-capability-00 >> >> Any comments will be welcome. >> Thanks, >> Tal Mizrahi. >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From andy@yumaworks.com Thu Jul 18 06:57:08 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5326211E8135 for ; Thu, 18 Jul 2013 06:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njlmmSGQDD87 for ; Thu, 18 Jul 2013 06:57:04 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 232BF11E8140 for ; Thu, 18 Jul 2013 06:56:50 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id lj1so3238776pab.31 for ; Thu, 18 Jul 2013 06:56:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=lnqSLjDwkQ4oLsFtAxEbJiDycb7p+prFIdQInImDgtk=; b=g1DETlf1aKBI3vSMMbhCqre8yHGH2qMIA/SMwjpw3RpcPYaLuu3HgtxlCKFk1rZgeV Ig/0rpWpqmJCDAUBL/Y/GKErl8XZn0RUnSIBhYDFl4B89gLQZEQr0qvXf2uizY9wmzlW EAm1cN/hnq/ncL1/f16K5j7ujPRE2TdM6f1wqee30IH3iXAxNTAgec+CMM9eBdfjyB2N mXppDwh6z3bKvAu3pSx6D1tlVao8m6u1gA/cLq2x3vh23yGct/CN74Rz4/unbjCFfU2X YPW5M84tE5VHxcZ5/hSA8cA2jL6+Eq85YMwddXLTvkJtd1KdJR0pXjhfzOPdQhF87mZ5 QKEQ== MIME-Version: 1.0 X-Received: by 10.66.249.202 with SMTP id yw10mr13096057pac.145.1374155809128; Thu, 18 Jul 2013 06:56:49 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Thu, 18 Jul 2013 06:56:48 -0700 (PDT) In-Reply-To: <51E7E10F.7060209@ericsson.com> References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <51E7E10F.7060209@ericsson.com> Date: Thu, 18 Jul 2013 06:56:48 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkcumlz5W3DKv1daF9nYyvsRZiXHx7fHY5otBRzZB77QFE3TFGM8Tja/jBvlx7Dzo7bRfZ+ Cc: netconf@ietf.org, moses@ee.technion.ac.il Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 13:57:08 -0000 Hi, There are lots of operational problems with delayed operations. I like the solution in draft-kwatsen-conditional-enablement-00 better than this one because it covers more use-cases and seems more tractable. For example: * in order to stage time-triggered-config, the user and access control can be checked once at the time the request is made. * the normal RPC mechanism is used (1 request and 1 immediate reply) * the staged config can be viewed or deleted with standard protocol operations, using standard access control [Not clear what filters would need to be added.] * conditional-enablement easily handles periodic config to support maintenance windows, URL blocking, etc. * time-shift applies to config activation, which is much less complicated than delaying arbitrary protocol operations. Andy On Thu, Jul 18, 2013 at 5:35 AM, Balazs Lengyel wrote: > Hello, > - The idea that scheduled time should be the required completion time for= an > operation is unfortunate. That assumes a device can estimate how long a > complex configuration operation will take. That is already a a risky > assumption. Even worse some operations might depend on external factors l= ike > traffic load, I/O related delays, interaction with external nodes. It is > impossible to estimate these delays. > - because of the above IMO nanosecond precision for timing is not realist= ic. > The YANG time types are good enough. Anyway in many protocols we have tim= ers > on the scale of seconds, so coordinating configuration changes between no= des > with milli/nanosecond precision does not look like a sensible goal. > > - there must be a way to check pending scheduled operations. This has som= e > interesting access control issues as well. Can I see other peoples pendin= g > operations? Even if I can read them, what if I do not have rights to a > managed object included in a pending operation? I should not be able to r= ead > it. > - there must be a way to remove pending scheduled operations. > > - often a configuration session will consist of multiple operations: (loc= k, > edit-config, unlock), (lock, discard-changes, edit-config, commit, unlock= ). > If I can only schedule single operations does that mean I can not use loc= k? > If I want to schedule commit, should I keep the running and the candidate > configurations locked to ensure I commit, what I really want? What if my > session is closed e.g. by a network timeout? > > - if a management user is removed/undefined will his pending operations a= lso > be removed, or will they stand there and fail at the scheduled execution > time? The latter case will confuse people that do not know the user was > removed. > > - generally timed operations work nicely if no one else configures the no= de > while my changes are pending. What is the proposed method to ensure this? > > regards Balazs > > On 2013-07-08 16:27, Andy Bierman wrote: >> >> Hi, >> >> I do not support a general time-scheduled protocol operation mechanism f= or >> all NETCONF operations. There is one interesting use-case mentioned: >> synchronized (or on :writable-running) operations >> across multiple servers. >> >> The proposal doesn't actually work within NETCONF because requests >> within a single session are serialized. This solution seems to send 1 >> >> when the operation is finally executed. How does the client know the >> operation >> was scheduled successfully? IMO, a better solution would be an immediat= e >> (scheduled OK) and the execution results sent in a >> . >> >> How do clients monitor what operations are pending? >> >> What if the NACM rules change while the operation is pending? >> Does access control get checked twice? Clients should not be able >> to schedule operations they are not permitted to execute. >> >> What if a session is lost or closed before its scheduled operation is >> started? >> >> What if the server reboots while operations are pending? >> >> IMO, YANG date-and-time is better time parameter than 'seconds since >> 1970'. >> It is already supported by NETCONF servers. >> >> How does a client cancel an operation? >> Can client A cancel operations for client B, >> assuming client A is allowed to invoke ? >> >> >> >> Andy >> >> On Mon, Jul 8, 2013 at 12:48 AM, Tal Mizrahi >> wrote: >>> >>> Hi, >>> >>> We have submitted a new draft titled =93Time Capability in NETCONF=94. >>> http://tools.ietf.org/html/draft-mm-netconf-time-capability-00 >>> >>> Any comments will be welcome. >>> Thanks, >>> Tal Mizrahi. >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > -- > Balazs Lengyel Ericsson Hungary Ltd. > System Manager > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > From dew@tx.technion.ac.il Thu Jul 18 07:31:22 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED92911E8152 for ; Thu, 18 Jul 2013 07:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8VeaMtFw9Ia for ; Thu, 18 Jul 2013 07:31:16 -0700 (PDT) Received: from mailgw13.technion.ac.il (mailgw13.technion.ac.il [132.68.225.13]) by ietfa.amsl.com (Postfix) with ESMTP id 03F0A11E814B for ; Thu, 18 Jul 2013 07:31:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIAAOT651GERAEil2dsb2JhbABSCIM7UIMGvT2BDhYOAQEBAQEIFgc8giQBAQEBAgEBAQEgFTYLBQsLGAICJgICJwUrBhMbh28GDKRFiUOIB4EojSUMgQMzB4JbgSEDiSKOOoEqjlWEZIFu X-IronPort-AV: E=Sophos;i="4.89,694,1367960400"; d="scan'208";a="80125668" Received: from webmail.technion.ac.il ([132.68.1.34]) by mailgw13.technion.ac.il with ESMTP; 18 Jul 2013 17:31:12 +0300 Received: by webmail.technion.ac.il (Postfix, from userid 48) id 591FF1000FE; Thu, 18 Jul 2013 17:31:11 +0300 (IDT) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by webmail.technion.ac.il (Horde Framework) with HTTP; Thu, 18 Jul 2013 17:31:11 +0300 Date: Thu, 18 Jul 2013 17:31:11 +0300 Message-ID: <20130718173111.Horde.JRolqvI3YtZZPzknuNyqkQ1@webmail.technion.ac.il> From: Tal Mizrahi To: Balazs Lengyel References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <51E7E10F.7060209@ericsson.com> In-Reply-To: <51E7E10F.7060209@ericsson.com> User-Agent: Internet Messaging Program (IMP) H5 (6.0.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: moses@ee.technion.ac.il, netconf@ietf.org Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 14:31:22 -0000 Hi Balazs, Thanks for reviewing the draft. I think most of your questions/comments (as well as Andy's) are valid questions that we plan to address in the next draft, e.g., mutual exclusion issues, managing pending operations, lost/closed session, etc. > - The idea that scheduled time should be the required completion > time for an operation is unfortunate. That assumes a device can > estimate how long a complex configuration operation will take. That > is already a a risky assumption. Even worse some operations might > depend on external factors like traffic load, I/O related delays, > interaction with external nodes. It is impossible to estimate these > delays. > - because of the above IMO nanosecond precision for timing is not > realistic. The YANG time types are good enough. Anyway in many > protocols we have timers on the scale of seconds, so coordinating > configuration changes between nodes with milli/nanosecond precision > does not look like a sensible goal. I agree that in some cases it may be harder to predict the completion time of an operation than others. Indeed, a commit operation may be an example where your scheduling time will have a lower accuracy. However, consider a simpler case where you want to do a scheduled of a single leaf. In this case you can schedule the update fairly accurately. We are trying to provide a tool that will allow accurate scheduling where possible, which is why we are targeting a higher resolution than tenth-of-a-second. I agree that we do not need a nanosecond resolution, however, it would be best if we chose one of the existing time formats already used in the IETF rather than invent a new one, and if we indeed agree that we need to target a better resolution than a tenth-of-a-second, the PTP/NTP time formats both seem like good candidates. > - often a configuration session will consist of multiple operations: > (lock, edit-config, unlock), (lock, discard-changes, edit-config, > commit, unlock). If I can only schedule single operations does that > mean I can not use lock? For example, when you invoke a (lock, edit-config, unlock) procedure, the and will typically be performed according to the 'normal' paradigm, i.e., without using the time element, whereas the will include the time element, allowing the edit-config to be scheduled in a coordinated way. Thanks, Tal. Quoting Balazs Lengyel : > Hello, > - The idea that scheduled time should be the required completion > time for an operation is unfortunate. That assumes a device can > estimate how long a complex configuration operation will take. That > is already a a risky assumption. Even worse some operations might > depend on external factors like traffic load, I/O related delays, > interaction with external nodes. It is impossible to estimate these > delays. > - because of the above IMO nanosecond precision for timing is not > realistic. The YANG time types are good enough. Anyway in many > protocols we have timers on the scale of seconds, so coordinating > configuration changes between nodes with milli/nanosecond precision > does not look like a sensible goal. > > - there must be a way to check pending scheduled operations. This > has some interesting access control issues as well. Can I see other > peoples pending operations? Even if I can read them, what if I do > not have rights to a managed object included in a pending operation? > I should not be able to read it. > - there must be a way to remove pending scheduled operations. > > - often a configuration session will consist of multiple operations: > (lock, edit-config, unlock), (lock, discard-changes, edit-config, > commit, unlock). If I can only schedule single operations does that > mean I can not use lock? If I want to schedule commit, should I keep > the running and the candidate configurations locked to ensure I > commit, what I really want? What if my session is closed e.g. by a > network timeout? > > - if a management user is removed/undefined will his pending > operations also be removed, or will they stand there and fail at the > scheduled execution time? The latter case will confuse people that > do not know the user was removed. > > - generally timed operations work nicely if no one else configures > the node while my changes are pending. What is the proposed method > to ensure this? > > regards Balazs > > On 2013-07-08 16:27, Andy Bierman wrote: >> Hi, >> >> I do not support a general time-scheduled protocol operation mechanism f= or >> all NETCONF operations. There is one interesting use-case mentioned: >> synchronized (or on :writable-running) operations >> across multiple servers. >> >> The proposal doesn't actually work within NETCONF because requests >> within a single session are serialized. This solution seems to send 1 >> >> when the operation is finally executed. How does the client know >> the operation >> was scheduled successfully? IMO, a better solution would be an immediat= e >> (scheduled OK) and the execution results sent in a >> . >> >> How do clients monitor what operations are pending? >> >> What if the NACM rules change while the operation is pending? >> Does access control get checked twice? Clients should not be able >> to schedule operations they are not permitted to execute. >> >> What if a session is lost or closed before its scheduled operation >> is started? >> >> What if the server reboots while operations are pending? >> >> IMO, YANG date-and-time is better time parameter than 'seconds since 197= 0'. >> It is already supported by NETCONF servers. >> >> How does a client cancel an operation? >> Can client A cancel operations for client B, >> assuming client A is allowed to invoke ? >> >> >> >> Andy >> >> On Mon, Jul 8, 2013 at 12:48 AM, Tal Mizrahi wro= te: >>> Hi, >>> >>> We have submitted a new draft titled =E2=80=9CTime Capability in NETCON= F=E2=80=9D. >>> http://tools.ietf.org/html/draft-mm-netconf-time-capability-00 >>> >>> Any comments will be welcome. >>> Thanks, >>> Tal Mizrahi. >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > -- > Balazs Lengyel Ericsson Hungary Ltd. > System Manager > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From dew@tx.technion.ac.il Thu Jul 18 07:48:52 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A8821E8105 for ; Thu, 18 Jul 2013 07:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXnXPuAqB4gX for ; Thu, 18 Jul 2013 07:48:47 -0700 (PDT) Received: from mailgw13.technion.ac.il (mailgw13.technion.ac.il [132.68.225.13]) by ietfa.amsl.com (Postfix) with ESMTP id D154821E80FF for ; Thu, 18 Jul 2013 07:48:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIAAGT/51GERAEil2dsb2JhbABSCIM7UIMGvT2BDhYOAQEBAQEIFgc8giQBAQEBAgEBAQEgFTYGBQULCxgCAiYCAicFKwYTG4dvBgykSolCiAeBKI0lDIEDMweCW4EhA4kiimSDVoEqjlWEZIFu X-IronPort-AV: E=Sophos;i="4.89,694,1367960400"; d="scan'208";a="80127667" Received: from webmail.technion.ac.il ([132.68.1.34]) by mailgw13.technion.ac.il with ESMTP; 18 Jul 2013 17:48:14 +0300 Received: by webmail.technion.ac.il (Postfix, from userid 48) id A15781000FE; Thu, 18 Jul 2013 17:48:14 +0300 (IDT) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by webmail.technion.ac.il (Horde Framework) with HTTP; Thu, 18 Jul 2013 17:48:14 +0300 Date: Thu, 18 Jul 2013 17:48:14 +0300 Message-ID: <20130718174814.Horde.4U20NHGbDvb8NzPI8g2QFQ6@webmail.technion.ac.il> From: Tal Mizrahi To: Andy Bierman References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <51E7E10F.7060209@ericsson.com> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.0.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: moses@ee.technion.ac.il, netconf@ietf.org Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 14:48:52 -0000 Hi Andy, > I like the solution in draft-kwatsen-conditional-enablement-00 > better than this one because it covers more use-cases and > seems more tractable. The concept in our draft is to suggest a general solution, allowing servers to coordinate any type of operation, including commit, edit-config, or any future operations that may come up. We are also targeting a higher resolution than hours. Your points below are well taken. Thanks, Tal. Quoting Andy Bierman : > Hi, > > There are lots of operational problems with delayed operations. > I like the solution in draft-kwatsen-conditional-enablement-00 > better than this one because it covers more use-cases and > seems more tractable. > > For example: > * in order to stage time-triggered-config, > the user and access control can be checked once at the time > the request is made. > * the normal RPC mechanism is used > (1 request and 1 immediate reply) > * the staged config can be viewed or deleted with standard > protocol operations, using standard access control > [Not clear what filters would need to be added.] > * conditional-enablement easily handles periodic config to > support maintenance windows, URL blocking, etc. > * time-shift applies to config activation, which is much less > complicated than delaying arbitrary protocol operations. > > > Andy > > > On Thu, Jul 18, 2013 at 5:35 AM, Balazs Lengyel > wrote: >> Hello, >> - The idea that scheduled time should be the required completion time fo= r an >> operation is unfortunate. That assumes a device can estimate how long a >> complex configuration operation will take. That is already a a risky >> assumption. Even worse some operations might depend on external factors = like >> traffic load, I/O related delays, interaction with external nodes. It is >> impossible to estimate these delays. >> - because of the above IMO nanosecond precision for timing is not realis= tic. >> The YANG time types are good enough. Anyway in many protocols we have ti= mers >> on the scale of seconds, so coordinating configuration changes between n= odes >> with milli/nanosecond precision does not look like a sensible goal. >> >> - there must be a way to check pending scheduled operations. This has so= me >> interesting access control issues as well. Can I see other peoples pendi= ng >> operations? Even if I can read them, what if I do not have rights to a >> managed object included in a pending operation? I should not be able to = read >> it. >> - there must be a way to remove pending scheduled operations. >> >> - often a configuration session will consist of multiple operations: (lo= ck, >> edit-config, unlock), (lock, discard-changes, edit-config, commit, unloc= k). >> If I can only schedule single operations does that mean I can not use lo= ck? >> If I want to schedule commit, should I keep the running and the candidat= e >> configurations locked to ensure I commit, what I really want? What if my >> session is closed e.g. by a network timeout? >> >> - if a management user is removed/undefined will his pending operations = also >> be removed, or will they stand there and fail at the scheduled execution >> time? The latter case will confuse people that do not know the user was >> removed. >> >> - generally timed operations work nicely if no one else configures the n= ode >> while my changes are pending. What is the proposed method to ensure this= ? >> >> regards Balazs >> >> On 2013-07-08 16:27, Andy Bierman wrote: >>> >>> Hi, >>> >>> I do not support a general time-scheduled protocol operation mechanism = for >>> all NETCONF operations. There is one interesting use-case mentioned: >>> synchronized (or on :writable-running) operation= s >>> across multiple servers. >>> >>> The proposal doesn't actually work within NETCONF because request= s >>> within a single session are serialized. This solution seems to send 1 >>> >>> when the operation is finally executed. How does the client know the >>> operation >>> was scheduled successfully? IMO, a better solution would be an immedia= te >>> (scheduled OK) and the execution results sent in a >>> . >>> >>> How do clients monitor what operations are pending? >>> >>> What if the NACM rules change while the operation is pending? >>> Does access control get checked twice? Clients should not be able >>> to schedule operations they are not permitted to execute. >>> >>> What if a session is lost or closed before its scheduled operation is >>> started? >>> >>> What if the server reboots while operations are pending? >>> >>> IMO, YANG date-and-time is better time parameter than 'seconds since >>> 1970'. >>> It is already supported by NETCONF servers. >>> >>> How does a client cancel an operation? >>> Can client A cancel operations for client B, >>> assuming client A is allowed to invoke ? >>> >>> >>> >>> Andy >>> >>> On Mon, Jul 8, 2013 at 12:48 AM, Tal Mizrahi >>> wrote: >>>> >>>> Hi, >>>> >>>> We have submitted a new draft titled =E2=80=9CTime Capability in NETCO= NF=E2=80=9D. >>>> http://tools.ietf.org/html/draft-mm-netconf-time-capability-00 >>>> >>>> Any comments will be welcome. >>>> Thanks, >>>> Tal Mizrahi. >>>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> System Manager >> ECN: 831 7320 Tel: +36-1-437-7320 >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >> From andy@yumaworks.com Thu Jul 18 08:00:13 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867CA11E80E1 for ; Thu, 18 Jul 2013 08:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.767 X-Spam-Level: X-Spam-Status: No, score=-2.767 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPtD8mz8RhJD for ; Thu, 18 Jul 2013 08:00:06 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED96411E814F for ; Thu, 18 Jul 2013 07:59:27 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id uo1so3271638pbc.3 for ; Thu, 18 Jul 2013 07:59:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ZyXMOEfJsRi9edir9Lk4//5WrvCXc8ArGmtXnrVmAuk=; b=Sh4xqt82p9PR6Bvdad2Kq/6oOSsILyXPJZyXodT0VQmERPh5nQA0wn9mDsVb1x41KR BlSKbiWi5SFq+w/e7SrdDLcWLjOq6RsRs+b4D4m8t0aaYGK+62JiFuxjGHaJWerWihGY gHzvGNAmgQ782mwa7ghIKklxZBbmVFIeT61oy8RG5vuiRcLsQDE9lWmiT8qpK+n0PuQu AybCbtfSKmEgF0otWzi0c4TFfB/fxwkGd5lVPRq8MOsbQruFrTzLDGzCbj/X40U6IHEI vjvu/SKpyfHIOQM9NVPLh2J8nnFvHM3tQ7H/9LhSm4CUY0ixISv4sYcHCiQFHc81JlrW wZFw== MIME-Version: 1.0 X-Received: by 10.66.234.71 with SMTP id uc7mr13449944pac.10.1374159562414; Thu, 18 Jul 2013 07:59:22 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Thu, 18 Jul 2013 07:59:22 -0700 (PDT) In-Reply-To: <20130718174814.Horde.4U20NHGbDvb8NzPI8g2QFQ6@webmail.technion.ac.il> References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <51E7E10F.7060209@ericsson.com> <20130718174814.Horde.4U20NHGbDvb8NzPI8g2QFQ6@webmail.technion.ac.il> Date: Thu, 18 Jul 2013 07:59:22 -0700 Message-ID: From: Andy Bierman To: Tal Mizrahi Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkaP/kF3mFZMADkVeKCBZ54Lrm84uqDqEI6B3hyZx3P2GhYsxDErLuB8uXbNfeLYqG2iihx Cc: moses@ee.technion.ac.il, netconf@ietf.org Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:00:13 -0000 On Thu, Jul 18, 2013 at 7:48 AM, Tal Mizrahi wrote: > Hi Andy, > >> I like the solution in draft-kwatsen-conditional-enablement-00 >> better than this one because it covers more use-cases and >> seems more tractable. > > > The concept in our draft is to suggest a general solution, allowing serve= rs > to coordinate any type of operation, including commit, edit-config, or an= y > future operations that may come up. We are also targeting a higher > resolution than hours. > I think your solution has use-cases outside of configuration. - synchronized actions across multiple servers (e.g., ) - synchronized across multiple servers > Your points below are well taken. > > Thanks, > Tal. > > Andy > > Quoting Andy Bierman : > >> Hi, >> >> There are lots of operational problems with delayed operations. >> I like the solution in draft-kwatsen-conditional-enablement-00 >> better than this one because it covers more use-cases and >> seems more tractable. >> >> For example: >> * in order to stage time-triggered-config, >> the user and access control can be checked once at the time >> the request is made. >> * the normal RPC mechanism is used >> (1 request and 1 immediate reply) >> * the staged config can be viewed or deleted with standard >> protocol operations, using standard access control >> [Not clear what filters would need to be added.] >> * conditional-enablement easily handles periodic config to >> support maintenance windows, URL blocking, etc. >> * time-shift applies to config activation, which is much less >> complicated than delaying arbitrary protocol operations. >> >> >> Andy >> >> >> On Thu, Jul 18, 2013 at 5:35 AM, Balazs Lengyel >> wrote: >>> >>> Hello, >>> - The idea that scheduled time should be the required completion time f= or >>> an >>> operation is unfortunate. That assumes a device can estimate how long a >>> complex configuration operation will take. That is already a a risky >>> assumption. Even worse some operations might depend on external factors >>> like >>> traffic load, I/O related delays, interaction with external nodes. It i= s >>> impossible to estimate these delays. >>> - because of the above IMO nanosecond precision for timing is not >>> realistic. >>> The YANG time types are good enough. Anyway in many protocols we have >>> timers >>> on the scale of seconds, so coordinating configuration changes between >>> nodes >>> with milli/nanosecond precision does not look like a sensible goal. >>> >>> - there must be a way to check pending scheduled operations. This has >>> some >>> interesting access control issues as well. Can I see other peoples >>> pending >>> operations? Even if I can read them, what if I do not have rights to a >>> managed object included in a pending operation? I should not be able to >>> read >>> it. >>> - there must be a way to remove pending scheduled operations. >>> >>> - often a configuration session will consist of multiple operations: >>> (lock, >>> edit-config, unlock), (lock, discard-changes, edit-config, commit, >>> unlock). >>> If I can only schedule single operations does that mean I can not use >>> lock? >>> If I want to schedule commit, should I keep the running and the candida= te >>> configurations locked to ensure I commit, what I really want? What if m= y >>> session is closed e.g. by a network timeout? >>> >>> - if a management user is removed/undefined will his pending operations >>> also >>> be removed, or will they stand there and fail at the scheduled executio= n >>> time? The latter case will confuse people that do not know the user was >>> removed. >>> >>> - generally timed operations work nicely if no one else configures the >>> node >>> while my changes are pending. What is the proposed method to ensure thi= s? >>> >>> regards Balazs >>> >>> On 2013-07-08 16:27, Andy Bierman wrote: >>>> >>>> >>>> Hi, >>>> >>>> I do not support a general time-scheduled protocol operation mechanism >>>> for >>>> all NETCONF operations. There is one interesting use-case mentioned: >>>> synchronized (or on :writable-running) operatio= ns >>>> across multiple servers. >>>> >>>> The proposal doesn't actually work within NETCONF because reques= ts >>>> within a single session are serialized. This solution seems to send 1 >>>> >>>> when the operation is finally executed. How does the client know the >>>> operation >>>> was scheduled successfully? IMO, a better solution would be an >>>> immediate >>>> (scheduled OK) and the execution results sent in a >>>> . >>>> >>>> How do clients monitor what operations are pending? >>>> >>>> What if the NACM rules change while the operation is pending? >>>> Does access control get checked twice? Clients should not be able >>>> to schedule operations they are not permitted to execute. >>>> >>>> What if a session is lost or closed before its scheduled operation is >>>> started? >>>> >>>> What if the server reboots while operations are pending? >>>> >>>> IMO, YANG date-and-time is better time parameter than 'seconds since >>>> 1970'. >>>> It is already supported by NETCONF servers. >>>> >>>> How does a client cancel an operation? >>>> Can client A cancel operations for client B, >>>> assuming client A is allowed to invoke ? >>>> >>>> >>>> >>>> Andy >>>> >>>> On Mon, Jul 8, 2013 at 12:48 AM, Tal Mizrahi >>>> wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> We have submitted a new draft titled =93Time Capability in NETCONF=94= . >>>>> http://tools.ietf.org/html/draft-mm-netconf-time-capability-00 >>>>> >>>>> Any comments will be welcome. >>>>> Thanks, >>>>> Tal Mizrahi. >>>>> >>>>> _______________________________________________ >>>>> Netconf mailing list >>>>> Netconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netconf >>>> >>>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>>> >>> >>> -- >>> Balazs Lengyel Ericsson Hungary Ltd. >>> System Manager >>> ECN: 831 7320 Tel: +36-1-437-7320 >>> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >>> > > From mehmet.ersue@nsn.com Sat Jul 20 10:40:18 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD2B21F9E6A for ; Sat, 20 Jul 2013 10:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.42 X-Spam-Level: X-Spam-Status: No, score=-106.42 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVD11M2+iFOR for ; Sat, 20 Jul 2013 10:40:14 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B80A421F9E6E for ; Sat, 20 Jul 2013 10:40: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 r6KHe9Tr027753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 20 Jul 2013 19:40:09 +0200 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6KHe92r029600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 20 Jul 2013 19:40:09 +0200 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 20 Jul 2013 19:40:09 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.45]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Sat, 20 Jul 2013 19:40:09 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: Draft Agenda for the Netconf session in IETF #87 Thread-Index: Ac6FcCz4oAi9RyJQSAKFqTx77KNQdQ== Date: Sat, 20 Jul 2013 17:40:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.104] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F814292BDEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3055 X-purgate-ID: 151667::1374342009-000017BA-9FFFA6A0/0-0/0-0 Subject: [Netconf] Draft Agenda for the Netconf session in IETF #87 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 17:40:18 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F814292BDEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, please find online the draft agenda for the Netconf session in IETF #87. http://www.ietf.org/proceedings/87/agenda/agenda-87-netconf Please let us know whether there is any interest to discuss on draft-petch-= netconf-surprises-00. Cheers, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F814292BDEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
 
please find online the draft agenda for the Netco= nf session in IETF #87.
 
 
Please let us know whether there is any interest = to discuss on draft-petch-netconf-surprises-00.
 
Cheers,
Mehmet
 
 
 --_000_E4DE949E6CE3E34993A2FF8AE79131F814292BDEMUMBX005nsnintr_-- From andy@yumaworks.com Sat Jul 20 17:57:24 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE4911E80BA for ; Sat, 20 Jul 2013 17:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.774 X-Spam-Level: X-Spam-Status: No, score=-2.774 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvdGq9zSTPnx for ; Sat, 20 Jul 2013 17:57:19 -0700 (PDT) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id BCC1711E8131 for ; Sat, 20 Jul 2013 17:57:18 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so227211pab.25 for ; Sat, 20 Jul 2013 17:57:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=5U+HdiE2RiPb2Vs+6OXc4ldJppEzw5tPsFnOTtyQ3k4=; b=UNKuFb7am8aDF3yvL4qlOmJhG4ytJL75mZod9hwhMCCmr54tC5Ka3wkeqxAj8jLjpr zwV2d5ugJmaseGOmRJdYAoHMh2VZ4TOw4FsDIHSV+hJ/MBA7Dk5mOcrHOzUIJfld9s/f ZehC/tMz7hm97IKDNqyiTTt29D1fOXpRf1Ya9hQWvmfMUL/FEt9+6MG5TXPDa09laRxi 7TXhAdwqENeHuhEfXTD4Lqgg4OiLKTEQOha5xMV9ipttzMT2f+UwxHjrZ3OfWuYEdowt 25B/9d0ysoz3Ey1HhMLYNhPrqWj77EU7wirosjf0R/OYwCIVzNiEu3NgdenpEg1r5Otz i6Ww== MIME-Version: 1.0 X-Received: by 10.68.201.98 with SMTP id jz2mr24127440pbc.56.1374368238420; Sat, 20 Jul 2013 17:57:18 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Sat, 20 Jul 2013 17:57:18 -0700 (PDT) In-Reply-To: <51E7E10F.7060209@ericsson.com> References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <51E7E10F.7060209@ericsson.com> Date: Sat, 20 Jul 2013 17:57:18 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn/Ufh+xjRhzep3HI5+qY6JbNIqrn+3De2fB8aYAkMmXAUSKDJ3scAUuV8n3u7bpe8fs7W+ Cc: netconf@ietf.org, moses@ee.technion.ac.il Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 00:57:24 -0000 On Thu, Jul 18, 2013 at 5:35 AM, Balazs Lengyel wrote: > Hello, > - The idea that scheduled time should be the required completion time for an > operation is unfortunate. That assumes a device can estimate how long a > complex configuration operation will take. That is already a a risky > assumption. Even worse some operations might depend on external factors like > traffic load, I/O related delays, interaction with external nodes. It is > impossible to estimate these delays. I agree it is better to synch the start-times, not the finish-times. That is too difficult to predict. IMO, 1 micro-second resolution is enough, not nano-seconds. There can be a monitoring leaf specifying the start-time-granularity supported by the server. > - because of the above IMO nanosecond precision for timing is not realistic. > The YANG time types are good enough. Anyway in many protocols we have timers > on the scale of seconds, so coordinating configuration changes between nodes > with milli/nanosecond precision does not look like a sensible goal. > > - there must be a way to check pending scheduled operations. This has some > interesting access control issues as well. Can I see other peoples pending > operations? Even if I can read them, what if I do not have rights to a > managed object included in a pending operation? I should not be able to read > it. > - there must be a way to remove pending scheduled operations. > > - often a configuration session will consist of multiple operations: (lock, > edit-config, unlock), (lock, discard-changes, edit-config, commit, unlock). > If I can only schedule single operations does that mean I can not use lock? > If I want to schedule commit, should I keep the running and the candidate > configurations locked to ensure I commit, what I really want? What if my > session is closed e.g. by a network timeout? > > - if a management user is removed/undefined will his pending operations also > be removed, or will they stand there and fail at the scheduled execution > time? The latter case will confuse people that do not know the user was > removed. > > - generally timed operations work nicely if no one else configures the node > while my changes are pending. What is the proposed method to ensure this? > How about other timed events like a confirmed-commit timeout? In general, what if the config being patched via a timed operation assumes a different running config and system state than what actually exists? (This is why NETCONF editing operations need to support ETags). IMO, conditional config is too hard to accomplish via staged edit operations. It is better to just stage the config itself. > regards Balazs > Andy From dew@tx.technion.ac.il Mon Jul 22 07:45:32 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F00E21E80AA for ; Mon, 22 Jul 2013 07:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AT1CIkdInCx4 for ; Mon, 22 Jul 2013 07:45:25 -0700 (PDT) Received: from mailgw13.technion.ac.il (mailgw13.technion.ac.il [132.68.225.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB6D21E8097 for ; Mon, 22 Jul 2013 07:44:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFAGNE7VGERAEi/2dsb2JhbABSCIMGgQWDCr0mgRIWdIIkAQEEASMVPAUFCwsYAgImAgIsKwYTiAoGpj2JHIgHgSiNOIE2B4JdgSEDiSKOOo9/gU+DFQ X-IronPort-AV: E=Sophos;i="4.89,719,1367960400"; d="scan'208";a="80505520" Received: from webmail.technion.ac.il ([132.68.1.34]) by mailgw13.technion.ac.il with ESMTP; 22 Jul 2013 17:44:53 +0300 Received: by webmail.technion.ac.il (Postfix, from userid 48) id 9B2FB1000FE; Mon, 22 Jul 2013 17:44:52 +0300 (IDT) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by webmail.technion.ac.il (Horde Framework) with HTTP; Mon, 22 Jul 2013 17:44:52 +0300 Date: Mon, 22 Jul 2013 17:44:52 +0300 Message-ID: <20130722174452.Horde.sqGEhVLk2MR5teBwUuFsOQ1@webmail.technion.ac.il> From: Tal Mizrahi To: Andy Bierman References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <51E7E10F.7060209@ericsson.com> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.0.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: moses@ee.technion.ac.il, netconf@ietf.org Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 14:45:32 -0000 Hi Andy, > IMO, 1 micro-second resolution is enough, not nano-seconds. > There can be a monitoring leaf specifying the start-time-granularity > supported by the server. I don't disagree. I believe a micro-second resolution is probably granular enough. I am just saying there is an advantage to use an existing time format (PTP/NTP) rather than to invent a new one. > How about other timed events like a confirmed-commit timeout? Please note the " Confirmed Commit Capability" section in the draft: When the time capability is supported, and a confirmed operation is used with the element, the confirmation timeout MUST be counted from the scheduled time, i.e., the client begins the timeout measurement starting at the scheduled time. Thanks, Tal. Quoting Andy Bierman : > On Thu, Jul 18, 2013 at 5:35 AM, Balazs Lengyel > wrote: >> Hello, >> - The idea that scheduled time should be the required completion time for an >> operation is unfortunate. That assumes a device can estimate how long a >> complex configuration operation will take. That is already a a risky >> assumption. Even worse some operations might depend on external factors like >> traffic load, I/O related delays, interaction with external nodes. It is >> impossible to estimate these delays. > > > I agree it is better to synch the start-times, not the finish-times. > That is too difficult to predict. > > IMO, 1 micro-second resolution is enough, not nano-seconds. > There can be a monitoring leaf specifying the start-time-granularity > supported by the server. > >> - because of the above IMO nanosecond precision for timing is not realistic. >> The YANG time types are good enough. Anyway in many protocols we have timers >> on the scale of seconds, so coordinating configuration changes between nodes >> with milli/nanosecond precision does not look like a sensible goal. >> >> - there must be a way to check pending scheduled operations. This has some >> interesting access control issues as well. Can I see other peoples pending >> operations? Even if I can read them, what if I do not have rights to a >> managed object included in a pending operation? I should not be able to read >> it. >> - there must be a way to remove pending scheduled operations. >> >> - often a configuration session will consist of multiple operations: (lock, >> edit-config, unlock), (lock, discard-changes, edit-config, commit, unlock). >> If I can only schedule single operations does that mean I can not use lock? >> If I want to schedule commit, should I keep the running and the candidate >> configurations locked to ensure I commit, what I really want? What if my >> session is closed e.g. by a network timeout? >> >> - if a management user is removed/undefined will his pending operations also >> be removed, or will they stand there and fail at the scheduled execution >> time? The latter case will confuse people that do not know the user was >> removed. >> >> - generally timed operations work nicely if no one else configures the node >> while my changes are pending. What is the proposed method to ensure this? >> > > > How about other timed events like a confirmed-commit timeout? > > In general, what if the config being patched via a timed operation assumes > a different running config and system state than what actually exists? > > (This is why NETCONF editing operations need to support ETags). > > IMO, conditional config is too hard to accomplish via staged edit operations. > It is better to just stage the config itself. > > >> regards Balazs >> > > Andy From rkrejci@cesnet.cz Mon Jul 22 07:54:22 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF5F21F9E3B for ; Mon, 22 Jul 2013 07:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.95 X-Spam-Level: X-Spam-Status: No, score=-4.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3-Z6IPFdMgP for ; Mon, 22 Jul 2013 07:54:12 -0700 (PDT) Received: from minas.ics.muni.cz (minas.ics.muni.cz [147.251.4.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5340011E80F5 for ; Mon, 22 Jul 2013 07:53:47 -0700 (PDT) Received: from anxur.fi.muni.cz (anxur.fi.muni.cz [147.251.48.3]) by minas.ics.muni.cz (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id r6MEreN2013965; Mon, 22 Jul 2013 16:53:41 +0200 Received: from sheldon.liberouter.org (pc07.liberouter.org [147.251.21.216]) by anxur.fi.muni.cz (Postfix) with ESMTPSA id 4424E61064; Mon, 22 Jul 2013 16:53:40 +0200 (CEST) Message-ID: <51ED4774.2080300@cesnet.cz> Date: Mon, 22 Jul 2013 16:53:40 +0200 From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Organization: CESNET, z.s.p.o. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andy Bierman References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <51E7E10F.7060209@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Muni-Spam-TestIP: 147.251.48.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (minas.ics.muni.cz [147.251.4.35]); Mon, 22 Jul 2013 16:53:41 +0200 (CEST) Cc: moses@ee.technion.ac.il, netconf@ietf.org Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 14:54:22 -0000 Dne 21.7.2013 02:57, Andy Bierman napsal(a): > On Thu, Jul 18, 2013 at 5:35 AM, Balazs Lengyel > wrote: >> Hello, >> - The idea that scheduled time should be the required completion time for an >> operation is unfortunate. That assumes a device can estimate how long a >> complex configuration operation will take. That is already a a risky >> assumption. Even worse some operations might depend on external factors like >> traffic load, I/O related delays, interaction with external nodes. It is >> impossible to estimate these delays. > > > I agree it is better to synch the start-times, not the finish-times. > That is too difficult to predict. > +1 Even if you do on a single leaf, it can represent a complex operation with a hardly predictable duration. Radek From balazs.lengyel@ericsson.com Tue Jul 23 00:23:27 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453BF11E8118 for ; Tue, 23 Jul 2013 00:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upkRNJyNkdr2 for ; Tue, 23 Jul 2013 00:23:21 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8586611E80D1 for ; Tue, 23 Jul 2013 00:23:20 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-36-51ee2f666839 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 27.13.11907.66F2EE15; Tue, 23 Jul 2013 09:23:19 +0200 (CEST) Received: from [159.107.196.192] (153.88.183.149) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.328.9; Tue, 23 Jul 2013 09:23:18 +0200 Message-ID: <51EE2F65.5090902@ericsson.com> Date: Tue, 23 Jul 2013 09:23:17 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tal Mizrahi References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <51E7E10F.7060209@ericsson.com> <20130722174452.Horde.sqGEhVLk2MR5teBwUuFsOQ1@webmail.technion.ac.il> In-Reply-To: <20130722174452.Horde.sqGEhVLk2MR5teBwUuFsOQ1@webmail.technion.ac.il> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+JvrW66/rtAgyO/WS0eHJnFbrHo8kk2 i4mLvzNZTN10m9WBxWP7tIfsHkuW/GTymPTwG5NHS/9FlgCWKC6blNSczLLUIn27BK6M5juX WArWcFXs6dnH2MDYxNHFyMkhIWAi8XZaByuELSZx4d56ti5GLg4hgaOMEp/uboRy1jJKPNu2 gRmkildAW+L+njUsIDaLgKrE6vebmEBsNgEjian958HiogJREq29U6HqBSVOznwCFhcRUJdY sf4/O4jNLBAmcXf/HjYQW1jAVeLl6TvMEMsOMklsPNbLCJLgFAiS2PzkMlSDhcTiNwehbHmJ 7W/ngC0QEtCQeHjhL+sERsFZSPbNQtIyC0nLAkbmVYwcxanFSbnpRgabGIEBfHDLb4sdjJf/ 2hxilOZgURLn3aJ3JlBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD47SGBZI3zNrjKll+nGp7 /vWa6OdV65a1Ni/tTG8Nn839eXOqne3f5VzND5OWPLl3+Az73vc235ecnl6VVHrXJY1jgyjL 6eldTMbul950rsuRCH4g4uGzz4Kv7wVr5ItIp6S9odxS6qVe3Dsvd4V5/d1dv3P1ZddTs7oX fowMedT5osPvsHhNihJLcUaioRZzUXEiANF1TmYuAgAA Cc: moses@ee.technion.ac.il, netconf@ietf.org Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 07:23:27 -0000 On 2013-07-22 16:44, Tal Mizrahi wrote: > Hi Andy, > > >> IMO, 1 micro-second resolution is enough, not nano-seconds. >> There can be a monitoring leaf specifying the start-time-granularity >> supported by the server. > > I don't disagree. I believe a micro-second resolution is probably > granular enough. > I am just saying there is an advantage to use an existing time format > (PTP/NTP) rather than to invent a new one. > IMHO anything better then millisec precision is unrealistic, unneeded or rather just wishfull thinking. - Have anyone ever seen a configuration operations that were specified to this precision? - It would be extremely fragile to depend on that level of precision. AFAIK even in the most tightly controlled networks network delays can fluctuate with milliseconds, so requiring microsecond precision seems to be unrealistic. - Do you foresee any real use cases needing that precision? - How well are the timers of different nodes syncronised today? Do we really have 1 microsecond syncronisation(or will have in the next 10 years)? regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From dew@tx.technion.ac.il Tue Jul 23 00:58:03 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C20121E804D for ; Tue, 23 Jul 2013 00:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvYw3mqY7sN3 for ; Tue, 23 Jul 2013 00:57:57 -0700 (PDT) Received: from mailgw13.technion.ac.il (mailgw13.technion.ac.il [132.68.225.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8F80C21E804C for ; Tue, 23 Jul 2013 00:57:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAP827lGERAEi/2dsb2JhbABbgwaBBYMJvS+BDxZ0giQBAQQBIxVBBQsLGAICJgICLCsGE4gKBqZbiWCIB4EojSmBQgeCXYEhA4kiimSDVo9/gU+DFYFu X-IronPort-AV: E=Sophos;i="4.89,725,1367960400"; d="scan'208";a="80576465" Received: from webmail.technion.ac.il ([132.68.1.34]) by mailgw13.technion.ac.il with ESMTP; 23 Jul 2013 10:57:53 +0300 Received: by webmail.technion.ac.il (Postfix, from userid 48) id B15D61000F6; Tue, 23 Jul 2013 10:57:51 +0300 (IDT) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by webmail.technion.ac.il (Horde Framework) with HTTP; Tue, 23 Jul 2013 10:57:51 +0300 Date: Tue, 23 Jul 2013 10:57:51 +0300 Message-ID: <20130723105751.Horde.xDfWGUl3ShdRI-xBWm3TsQ2@webmail.technion.ac.il> From: Tal Mizrahi To: Balazs Lengyel References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <51E7E10F.7060209@ericsson.com> <20130722174452.Horde.sqGEhVLk2MR5teBwUuFsOQ1@webmail.technion.ac.il> <51EE2F65.5090902@ericsson.com> In-Reply-To: <51EE2F65.5090902@ericsson.com> User-Agent: Internet Messaging Program (IMP) H5 (6.0.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: moses@ee.technion.ac.il, netconf@ietf.org Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 07:58:03 -0000 Hi Balazs, > IMHO anything better then millisec precision is unrealistic, > unneeded or rather just wishfull thinking. It is not necessarily bad to provision for a higher resolution than is currently needed. (Honestly, does anyone really need 128-bit IP addresses? :) ) > - How well are the timers of different nodes syncronised today? Do > we really have 1 microsecond syncronisation(or will have in the > next 10 years)? NTP allows an accuracy in the order of milliseconds. PTP typically allows an accuracy in the order of 1 microsecond, and the accuracy requirements of time-aware applications are becoming increasingly stringent. So in the next 10 years it is very likely to see network devices (switches, routers) that maintain a clock with an accuracy in the order of tens of nanoseconds. Since this level of accuracy is available, it makes sense to provision for a high-resolution time field, even if we know *current* applications only require a coarser-grained resolution. Regards, Tal. Quoting Balazs Lengyel : > On 2013-07-22 16:44, Tal Mizrahi wrote: >> Hi Andy, >> >> >>> IMO, 1 micro-second resolution is enough, not nano-seconds. >>> There can be a monitoring leaf specifying the >>> start-time-granularity supported by the server. >> >> I don't disagree. I believe a micro-second resolution is probably >> granular enough. >> I am just saying there is an advantage to use an existing time >> format (PTP/NTP) rather than to invent a new one. >> > IMHO anything better then millisec precision is unrealistic, > unneeded or rather just wishfull thinking. > - Have anyone ever seen a configuration operations that were > specified to this precision? > - It would be extremely fragile to depend on that level of > precision. AFAIK even in the most tightly controlled networks > network delays can fluctuate with milliseconds, so requiring > microsecond precision seems to be unrealistic. > - Do you foresee any real use cases needing that precision? > - How well are the timers of different nodes syncronised today? Do > we really have 1 microsecond syncronisation(or will have in the > next 10 years)? > regards Balazs > > -- > Balazs Lengyel Ericsson Hungary Ltd. > System Manager > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From j.schoenwaelder@jacobs-university.de Tue Jul 23 01:40:57 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A0021F9E68 for ; Tue, 23 Jul 2013 01:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0gg4I2RaZ9R for ; Tue, 23 Jul 2013 01:40:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C7E3511E8103 for ; Tue, 23 Jul 2013 01:40:51 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FB5320BD5; Tue, 23 Jul 2013 10:40:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id q7zoibkdmeyu; Tue, 23 Jul 2013 10:40:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9FBDA20AFE; Tue, 23 Jul 2013 10:40:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5E507274D11E; Tue, 23 Jul 2013 10:40:46 +0200 (CEST) Date: Tue, 23 Jul 2013 10:40:45 +0200 From: Juergen Schoenwaelder To: Tal Mizrahi Message-ID: <20130723084045.GA3273@elstar.local> Mail-Followup-To: Tal Mizrahi , Balazs Lengyel , moses@ee.technion.ac.il, netconf@ietf.org References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <51E7E10F.7060209@ericsson.com> <20130722174452.Horde.sqGEhVLk2MR5teBwUuFsOQ1@webmail.technion.ac.il> <51EE2F65.5090902@ericsson.com> <20130723105751.Horde.xDfWGUl3ShdRI-xBWm3TsQ2@webmail.technion.ac.il> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130723105751.Horde.xDfWGUl3ShdRI-xBWm3TsQ2@webmail.technion.ac.il> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: moses@ee.technion.ac.il, netconf@ietf.org Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 08:40:57 -0000 On Tue, Jul 23, 2013 at 10:57:51AM +0300, Tal Mizrahi wrote: > Since this level of accuracy is available, it makes sense to > provision for a high-resolution time field, even if we know > *current* applications only require a coarser-grained resolution. If nobody seriously can implement a certain precision, implementations will simply cheat and the consequence of that in the long run is often worse than having a less fine grained precision that is implementable and thus meaningful. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From balazs.lengyel@ericsson.com Tue Jul 23 03:06:23 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207EA11E80DC for ; Tue, 23 Jul 2013 03:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOFCShFiPNVy for ; Tue, 23 Jul 2013 03:06:16 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 63EC811E8140 for ; Tue, 23 Jul 2013 03:06:16 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-c8-51ee5596ba08 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 68.39.11907.6955EE15; Tue, 23 Jul 2013 12:06:15 +0200 (CEST) Received: from [159.107.196.192] (153.88.183.150) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.328.9; Tue, 23 Jul 2013 12:06:14 +0200 Message-ID: <51EE5595.6060208@ericsson.com> Date: Tue, 23 Jul 2013 12:06:13 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tal Mizrahi References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <51E7E10F.7060209@ericsson.com> <20130722174452.Horde.sqGEhVLk2MR5teBwUuFsOQ1@webmail.technion.ac.il> <51EE2F65.5090902@ericsson.com> <20130723105751.Horde.xDfWGUl3ShdRI-xBWm3TsQ2@webmail.technion.ac.il> In-Reply-To: <20130723105751.Horde.xDfWGUl3ShdRI-xBWm3TsQ2@webmail.technion.ac.il> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvre700HeBBtemc1g8ODKL3WLR5ZNs FhMXf2eymLrpNqsDi8f2aQ/ZPZYs+cnkMenhNyaPlv6LLAEsUVw2Kak5mWWpRfp2CVwZPbsv sBU8k6h4dbSftYFxpnAXIyeHhICJxJS1/1khbDGJC/fWs3UxcnEICRxllGh4fBnKWcsocWHi aSaQKl4BbYlb/9eBdbAIqErsf7aGHcRmEzCSmNp/ngXEFhWIkmjtncoMUS8ocXLmE7C4iIC6 xIr1/8HqmQXCJO7u38MGYgsLuEq8PH0HrF5IYDmzxKEnWiA2p0CQxNr1j5gg6i0kFr85CNUr L7H97Ryoeg2Jhxf+sk5gFJyFZN0sJC2zkLQsYGRexchRnFqclJtuZLCJERi+B7f8ttjBePmv zSFGaQ4WJXHeLXpnAoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwZnb/vKVSs2HfojmmbjWP 5LP13v3TKcjm+ai5JHxlgIXoS+uzbRVP+yc/ep6ZYfaN5UdVEXtXTo26/Yunew0b9bJev02t 5NiiyvZhV7RbyQffyHN3fip/3Br04NvLlM3zhIp/M0f5mWbI3Hyxdxnr1ezVdbkzP7nr7lgT IWPSvWfjF8lFjAe7lViKMxINtZiLihMBYQlJ3S0CAAA= Cc: moses@ee.technion.ac.il, netconf@ietf.org Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 10:06:23 -0000 Hello Tal, Can you give us some examples of applications today that use coordinated configuration? What precision is used today? (I don't seriously object to adding a few extra characters/bits for precision. However I still feel it would be a fragile design to depend on such high precision coordinated configuration.) regards Balazs On 2013-07-23 09:57, Tal Mizrahi wrote: > Hi Balazs, > >> IMHO anything better then millisec precision is unrealistic, unneeded >> or rather just wishfull thinking. > > It is not necessarily bad to provision for a higher resolution than is > currently needed. > (Honestly, does anyone really need 128-bit IP addresses? :) ) > > >> - How well are the timers of different nodes syncronised today? Do we >> really have 1 microsecond syncronisation(or will have in the next 10 >> years)? > > NTP allows an accuracy in the order of milliseconds. PTP typically > allows an accuracy in the order of 1 microsecond, and the accuracy > requirements of time-aware applications are becoming increasingly > stringent. So in the next 10 years it is very likely to see network > devices (switches, routers) that maintain a clock with an accuracy in > the order of tens of nanoseconds. > Since this level of accuracy is available, it makes sense to provision > for a high-resolution time field, even if we know *current* > applications only require a coarser-grained resolution. > > > Regards, > Tal. > > > > Quoting Balazs Lengyel : > >> On 2013-07-22 16:44, Tal Mizrahi wrote: >>> Hi Andy, >>> >>> >>>> IMO, 1 micro-second resolution is enough, not nano-seconds. >>>> There can be a monitoring leaf specifying the >>>> start-time-granularity supported by the server. >>> >>> I don't disagree. I believe a micro-second resolution is probably >>> granular enough. >>> I am just saying there is an advantage to use an existing time >>> format (PTP/NTP) rather than to invent a new one. >>> >> IMHO anything better then millisec precision is unrealistic, unneeded >> or rather just wishfull thinking. >> - Have anyone ever seen a configuration operations that were >> specified to this precision? >> - It would be extremely fragile to depend on that level of precision. >> AFAIK even in the most tightly controlled networks network delays can >> fluctuate with milliseconds, so requiring microsecond precision seems >> to be unrealistic. >> - Do you foresee any real use cases needing that precision? >> - How well are the timers of different nodes syncronised today? Do we >> really have 1 microsecond syncronisation(or will have in the next 10 >> years)? >> regards Balazs >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> System Manager >> ECN: 831 7320 Tel: +36-1-437-7320 >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > > > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From dew@tx.technion.ac.il Tue Jul 23 04:04:59 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68FB611E8216 for ; Tue, 23 Jul 2013 04:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6bsPW5BWJn2 for ; Tue, 23 Jul 2013 04:04:52 -0700 (PDT) Received: from mailgw13.technion.ac.il (mailgw13.technion.ac.il [132.68.225.13]) by ietfa.amsl.com (Postfix) with ESMTP id D856111E8215 for ; Tue, 23 Jul 2013 04:04:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUIAFti7lGERAEi/2dsb2JhbABbFoJwNVCDCakqlAaBERZ0giQBAQMBASMVQQULCxgCAiYCAiwrBhOICgYMpwiJZogHgSiNKYFCB4JdgSEDiSKKZINWj3+BT4MVgW4 X-IronPort-AV: E=Sophos;i="4.89,726,1367960400"; d="scan'208";a="80606374" Received: from webmail.technion.ac.il ([132.68.1.34]) by mailgw13.technion.ac.il with ESMTP; 23 Jul 2013 14:04:49 +0300 Received: by webmail.technion.ac.il (Postfix, from userid 48) id A48111000F6; Tue, 23 Jul 2013 14:04:48 +0300 (IDT) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by webmail.technion.ac.il (Horde Framework) with HTTP; Tue, 23 Jul 2013 14:04:48 +0300 Date: Tue, 23 Jul 2013 14:04:48 +0300 Message-ID: <20130723140448.Horde.KULO0_8w2Ts-oNHOIq9log1@webmail.technion.ac.il> From: Tal Mizrahi To: Balazs Lengyel References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <51E7E10F.7060209@ericsson.com> <20130722174452.Horde.sqGEhVLk2MR5teBwUuFsOQ1@webmail.technion.ac.il> <51EE2F65.5090902@ericsson.com> <20130723105751.Horde.xDfWGUl3ShdRI-xBWm3TsQ2@webmail.technion.ac.il> <51EE5595.6060208@ericsson.com> In-Reply-To: <51EE5595.6060208@ericsson.com> User-Agent: Internet Messaging Program (IMP) H5 (6.0.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: moses@ee.technion.ac.il, netconf@ietf.org Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 11:04:59 -0000 Hi Balazs, > Can you give us some examples of applications today that use > coordinated configuration? What precision is used today? It is a fair question (I am a bit confused about the word *today* in your question; since we are proposing a new feature, it is not used today, but existing applications can benefit from it in the future). We plan to present a few use-cases in next week's meeting in Berlin. In general the time capability addresses two main scenarios: - Coordinated updates, which allow you to update multiple servers at the same time, minimizing the transient effect of any anomalies or inconsistencies that may be caused by the transition to the new configuration. - Sequential updates, where the client can schedule a different update time at each server, allowing an ordered sequence of updates. We have also proposed an extension to the OpenFlow protocol that is very similar to the proposed time capability in NETCONF. The following technical report provides some more details as well as a few time-triggered update use-cases: http://tx.technion.ac.il/~dew/OFTimeTR.pdf Regards, Tal. Quoting Balazs Lengyel : > Hello Tal, > Can you give us some examples of applications today that use > coordinated configuration? What precision is used today? > > (I don't seriously object to adding a few extra characters/bits for > precision. However I still feel it would be a fragile design to > depend on such high precision coordinated configuration.) > regards Balazs > > On 2013-07-23 09:57, Tal Mizrahi wrote: >> Hi Balazs, >> >>> IMHO anything better then millisec precision is unrealistic, >>> unneeded or rather just wishfull thinking. >> >> It is not necessarily bad to provision for a higher resolution than >> is currently needed. >> (Honestly, does anyone really need 128-bit IP addresses? :) ) >> >> >>> - How well are the timers of different nodes syncronised today? Do >>> we really have 1 microsecond syncronisation(or will have in the >>> next 10 years)? >> >> NTP allows an accuracy in the order of milliseconds. PTP typically >> allows an accuracy in the order of 1 microsecond, and the accuracy >> requirements of time-aware applications are becoming increasingly >> stringent. So in the next 10 years it is very likely to see network >> devices (switches, routers) that maintain a clock with an accuracy >> in the order of tens of nanoseconds. >> Since this level of accuracy is available, it makes sense to >> provision for a high-resolution time field, even if we know >> *current* applications only require a coarser-grained resolution. >> >> >> Regards, >> Tal. >> >> >> >> Quoting Balazs Lengyel : >> >>> On 2013-07-22 16:44, Tal Mizrahi wrote: >>>> Hi Andy, >>>> >>>> >>>>> IMO, 1 micro-second resolution is enough, not nano-seconds. >>>>> There can be a monitoring leaf specifying the >>>>> start-time-granularity supported by the server. >>>> >>>> I don't disagree. I believe a micro-second resolution is probably >>>> granular enough. >>>> I am just saying there is an advantage to use an existing time >>>> format (PTP/NTP) rather than to invent a new one. >>>> >>> IMHO anything better then millisec precision is unrealistic, >>> unneeded or rather just wishfull thinking. >>> - Have anyone ever seen a configuration operations that were >>> specified to this precision? >>> - It would be extremely fragile to depend on that level of >>> precision. AFAIK even in the most tightly controlled networks >>> network delays can fluctuate with milliseconds, so requiring >>> microsecond precision seems to be unrealistic. >>> - Do you foresee any real use cases needing that precision? >>> - How well are the timers of different nodes syncronised today? Do >>> we really have 1 microsecond syncronisation(or will have in the >>> next 10 years)? >>> regards Balazs >>> >>> -- >>> Balazs Lengyel Ericsson Hungary Ltd. >>> System Manager >>> ECN: 831 7320 Tel: +36-1-437-7320 >>> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >> >> >> >> > > -- > Balazs Lengyel Ericsson Hungary Ltd. > System Manager > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From mbj@tail-f.com Tue Jul 23 13:59:04 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842E011E8141 for ; Tue, 23 Jul 2013 13:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pNjQmoyYZqL for ; Tue, 23 Jul 2013 13:58:54 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE7B11E8135 for ; Tue, 23 Jul 2013 13:58:54 -0700 (PDT) Received: from localhost (213-65-182-102-no181.tbcn.telia.com [213.65.182.102]) by mail.tail-f.com (Postfix) with ESMTPSA id 74FAA1200A3A; Tue, 23 Jul 2013 22:58:52 +0200 (CEST) Date: Tue, 23 Jul 2013 22:58:52 +0200 (CEST) Message-Id: <20130723.225852.421217463.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130706184312.GA51144@elstar.local> References: <20130706184312.GA51144@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] standard YANG RFC publication X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 20:59:04 -0000 Juergen Schoenwaelder wrote: > On Sat, Jul 06, 2013 at 09:26:41AM -0700, Andy Bierman wrote: > > I want to understand how well this RFC publication process is going > > to work for the next 10 years. The purpose of using submodules is > > to avoid "the high cost of using an XML namespace". IMO the RFC > > publication issues are far worse than the message overhead incurred > > by using an additional namespace. The solution is worse than the > > original problem. > > Like with many things in life there are trade-offs and judgements may > differ as well. I am with Juergen on this one. It is a somewhat subjective matter, but I think the submodule design with a single namespace and include-by-revision leads to a simpler solution. Yes, the RFCs will have multiple normative references, but I do not think this is a problem. Since include-by-revison is used, it is clear which submodules are actually used. /martin From mbj@tail-f.com Tue Jul 23 14:03:35 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32F021F9011 for ; Tue, 23 Jul 2013 14:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id old9ETwekBhP for ; Tue, 23 Jul 2013 14:03:29 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 95A9721F9C37 for ; Tue, 23 Jul 2013 14:03:28 -0700 (PDT) Received: from localhost (213-65-182-102-no181.tbcn.telia.com [213.65.182.102]) by mail.tail-f.com (Postfix) with ESMTPSA id 495D21200A3A; Tue, 23 Jul 2013 23:03:26 +0200 (CEST) Date: Tue, 23 Jul 2013 23:03:25 +0200 (CEST) Message-Id: <20130723.230325.519839200.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <51E67CAA.5000604@ericsson.com> References: <20130716181845.GB85215@elstar.local> <51E67CAA.5000604@ericsson.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] standard YANG RFC publication X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 21:03:35 -0000 Hi, Balazs Lengyel wrote: > Hello, > Having the same module published in many RFCs is a recipe for > mistakes. People will keep using the module from the incorrect > RFC. I don't know what the incorrect RFC would be. Since include-by-revision is used, you cannot mix an old module with a newer submodule. > Also why bother people with keeping track of the correct version > if it does not need to be done. > > AFAIK one of the main reasons for having the augment statement was > that ONLY the augmenting module needs to be touched. If we thought > that was an important idea, why are we not following it now. (I don't > really see any advantages of the submodule approach.) With this logic, you would also never update a published module; always use augment to add new stuff instead. submodules should be viewed as a way to split one module / namespace into smaller pieces. External augment has its places (as was mentioned, the routing module is designed for use with external augmentation), and submodule augmentation has its places. /martin From mbj@tail-f.com Tue Jul 23 14:15:34 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F9811E8135 for ; Tue, 23 Jul 2013 14:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnuYsIDJoeKb for ; Tue, 23 Jul 2013 14:15:28 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B5C1D11E80FA for ; Tue, 23 Jul 2013 14:15:27 -0700 (PDT) Received: from localhost (213-65-182-102-no181.tbcn.telia.com [213.65.182.102]) by mail.tail-f.com (Postfix) with ESMTPSA id A303A1200A39; Tue, 23 Jul 2013 23:15:26 +0200 (CEST) Date: Tue, 23 Jul 2013 23:15:26 +0200 (CEST) Message-Id: <20130723.231526.481513327.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netconf@ietf.org Subject: Re: [Netconf] Are namespaces required for extra attributes? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 21:15:34 -0000 Andy Bierman wrote: > Hi, > = > According to my interpretation of the text and XSD in RFC 6241, > and the XSD definition of 'anyAttribute' and 'processContents', > the client is allowed to send extra attributes in the element > even if the namespaces are not used: > = > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > = > = > Is this interpretation correct? Yes this is also my interpretation; I also verified with xmllint just to be sure. > Either way the next NETCONF update should clarify this detail in > sec. 4.1. Ok. > RFC 6241:, sec 4.1, para 3: > = > If additional attributes are present in an element, a NETCON= F > peer MUST return them unmodified in the element. This= > includes any "xmlns" attributes. > = > = > RFC 6241, XSD, page 81: > = > > > > > use=3D"required"/> > > > > = > = > http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#pr= ocess_contents > = > = > lax: If the item has a uniquely determined declaration available, > it must be =B7valid=B7 > with respect to that definition, that is, =B7validate=B7 if you ca= n, > don't worry if you can't. /martin From mbj@tail-f.com Tue Jul 23 14:27:18 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E8F21F9815 for ; Tue, 23 Jul 2013 14:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhsA1WsC8TnX for ; Tue, 23 Jul 2013 14:27:12 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id D490411E82F4 for ; Tue, 23 Jul 2013 14:27:10 -0700 (PDT) Received: from localhost (213-65-182-102-no181.tbcn.telia.com [213.65.182.102]) by mail.tail-f.com (Postfix) with ESMTPSA id EB2E31200089; Tue, 23 Jul 2013 23:27:09 +0200 (CEST) Date: Tue, 23 Jul 2013 23:27:09 +0200 (CEST) Message-Id: <20130723.232709.326412097.mbj@tail-f.com> To: dew@tx.technion.ac.il From: Martin Bjorklund In-Reply-To: <20130709003047.Horde.23QgiHPWhnmFavvNTQ0UYg1@webmail.technion.ac.il> References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <20130709003047.Horde.23QgiHPWhnmFavvNTQ0UYg1@webmail.technion.ac.il> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: moses@ee.technion.ac.il, netconf@ietf.org Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 21:27:18 -0000 Hi, Tal Mizrahi wrote: > Unfortunately, the IETF does not have a single standard way to > represent time. The date-and-time format you refer to (RFC 3339) is > one way to go, but it only allows a 10th of a second resolution > (correct me if I am missing something) date-and-time (and RFC 3339) allow finer granularity than a 10th of a second. In fact, they allow any number of fraction digits of the second: time-secfrac = "." 1*DIGIT /martin From andy@yumaworks.com Tue Jul 23 15:38:35 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362CE11E8166 for ; Tue, 23 Jul 2013 15:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bIXfkY+gvqE for ; Tue, 23 Jul 2013 15:38:30 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAB411E813F for ; Tue, 23 Jul 2013 15:38:29 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj3so8972709pad.14 for ; Tue, 23 Jul 2013 15:38:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=PeVG/ofajUjpbrS3tG36idbF/dRLEA5yxg9OT+8xl0A=; b=Xd3jreGe3sAO2gA9HbyNmq04mE423lgMWAfvDVJFrO0UzPINjF00d83GhUZdYH8tY0 gR3+ub1mZGBhRiUCPx7u0CSYd21LYUA/N4WRKBgHhR6Qb5byg49v/Azr9o42IhPhubb2 nl0co0oIvp/JqbsIsP9elEl+mvIhDOVrGcSz/aZtJHJuAfN8sclwryvI0ocIvpI8iMZC ljlhWgINMn8BremJXscIU9W2X3R9Z6olYNWnascItQ6IP3A0ReSS6zXUsYMMZnXrbBhM 23VUFIl1mh/eajntwHeJJ8fIRH9sinxPVPrZB9RUrQKy73UoRVtiQc5GyUBWFmboGBw9 RVkw== MIME-Version: 1.0 X-Received: by 10.68.164.69 with SMTP id yo5mr38830412pbb.96.1374619109565; Tue, 23 Jul 2013 15:38:29 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 23 Jul 2013 15:38:29 -0700 (PDT) In-Reply-To: <20130723.232709.326412097.mbj@tail-f.com> References: <20130708104818.Horde.WJEDWO_XoOj_pIO2WxwcEg5@webmail.technion.ac.il> <20130709003047.Horde.23QgiHPWhnmFavvNTQ0UYg1@webmail.technion.ac.il> <20130723.232709.326412097.mbj@tail-f.com> Date: Tue, 23 Jul 2013 15:38:29 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn9chL1U0fexeCIwPvfr51MbsOFMIJq0GTh+CTjQSaEHW73TCFcA0XMc9vejFZfuCzERmzy Cc: netconf@ietf.org, moses@ee.technion.ac.il Subject: Re: [Netconf] New draft: draft-mm-netconf-time-capability-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 22:38:35 -0000 Hi, I don't think it will be clear which RFC is the current one. The problem is that RFC YYYY updates XXXX and does not obsolete XXXX. Only the main module is obsolete, but the submodules may in fact still be current. (i.e., copy old include-stmt into new main module). The WG overhead is not that significant either way. The deciding factor should be how confusing this will be to readers over time. Andy On Tue, Jul 23, 2013 at 2:27 PM, Martin Bjorklund wrote: > Hi, > > Tal Mizrahi wrote: >> Unfortunately, the IETF does not have a single standard way to >> represent time. The date-and-time format you refer to (RFC 3339) is >> one way to go, but it only allows a 10th of a second resolution >> (correct me if I am missing something) > > date-and-time (and RFC 3339) allow finer granularity than a 10th of a > second. In fact, they allow any number of fraction digits of the > second: > > time-secfrac = "." 1*DIGIT > > > /martin From bclaise@cisco.com Thu Jul 25 04:03:52 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5878B21F888F for ; Thu, 25 Jul 2013 04:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.568 X-Spam-Level: X-Spam-Status: No, score=-10.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbM0rozd787B for ; Thu, 25 Jul 2013 04:03:48 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id EDA7021F8887 for ; Thu, 25 Jul 2013 04:03:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6PB3diK015118; Thu, 25 Jul 2013 13:03:39 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6PB2vcn002549; Thu, 25 Jul 2013 13:03:13 +0200 (CEST) Message-ID: <51F105CE.6050907@cisco.com> Date: Thu, 25 Jul 2013 13:02:38 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ietfdbh References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local> <20130711074446.GA23993@ruth> <00a201ce7e24$76a04360$63e0ca20$@comcast.net> In-Reply-To: <00a201ce7e24$76a04360$63e0ca20$@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 11:03:52 -0000 Hi, > Hi, > > A major reason for moving from SNMP's ASN.1 binary encoding to XML's > text-based encoding was operator request. > > Operators preferred a solution that was readable on-the-wire, so they could > look at packet-dumps and see the information being passed. I just re-read RFC 3535, section 3, hoping to see that requirement in the list, but could not find it. Regards, Benoit > Operators found that SNMP packets had to be decoded by (non-standard) > applications to make the data human-readable, and often an application UI > never showed the raw varbinds; and the information presented to the operator > might have been cached, or might have been "interpreted" before being shown > to the operator. Even when the decoded raw varbinds were shown, such as with > a MIB browser, the OIDs were not human-friendly. By having the data encoded > in XML, the on-the-wire packet content was readable in a packet dump, and > the labels were meaningful. (Of course, with encryption, the content was > unreadable.) > > I would be interested in seeing a discussion of these points in a comparison > of XML, EXI, and "ssh -C" encodings. Such discussion should probably include > whether popular packet sniffing tools, both commercial and open source, > supported the formats, and at what level in the transfer of information > between systems (i.e. in the network stack and/or the Netconf architecture) > an operator can access something human-readable. > > It would also be interesting to discuss the adoption level of each approach. > EXI was approved in 2011; When was "ssh -C" approved as a standard? > Do we have any information about how many commercial/open-source toolkits > support the standards? > > I don't know EXI. Wikipedia indicates EXI uses "schema-informed" > compression, and the decoder needs a copy of the same schema that the > encoder used . How would this potentially affect Netconf? Assuming multiple > Netconf clients (NMSes) talk to multiple Netconf servers, does that mean > that each client must have the managed-device-specific schema for each > device, and each netconf server must have a copy of the schema used by each > client? While such an approach might be viable for a web browser/web server > relationship, where each is hosted on a device that is not very resource > constrained, but what impact would this have on devices with significant > resource constraints (as is common with Netconf)? > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >> Behalf Of Michal 'vorner' Vaner >> Sent: Thursday, July 11, 2013 3:45 AM >> To: netconf@ietf.org >> Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga- >> netconf-exi-capability-00.txt >> >> Good morning >> >> On Thu, Jul 11, 2013 at 09:23:14AM +0200, Juergen Schoenwaelder wrote: >>> On Thu, Jul 11, 2013 at 08:22:23AM +0200, Robert Varga wrote: >>>> I have just uploaded a new draft specifying an extension to NETCONF >>>> protocol which allows the message encoding to be switched to >>>> Efficient XML Interchange (EXI). >>> Did you implement this? If so, what is the gain in >>> >>> a) consumed bandwidth, >>> b) reduced code size, >>> c) runtime overhead? >> May I suggest to compare it with enabling compression in the underlying > ssh >> connection, with `ssh -C` or equivalent? >> >> With regards >> >> -- >> Michal 'vorner' Vaner >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From bertietf@bwijnen.net Thu Jul 25 04:51:30 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90C421F9AA2 for ; Thu, 25 Jul 2013 04:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.504 X-Spam-Level: X-Spam-Status: No, score=-100.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVcZHvTSuBaY for ; Thu, 25 Jul 2013 04:51:25 -0700 (PDT) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by ietfa.amsl.com (Postfix) with ESMTP id E278F21F9A94 for ; Thu, 25 Jul 2013 04:51:24 -0700 (PDT) Received: from BertLaptop (a83-163-239-181.adsl.xs4all.nl [83.163.239.181]) (authenticated bits=0) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id r6PBpCHi001272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Jul 2013 13:51:14 +0200 (CEST) (envelope-from bertietf@bwijnen.net) Message-ID: <058A5AC4D069418BA79252A18EEB8079@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Benoit Claise" , "ietfdbh" References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local><20130711074446.GA23993@ruth><00a201ce7e24$76a04360$63e0ca20$@comcast.net> <51F105CE.6050907@cisco.com> In-Reply-To: <51F105CE.6050907@cisco.com> Date: Thu, 25 Jul 2013 13:46:48 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: netconf@ietf.org Subject: Re: [Netconf] Fwd: New Version Notification fordraft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 11:51:31 -0000 Inline ----- Original Message ----- From: "Benoit Claise" To: "ietfdbh" Cc: Sent: Thursday, July 25, 2013 1:02 PM Subject: Re: [Netconf] Fwd: New Version Notification fordraft-varga-netconf-exi-capability-00.txt > Hi, >> Hi, >> >> A major reason for moving from SNMP's ASN.1 binary encoding to XML's >> text-based encoding was operator request. >> >> Operators preferred a solution that was readable on-the-wire, so they could >> look at packet-dumps and see the information being passed. > I just re-read RFC 3535, section 3, hoping to see that requirement in the > list, but could not find it. > Not sure if it is explicitly documented. But I also recall that Operators wanted asci on the line. Now this extension would still allow non-binary transmission. So may be that is acceptable? Can any operators chime in? Bert From j.schoenwaelder@jacobs-university.de Thu Jul 25 07:31:51 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C973621F99E9 for ; Thu, 25 Jul 2013 07:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAjFbzoAtP3y for ; Thu, 25 Jul 2013 07:31:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 756CE21F99E3 for ; Thu, 25 Jul 2013 07:31:46 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C98F720CFB; Thu, 25 Jul 2013 16:31:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7k5p_aeKRHzg; Thu, 25 Jul 2013 16:31:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11E5D20D3C; Thu, 25 Jul 2013 16:31:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 869DB2779684; Thu, 25 Jul 2013 16:31:40 +0200 (CEST) Date: Thu, 25 Jul 2013 16:31:39 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20130725143139.GA42280@elstar.local> Mail-Followup-To: Benoit Claise , ietfdbh , netconf@ietf.org References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local> <20130711074446.GA23993@ruth> <00a201ce7e24$76a04360$63e0ca20$@comcast.net> <51F105CE.6050907@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51F105CE.6050907@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 14:31:51 -0000 On Thu, Jul 25, 2013 at 01:02:38PM +0200, Benoit Claise wrote: > > > >Operators preferred a solution that was readable on-the-wire, so they could > >look at packet-dumps and see the information being passed. > > I just re-read RFC 3535, section 3, hoping to see that requirement > in the list, but could not find it. I think operators actually preferred protocols that are _not_ readable on the wire. And this is why we use SSH as the default transport - without keys, the traffic is not readable on the wire by design. ;-) I think the most important requirement was captured in #10: The configuration itself should be in a format that allows to use off-the-shelf tools to process them. (Not exactly the wording in RFC 3535.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Thu Jul 25 07:48:29 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6C121F99D7 for ; Thu, 25 Jul 2013 07:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+kgrfGBREue for ; Thu, 25 Jul 2013 07:48:25 -0700 (PDT) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id E577521F9B0E for ; Thu, 25 Jul 2013 07:48:14 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un1so852277pbc.1 for ; Thu, 25 Jul 2013 07:48:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=g2kUZVR3T6PbnI+iUlHvR+mp5rh7og7lEshP89oPGFY=; b=fLgISENk9WX6J75hmFV4XrePUPt7sgB2JcXKIDTgDGG7Alk4MK33cnMJks8BaX5fHH 3Oiq04hGrlN7HiGteSNueROoqj3Bnbs3jFDd0hRcnCApm6U4fHounOoQ0bxhxqF4+VhP hI10Xu0siAYKXfIA3Pa/E3wkU6kVePhfzGTaHjUeHF7ex0YSFp5p8/wI6lNhF8kbIHdQ ON7yERodBD7u1z4gWGasx3I5vEL3aAhcKXZdhqbLdhZlqGWsFSVFxPLDoIeYSMNKM+9h h96mpt+QaoXte1zfoWj4xPPe3xi8cbQ5CLAu6TGuN3ldMKv497xhKm0a0lH3knqoZRIc 8mzQ== MIME-Version: 1.0 X-Received: by 10.66.253.40 with SMTP id zx8mr49925999pac.71.1374763694612; Thu, 25 Jul 2013 07:48:14 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Thu, 25 Jul 2013 07:48:14 -0700 (PDT) In-Reply-To: <20130725143139.GA42280@elstar.local> References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local> <20130711074446.GA23993@ruth> <00a201ce7e24$76a04360$63e0ca20$@comcast.net> <51F105CE.6050907@cisco.com> <20130725143139.GA42280@elstar.local> Date: Thu, 25 Jul 2013 07:48:14 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Benoit Claise , ietfdbh , netconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkT/cGXmQqn1bjHSXZblBAg8yoEc4rqOkbD8BK7q7pmops3PrrKMRuUrs2DT1f2fcxZ2SrP Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 14:48:29 -0000 Hi, What matters are the tools available to display the protocol messages. For REST, it is very nice that any browser will display JSON or XML. If a common tool like a browser or an xterm is all you need to debug protocol messages, that is better than if special tools need to be installed first. SSH is not wireshark-friendly. It does a much better job with HTTP. Andy On Thu, Jul 25, 2013 at 7:31 AM, Juergen Schoenwaelder wrote: > On Thu, Jul 25, 2013 at 01:02:38PM +0200, Benoit Claise wrote: >> > >> >Operators preferred a solution that was readable on-the-wire, so they could >> >look at packet-dumps and see the information being passed. >> >> I just re-read RFC 3535, section 3, hoping to see that requirement >> in the list, but could not find it. > > I think operators actually preferred protocols that are _not_ readable > on the wire. And this is why we use SSH as the default transport - > without keys, the traffic is not readable on the wire by design. ;-) > > I think the most important requirement was captured in #10: The > configuration itself should be in a format that allows to use > off-the-shelf tools to process them. (Not exactly the wording in > RFC 3535.) > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Thu Jul 25 08:05:09 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8962E21F99C1 for ; Thu, 25 Jul 2013 08:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BX6YN-ZrfHEo for ; Thu, 25 Jul 2013 08:05:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 464E321F9A99 for ; Thu, 25 Jul 2013 08:05:03 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B056720D65; Thu, 25 Jul 2013 17:05:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vY-YtXF2uZPB; Thu, 25 Jul 2013 17:05:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C37AE20D51; Thu, 25 Jul 2013 17:05:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2188627798D1; Thu, 25 Jul 2013 17:04:58 +0200 (CEST) Date: Thu, 25 Jul 2013 17:04:58 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130725150457.GA42471@elstar.local> Mail-Followup-To: Andy Bierman , Benoit Claise , ietfdbh , netconf@ietf.org References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local> <20130711074446.GA23993@ruth> <00a201ce7e24$76a04360$63e0ca20$@comcast.net> <51F105CE.6050907@cisco.com> <20130725143139.GA42280@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 15:05:09 -0000 On Thu, Jul 25, 2013 at 07:48:14AM -0700, Andy Bierman wrote: > Hi, > > What matters are the tools available to display the > protocol messages. For REST, it is very nice > that any browser will display JSON or XML. > > If a common tool like a browser or an xterm is all you > need to debug protocol messages, that is better than > if special tools need to be installed first. > > SSH is not wireshark-friendly. It does a much better job > with HTTP. > I do not care how wireshark-friendly is defined. I do agree that availability of a large variety of tools and APIs for different programming and scripting languages matters. And yes, this is where REST and JSON wins today (but I am old enough to know that popular encodings come and go). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Thu Jul 25 09:38:57 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417FE21F90DC for ; Thu, 25 Jul 2013 09:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.244 X-Spam-Level: X-Spam-Status: No, score=-99.244 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, DATE_IN_FUTURE_03_06=0.274, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjuoP8fRiJwF for ; Thu, 25 Jul 2013 09:38:39 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id C895721F8925 for ; Thu, 25 Jul 2013 09:38:38 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta03.westchester.pa.mail.comcast.net with comcast id 4atf1m0020bG4ec53geeRl; Thu, 25 Jul 2013 16:38:38 +0000 Received: from [10.0.4.96] ([89.246.150.136]) by omta03.westchester.pa.mail.comcast.net with comcast id 4ge51m0112wpE7M3PgeBsP; Thu, 25 Jul 2013 16:38:33 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Thu, 25 Jul 2013 18:38:04 -0400 From: David Harrington To: Benoit Claise Message-ID: Thread-Topic: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt In-Reply-To: <51F105CE.6050907@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374770318; bh=RW89QAerxNuK4/txlu9oG0+c423lvw2Avb3siUqaQ98=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=Dijek2C9jLhRZSPdaPzvDzdatB7cTvjpQC1z2kB0ZKGJNGQQlNk/vwQzb7AIn3uTk 6DP56eZd2jr/qqC9z7hB1VOuqHYXPV45tg6ImuV1wZ+mqC/Sz1Vv09dqCVWus1DeM4 tQMqT5eV3CARHxzd2urHFLoHmgENN1Y0QMm5mX1a0NAe9kFzUdV1t0tGbdp+r41ZRW dYlWxgtM/eJk1SkPzs8Pt5iaAylPMsRYU4U+hc3TUhiUw3w+SggE1AOk+PGobqLE8E XXv97B0CuYAd5qlLWH4Zt0C86Ho033ExnwP/z3HlunQotYL8LeKRBwCAy+8CTnqurx 8xFBufmrJU8jw== Cc: netconf@ietf.org Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 16:38:57 -0000 Not every operator request got documented in rfc3535. There was a mailing list for discussing nm directions, and other discussions. Part of the reason, as others are pointing out is ascii-tool compatibility (like diff). Another reason is that the ASN.1 was not easily read/translated/groked, so specialty applications were needed to translate from varbinds into something human readable. But operators didn't fully trust the applications to accurately reflect what was being sent across the wire. Some applications translated certain types incorrectly, but some agents sent certain types incorrectly, and the operator could not easily tell who was really at fault. Some applications used cached values, rather than sending new queries, which impacted interpretation of the results. So for various reasons, operators wanted an encoding they could understand without having to rely on (potentially-faulty) specialty tools. -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 7/25/13 7:02 AM, "Benoit Claise" wrote: >Hi, >> Hi, >> >> A major reason for moving from SNMP's ASN.1 binary encoding to XML's >> text-based encoding was operator request. >> >> Operators preferred a solution that was readable on-the-wire, so they >>could >> look at packet-dumps and see the information being passed. >I just re-read RFC 3535, section 3, hoping to see that requirement in >the list, but could not find it. > >Regards, Benoit >> Operators found that SNMP packets had to be decoded by (non-standard) >> applications to make the data human-readable, and often an application >>UI >> never showed the raw varbinds; and the information presented to the >>operator >> might have been cached, or might have been "interpreted" before being >>shown >> to the operator. Even when the decoded raw varbinds were shown, such as >>with >> a MIB browser, the OIDs were not human-friendly. By having the data >>encoded >> in XML, the on-the-wire packet content was readable in a packet dump, >>and >> the labels were meaningful. (Of course, with encryption, the content was >> unreadable.) >> >> I would be interested in seeing a discussion of these points in a >>comparison >> of XML, EXI, and "ssh -C" encodings. Such discussion should probably >>include >> whether popular packet sniffing tools, both commercial and open source, >> supported the formats, and at what level in the transfer of information >> between systems (i.e. in the network stack and/or the Netconf >>architecture) >> an operator can access something human-readable. >> >> It would also be interesting to discuss the adoption level of each >>approach. >> EXI was approved in 2011; When was "ssh -C" approved as a standard? >> Do we have any information about how many commercial/open-source >>toolkits >> support the standards? >> >> I don't know EXI. Wikipedia indicates EXI uses "schema-informed" >> compression, and the decoder needs a copy of the same schema that the >> encoder used . How would this potentially affect Netconf? Assuming >>multiple >> Netconf clients (NMSes) talk to multiple Netconf servers, does that mean >> that each client must have the managed-device-specific schema for each >> device, and each netconf server must have a copy of the schema used by >>each >> client? While such an approach might be viable for a web browser/web >>server >> relationship, where each is hosted on a device that is not very resource >> constrained, but what impact would this have on devices with significant >> resource constraints (as is common with Netconf)? >> >> David Harrington >> ietfdbh@comcast.net >> +1-603-828-1401 >> >>> -----Original Message----- >>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >>> Behalf Of Michal 'vorner' Vaner >>> Sent: Thursday, July 11, 2013 3:45 AM >>> To: netconf@ietf.org >>> Subject: Re: [Netconf] Fwd: New Version Notification for draft-varga- >>> netconf-exi-capability-00.txt >>> >>> Good morning >>> >>> On Thu, Jul 11, 2013 at 09:23:14AM +0200, Juergen Schoenwaelder wrote: >>>> On Thu, Jul 11, 2013 at 08:22:23AM +0200, Robert Varga wrote: >>>>> I have just uploaded a new draft specifying an extension to NETCONF >>>>> protocol which allows the message encoding to be switched to >>>>> Efficient XML Interchange (EXI). >>>> Did you implement this? If so, what is the gain in >>>> >>>> a) consumed bandwidth, >>>> b) reduced code size, >>>> c) runtime overhead? >>> May I suggest to compare it with enabling compression in the underlying >> ssh >>> connection, with `ssh -C` or equivalent? >>> >>> With regards >>> >>> -- >>> Michal 'vorner' Vaner >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > From kwatsen@juniper.net Thu Jul 25 22:14:27 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6D021F86B1 for ; Thu, 25 Jul 2013 22:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzyGedBCVcaX for ; Thu, 25 Jul 2013 22:14:22 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id A171821F8628 for ; Thu, 25 Jul 2013 22:14:21 -0700 (PDT) Received: from mail63-db9-R.bigfish.com (10.174.16.229) by DB9EHSOBE014.bigfish.com (10.174.14.77) with Microsoft SMTP Server id 14.1.225.22; Fri, 26 Jul 2013 05:14:19 +0000 Received: from mail63-db9 (localhost [127.0.0.1]) by mail63-db9-R.bigfish.com (Postfix) with ESMTP id BC4D48801B8 for ; Fri, 26 Jul 2013 05:14:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF03-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h1de096h8275bh8275dhz2fh2a8h683h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail63-db9: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=kwatsen@juniper.net; helo=P-EMF03-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail63-db9 (localhost.localdomain [127.0.0.1]) by mail63-db9 (MessageSwitch) id 1374815657544331_27831; Fri, 26 Jul 2013 05:14:17 +0000 (UTC) Received: from DB9EHSMHS008.bigfish.com (unknown [10.174.16.237]) by mail63-db9.bigfish.com (Postfix) with ESMTP id 7F95864004A for ; Fri, 26 Jul 2013 05:14:17 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.52) by DB9EHSMHS008.bigfish.com (10.174.14.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 26 Jul 2013 05:14:16 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF03-SAC.jnpr.net (172.24.192.19) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 25 Jul 2013 22:14:14 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Thu, 25 Jul 2013 22:14:14 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.189) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 25 Jul 2013 22:27:15 -0700 Received: from mail97-co1-R.bigfish.com (10.243.78.237) by CO1EHSOBE029.bigfish.com (10.243.66.94) with Microsoft SMTP Server id 14.1.225.22; Fri, 26 Jul 2013 05:14:13 +0000 Received: from mail97-co1 (localhost [127.0.0.1]) by mail97-co1-R.bigfish.com (Postfix) with ESMTP id 7CF7F80028A for ; Fri, 26 Jul 2013 05:14:13 +0000 (UTC) Received: from mail97-co1 (localhost.localdomain [127.0.0.1]) by mail97-co1 (MessageSwitch) id 1374815651880042_30908; Fri, 26 Jul 2013 05:14:11 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.241]) by mail97-co1.bigfish.com (Postfix) with ESMTP id D397B1C0047; Fri, 26 Jul 2013 05:14:11 +0000 (UTC) Received: from CH1PRD0511HT005.namprd05.prod.outlook.com (157.56.245.197) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 26 Jul 2013 05:14:09 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.108]) by CH1PRD0511HT005.namprd05.prod.outlook.com ([10.255.159.40]) with mapi id 14.16.0329.000; Fri, 26 Jul 2013 05:14:08 +0000 From: Kent Watsen To: Martin Bjorklund , "andy@yumaworks.com" Thread-Topic: [Netconf] Are namespaces required for extra attributes? Thread-Index: AQHOeyteFo/yfIYsn0WUrb4maegElZly3SkAgANnV4A= Date: Fri, 26 Jul 2013 05:14:07 +0000 Message-ID: In-Reply-To: <20130723.231526.481513327.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1D67574991F7C94B8D542A9495B01D9B@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%TAIL-F.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "netconf@ietf.org" Subject: Re: [Netconf] Are namespaces required for extra attributes? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 05:14:27 -0000 I always saw this as a good thing, that the client could pass an opaque and have it reliable returned to them, even if not namespaced. Kent On 7/23/13 5:15 PM, "Martin Bjorklund" wrote: >Andy Bierman wrote: >> Hi, >>=20 >> According to my interpretation of the text and XSD in RFC 6241, >> and the XSD definition of 'anyAttribute' and 'processContents', >> the client is allowed to send extra attributes in the element >> even if the namespaces are not used: >>=20 >> > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >> >> >>=20 >>=20 >> Is this interpretation correct? > >Yes this is also my interpretation; I also verified with xmllint just >to be sure. > >> Either way the next NETCONF update should clarify this detail in >> sec. 4.1. > >Ok. > >> RFC 6241:, sec 4.1, para 3: >>=20 >> If additional attributes are present in an element, a NETCONF >> peer MUST return them unmodified in the element. This >> includes any "xmlns" attributes. >>=20 >>=20 >> RFC 6241, XSD, page 81: >>=20 >> >> >> >> >> > use=3D"required"/> >> >> >> >>=20 >>=20 >>=20 >>http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#proces >>s_contents >>=20 >>=20 >> lax: If the item has a uniquely determined declaration available, >> it must be =B7valid=B7 >> with respect to that definition, that is, =B7validate=B7 if you can, >> don't worry if you can't. > > >/martin >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf > > From ietfc@btconnect.com Fri Jul 26 01:33:19 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07C121F8AA1 for ; Fri, 26 Jul 2013 01:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fO4FTqy8G1N5 for ; Fri, 26 Jul 2013 01:33:12 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id BB87221F8925 for ; Fri, 26 Jul 2013 01:33:09 -0700 (PDT) Received: from mail97-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.22; Fri, 26 Jul 2013 08:33:08 +0000 Received: from mail97-va3 (localhost [127.0.0.1]) by mail97-va3-R.bigfish.com (Postfix) with ESMTP id 5D7022A00FB; Fri, 26 Jul 2013 08:33:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -15 X-BigFish: PS-15(zf7Iz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL1de097h8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail97-va3 (localhost.localdomain [127.0.0.1]) by mail97-va3 (MessageSwitch) id 1374827586538795_7399; Fri, 26 Jul 2013 08:33:06 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.247]) by mail97-va3.bigfish.com (Postfix) with ESMTP id 70BAC300057; Fri, 26 Jul 2013 08:33:06 +0000 (UTC) Received: from AMSPRD0711HT002.eurprd07.prod.outlook.com (157.56.250.181) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 26 Jul 2013 08:33:04 +0000 Received: from DB3PRD0511HT003.eurprd05.prod.outlook.com (157.56.254.213) by pod51017.outlook.com (10.242.14.163) with Microsoft SMTP Server (TLS) id 14.16.329.3; Fri, 26 Jul 2013 08:33:02 +0000 Message-ID: <009901ce89da$ba284440$4001a8c0@gateway.2wire.net> From: t.petch To: "Bert Wijnen (IETF)" , Benoit Claise References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local><20130711074446.GA23993@ruth><00a201ce7e24$76a04360$63e0ca20$@comcast.net><51F105CE.6050907@cisco.com> <058A5AC4D069418BA79252A18EEB8079@BertLaptop> Date: Fri, 26 Jul 2013 09:32:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.254.213] X-OriginatorOrg: btconnect.com Cc: netconf@ietf.org Subject: Re: [Netconf] Fwd: New Version Notificationfordraft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 08:33:19 -0000 Tom Petch ----- Original Message ----- From: "Bert Wijnen (IETF)" To: "Benoit Claise" ; "ietfdbh" Cc: Sent: Thursday, July 25, 2013 12:46 PM > Inline > ----- Original Message ----- > From: "Benoit Claise" > To: "ietfdbh" > Cc: > Sent: Thursday, July 25, 2013 1:02 PM > > Hi, > >> Hi, > >> > >> A major reason for moving from SNMP's ASN.1 binary encoding to XML's > >> text-based encoding was operator request. > >> > >> Operators preferred a solution that was readable on-the-wire, so they could > >> look at packet-dumps and see the information being passed. > > I just re-read RFC 3535, section 3, hoping to see that requirement in the > > list, but could not find it. > > > Not sure if it is explicitly documented. But I also recall that Operators wanted > asci > on the line. Now this extension would still allow non-binary transmission. So > may > be that is acceptable? > > Can any operators chime in? Bert No way am I an operator, but in RFC3535, I do see " o SNMP requires applications to be useful. SNMP was, from its early days, designed as a programmatic interface between management applications and devices. As such, using SNMP without management applications or smart tools appears to be more complicated." and " 12. Textual configuration files should be able to contain international characters. Human-readable strings should utilize the least-bad internationalized character set and encoding, which this year almost certainly means UTF-8. Protocol elements should be in case insensitive ASCII." which I think is as close as we get. Tom Petch > > Bert > From bclaise@cisco.com Mon Jul 29 22:45:35 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A48D11E81B9 for ; Mon, 29 Jul 2013 22:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJJyXW6UgSZU for ; Mon, 29 Jul 2013 22:45:30 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C5F9111E8174 for ; Mon, 29 Jul 2013 22:45:29 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6U5jQFl015497; Tue, 30 Jul 2013 07:45:27 +0200 (CEST) Received: from [10.61.164.23] ([10.61.164.23]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6U5j52f011148; Tue, 30 Jul 2013 07:45:16 +0200 (CEST) Message-ID: <51F752BC.5050209@cisco.com> Date: Tue, 30 Jul 2013 07:44:28 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "netconf-chairs@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETCONF , sec-ads@tools.ietf.org Subject: [Netconf] Agenda for the NETCONF meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 05:45:35 -0000 Dear all, Sean Turner, one of the security ADs, will be joining our NETCONF meeting for the reverse SSH discussion. Would it be possible to change the agenda, and discuss the Reverse Secure Shell (Reverse SSH) - K. Watsen (30 min.) after 16h20? He is not available before. Regards, Benoit From mehmet.ersue@nsn.com Tue Jul 30 04:10:36 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C717D11E814F; Tue, 30 Jul 2013 04:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTQMLmsA8r6r; Tue, 30 Jul 2013 04:10:32 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 029BA11E810F; Tue, 30 Jul 2013 04:10:31 -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 r6UBASKU002255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Jul 2013 13:10:28 +0200 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6UBAOnF018620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 13:10:26 +0200 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 30 Jul 2013 13:10:24 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.59]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Tue, 30 Jul 2013 13:10:16 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Benoit Claise , NETCONF Thread-Topic: [Netconf] Agenda for the NETCONF meeting Thread-Index: AQHOjOgFO7A9+f0kdE69Y2t1eMeM7pl9D/kw Date: Tue, 30 Jul 2013 11:10:16 +0000 Message-ID: References: <51F752BC.5050209@cisco.com> In-Reply-To: <51F752BC.5050209@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.98] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1031 X-purgate-ID: 151667::1375182628-00002EAE-2144DDE3/0-0/0-0 Cc: "sec-ads@tools.ietf.org" , "saag@ietf.org" Subject: Re: [Netconf] Agenda for the NETCONF meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:10:37 -0000 Dear Netconf WG, please be aware that the agenda for the NETCONF session has changed (see be= low). http://www.ietf.org/proceedings/87/agenda/agenda-87-netconf=20 Kent, Sean: Please forward to saag wg and ssh people. Cheers,=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behal= f Of ext > Benoit Claise > Sent: Tuesday, July 30, 2013 7:44 AM > To: netconf-chairs@tools.ietf.org > Cc: NETCONF; sec-ads@tools.ietf.org > Subject: [Netconf] Agenda for the NETCONF meeting >=20 > Dear all, >=20 > Sean Turner, one of the security ADs, will be joining our NETCONF > meeting for the reverse SSH discussion. > Would it be possible to change the agenda, and discuss the Reverse > Secure Shell (Reverse SSH) - K. Watsen (30 min.) after 16h20? > He is not available before. >=20 > Regards, Benoit > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From balazs.lengyel@ericsson.com Tue Jul 30 05:34:22 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2040D21E80C5 for ; Tue, 30 Jul 2013 05:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.489 X-Spam-Level: X-Spam-Status: No, score=-4.489 tagged_above=-999 required=5 tests=[AWL=1.160, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AANMVyvWaM8 for ; Tue, 30 Jul 2013 05:34:16 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B77EA21E80CD for ; Tue, 30 Jul 2013 05:34:15 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-0d-51f7b2c4a591 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D4.79.05990.4C2B7F15; Tue, 30 Jul 2013 14:34:12 +0200 (CEST) Received: from [153.88.45.27] (153.88.183.146) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.328.9; Tue, 30 Jul 2013 14:34:12 +0200 Message-ID: <51F7B2C3.9010803@ericsson.com> Date: Tue, 30 Jul 2013 14:34:11 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: t.petch References: <20130711061148.14911.83495.idtracker@ietfa.amsl.com> <51DE4F1F.1040207@pantheon.sk> <20130711072314.GA69009@elstar.local><20130711074446.GA23993@ruth><00a201ce7e24$76a04360$63e0ca20$@comcast.net><51F105CE.6050907@cisco.com> <058A5AC4D069418BA79252A18EEB8079@BertLaptop> <009901ce89da$ba284440$4001a8c0@gateway.2wire.net> In-Reply-To: <009901ce89da$ba284440$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvre6RTd8DDRZv0LA4+ljCoqPjFZvF tUf3WSymbrrN6sDisevoD3aPW9cfsXhM+b2R1WPJkp9MASxRXDYpqTmZZalF+nYJXBnzGvay FuwQqWjZsZylgfEhfxcjJ4eEgInE/JmXmCFsMYkL99azdTFycQgJHGaU2LaslQnCWcUo8XnX TDaQKl4BbYmdS9cygtgsAqoSC5e8B4uzCRhJTO0/zwJiiwpESbT2TmWGqBeUODnzCVhcREBR 4lTLBDCbWSBD4u6MFlYQW1ggQWLqg9vMEMvOMkls/rMZbCingL3Eve2z2CEabCUuzLkO1Swv sf3tHLAFQgIaEg8v/GWdwCg4C8m+WUhaZiFpWcDIvIqRPTcxMye93GgTIzB4D275rbqD8c45 kUOM0hwsSuK8m/XOBAoJpCeWpGanphakFsUXleakFh9iZOLglGpglI26oN1pvMDkxeMLt9rn rZi+i8s17n72rIffir5Hed9Zcrm/kUGXaTH/fBsv9YAg7mXLfJasTvAst+2okJEQ2bM05pbu /PBclTMmT9TeRefyyjJNyAz7qLs5fwv//CMzLf5VnGH+3Xw5uHvrpfslt3Vfq2Y9t7314I3v dE7+OSuuKQg3JDpMUWIpzkg01GIuKk4EANaE87IsAgAA Cc: netconf@ietf.org Subject: Re: [Netconf] Fwd: New Version Notificationfordraft-varga-netconf-exi-capability-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 12:34:22 -0000 Hello, One thing that scared me in this approach was the schema dependent encoding, which would mean that anyone handling the messages needs to have a big set of schemas (all in their correct version). That could become a nightmare, so it is good we will avoid that :-) Balazs On 2013-07-26 10:32, t.petch wrote: > > Tom Petch > > ----- Original Message ----- > From: "Bert Wijnen (IETF)" > To: "Benoit Claise" ; "ietfdbh" > Cc: > Sent: Thursday, July 25, 2013 12:46 PM >> Inline >> ----- Original Message ----- >> From: "Benoit Claise" >> To: "ietfdbh" >> Cc: >> Sent: Thursday, July 25, 2013 1:02 PM >>> Hi, >>>> Hi, >>>> >>>> A major reason for moving from SNMP's ASN.1 binary encoding to > XML's >>>> text-based encoding was operator request. >>>> >>>> Operators preferred a solution that was readable on-the-wire, so > they could >>>> look at packet-dumps and see the information being passed. >>> I just re-read RFC 3535, section 3, hoping to see that requirement > in the >>> list, but could not find it. >>> >> Not sure if it is explicitly documented. But I also recall that > Operators wanted >> asci >> on the line. Now this extension would still allow non-binary > transmission. So >> may >> be that is acceptable? >> >> Can any operators chime in? > Bert > > No way am I an operator, but in RFC3535, I do see > " o SNMP requires applications to be useful. SNMP was, from its > early > days, designed as a programmatic interface between management > applications and devices. As such, using SNMP without management > applications or smart tools appears to be more complicated." > and > " 12. Textual configuration files should be able to contain > international characters. Human-readable strings should utilize > the least-bad internationalized character set and encoding, which > this year almost certainly means UTF-8. Protocol elements should > be in case insensitive ASCII." > > > which I think is as close as we get. > > Tom Petch > >> Bert >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From stpeter@stpeter.im Wed Jul 31 07:22:19 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7884C11E818B for ; Wed, 31 Jul 2013 07:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OIex3YhIB7t for ; Wed, 31 Jul 2013 07:22:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5C17721F9DF3 for ; Wed, 31 Jul 2013 07:22:13 -0700 (PDT) Received: from che-vpn-cluster-2-456.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A53EFF1DDC; Wed, 31 Jul 2013 08:24:26 -0600 (MDT) Message-ID: <51F91D91.2080502@stpeter.im> Date: Wed, 31 Jul 2013 16:22:09 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Netconf X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:22:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Since the chairs cut off the mic line, here is feedback on the topic of notifications. On long polling, please see RFC 6202. There are issues. On notifications, please think carefully about your latency and scalability requirements. It's likely that a RESTful approach will work fine (and will be easier to scale up because you can use existing HTTP infrastructure), but if you need very low latency (say, less than 100ms) then you might need to look into a different technology (say, XMPP). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR+R2RAAoJEOoGpJErxa2pdFYP/RwhEk9bXLosj858zCInpDy/ KPxVswlPhlD736hlGibsHH6xVpD396LmT+YIrcHeld6ehFSd0tYV3/suHYejn0G7 JFkNHybvYhf7HzJOBtwxCMswQA9bNt+Tz0FQ0nZ4gJIPYYJk7hcQmkUCyANRIY+w /e0Z4f3s0ZRCfwvoE7PfWdKFnRw54CSQFVjjYt2ZJasgEMyv8M3DRPaULZQNeGxu mpaCASahNo2IQYcBbT9Y5xEPJCGVwXU3RsWmQpyOnzUqaPyo5S4ndMHWoZ1dGhyd 3kPE5fR1qIiQALvHmAbf0zr962WCWfyo8MhYjV2E30UEnwfX6kqk0V8QQZPGPIsJ vM3xHXnY5ZSxe0URrbuZC0dPGKXCiZSMCBpbWblGIWziqqhz+/dxX0dZnS43tC34 KOy+w0Pu51oqk1o1Sdo3QQ4cFp+WQkmiqlerQyUx0yDUiCTWUHXdWJc8zISgD8vW wf1KDXlO2HddDX5ESMSlXzV82W/gXoGtRmBgTg/ojnW9JBfhDFVzeXXmiGH5OIB7 i7m7eswuxGb3A7V6GPxU1pSiR1Xh4GYsg+IkhkvcI4w2pHs5pi5FKh6W9OKEUBAT Wwy8IpJPE0c53bc75SwX8C7EtNpg/xqoYsdlgp4L1EqLy0biOzl7jLvwRBjJdEyK wpYO7IlTpDOx/NULh/1u =ShOq -----END PGP SIGNATURE-----