From j.schoenwaelder@jacobs-university.de Thu Aug 1 01:48:59 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5AC21F9E7C for ; Thu, 1 Aug 2013 01:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=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 O6GSbPXAx8CM for ; Thu, 1 Aug 2013 01:48:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5E51F21F9E9A for ; Thu, 1 Aug 2013 01:48:48 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2CC920BF9; Thu, 1 Aug 2013 10:48:46 +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 EK8GLjgArBL8; Thu, 1 Aug 2013 10:48:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 52F4D20BF6; Thu, 1 Aug 2013 10:48:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 586FD27A1E17; Thu, 1 Aug 2013 10:48:43 +0200 (CEST) Date: Thu, 1 Aug 2013 10:48:43 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20130801084843.GA25224@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] comments on draft-clemm-netmod-yang-network-topo-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:49:00 -0000 Hi, I have read the document with quite some interest since it kind of paves the way to do _network_ management instead of just device management. I am wondering about two little technical details: a) Why do you not use YANG identities to represent topology types? b) Why do you use inet:uri as the base type for node-id, link-id, and tp-id? The I-D status says 'Intended Status: Experimental' - was your idea to submit this for eventual publication as an experimental RFC? /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 Aug 1 02:04:45 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E80721F9BF1 for ; Thu, 1 Aug 2013 02:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=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 yg6inrz5bNjB for ; Thu, 1 Aug 2013 02:04:39 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id 86CE921F9A81 for ; Thu, 1 Aug 2013 02:04:38 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id p11so1784848pdj.32 for ; Thu, 01 Aug 2013 02:04:38 -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=FzBUmf0PJ2QtRaaa7fTeiOXVZRovepxMqWjglb27gdU=; b=Lyt/nHcdhVAHq/kbYl+bayCk9622m5hYeJnigLW5oAItBnX6HyfAJerizTfZGoaZgi 4k3FT7qwOzy2/NPNhmweBHulA7QbGur13fNDGsnnVzpfk3YsDTvyKBi7nBxmCYPf31aF 95kppUINeXaby1Z80zAvY8Qwq2eNyPW1zMcevp6y0LNeuPxnwk762TK8P46wxDECn9X+ 3lRuS9/BIVLTROCPjT0vGkqre6NLe3oDPkX9Fynkyec0Y0gGeFAJZYkv4nTAAQrvtVv8 43Tk5KsvaSrccPQoAWYnr96pPm6p+d4BxcJN9gvAxTZbKf1txCQzGYnUjcOUdXXNz4Dy FAZw== MIME-Version: 1.0 X-Received: by 10.68.135.162 with SMTP id pt2mr703250pbb.42.1375347878376; Thu, 01 Aug 2013 02:04:38 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Thu, 1 Aug 2013 02:04:38 -0700 (PDT) In-Reply-To: <20130801084843.GA25224@elstar.local> References: <20130801084843.GA25224@elstar.local> Date: Thu, 1 Aug 2013 02:04:38 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn80pOSH3DC3vALSaBfaNeZhV5DEj+/o+dzP5E1cQifC2J+i8lfOehTOMIIbvNxuSmVWAna Subject: Re: [netmod] comments on draft-clemm-netmod-yang-network-topo-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:04:45 -0000 Hi, I just want to add that I was very impressed with this draft. A lot of work was done on the design and the actual data node specifications, and it shows. I support adoption of this draft as a NETMOD work item, to produce a standards track RFC. (agree w/Juergen Experimental is not desirable). Andy On Thu, Aug 1, 2013 at 1:48 AM, Juergen Schoenwaelder wrote: > Hi, > > I have read the document with quite some interest since it kind of > paves the way to do _network_ management instead of just device > management. I am wondering about two little technical details: > > a) Why do you not use YANG identities to represent topology types? > > b) Why do you use inet:uri as the base type for node-id, link-id, and > tp-id? > > The I-D status says 'Intended Status: Experimental' - was your idea to > submit this for eventual publication as an experimental RFC? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Thu Aug 1 02:19:11 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0596A21F964C for ; Thu, 1 Aug 2013 02:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 mmzt8izEk3WR for ; Thu, 1 Aug 2013 02:19:09 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5308921F8E3D for ; Thu, 1 Aug 2013 02:19:04 -0700 (PDT) Received: from [IPv6:2001:df8::16:c455:a9bb:c641:c0f2] (unknown [IPv6:2001:df8:0:16:c455:a9bb:c641:c0f2]) by mail.nic.cz (Postfix) with ESMTPSA id 71C7A13FDA1 for ; Thu, 1 Aug 2013 11:18:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375348738; bh=t58dIAo2P3+RthiE7/qY6Y9K5TF7WnvdDeaHb3FY26s=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=CjIZqLXeMA6MlDvuFrvrvmaffpRDz3NTC50BE3N+CpvmSRLHleZa3Jq176Zt0QRrk 5prYxOIC96r5UzTu0HDJNLUx2Mv9tyP0h54J1DnhAtLsjzrlktxaHA36491ULl+KFk pmq5zzVBT5doh9rm0gdXmQwedOwtDvL4GtBYpaCs= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7C1C9EF1-2735-4053-AC49-A4F3FB806125@nic.cz> Date: Thu, 1 Aug 2013 11:18:57 +0200 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: [netmod] comments on draft-zhdankin-netmod-bgp-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:19:11 -0000 Hi, my main objection against this draft is that is completely bypasses the = core routing data model. I understand that it is easier to map the logic of a vendor-specific = configuration to a YANG module that is built from scratch, but then we = might end up with several alternative data models for each routing = protocol. One of the objectives stated in the routing-cfg document is that the = routing data model should enable mapping of proprietary data models. And = indeed, throughout the development of the core routing data model we = always tried to allow for such mappings, at least for the major router = implementations.=20 There is nothing wrong on using YANG for expressing proprietary data = models but IMO the data models developed and standardised in the IETF = should be vendor-neutral and should serve as a lingua franca to which = the proprietary models can be mapped (and vice versa). Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Thu Aug 1 04:00:33 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2898A21E8089 for ; Thu, 1 Aug 2013 04:00:33 -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_23=0.6, J_CHICKENPOX_43=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 1Ipl57UCHq6t for ; Thu, 1 Aug 2013 04:00:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2744C21E805F for ; Thu, 1 Aug 2013 04:00:27 -0700 (PDT) Received: from dhcp-10e3.meeting.ietf.org (dhcp-10e3.meeting.ietf.org [130.129.16.227]) by mail.nic.cz (Postfix) with ESMTPSA id 9207013FDA1; Thu, 1 Aug 2013 13:00:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375354824; bh=GbYQHWOgUaNpV/IkTidF5mUsnSQRTrdhB4+xGvta+8w=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=OI3CvGTK9qFz2wfCih8YfvaHoR3HJOq/DdyZC4NmhVh17s4r1xOEwVhR4eZM+Kl/u UjUMdnju0KCX2F5IOjGz64NSJxeL6+hcb6zhciU1b7w53GjQ2UyfHriNLPiSP2r/rA X8mZ1YY8cOSjz2XV8Jt9oXOpEdvFJJ1wD8Wv/eTI= 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, 1 Aug 2013 13:00:24 +0200 Content-Transfer-Encoding: 7bit Message-Id: <869CC112-E4DC-4A20-A1B1-814D65A31708@nic.cz> References: <20130801084843.GA25224@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-clemm-netmod-yang-network-topo-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 11:00:33 -0000 On Aug 1, 2013, at 11:04 AM, Andy Bierman wrote: > Hi, > > I just want to add that I was very impressed with this draft. > A lot of work was done on the design and the actual data node > specifications, and it shows. > > I support adoption of this draft as a NETMOD work item, > to produce a standards track RFC. > (agree w/Juergen Experimental is not desirable). +1 Lada > > > Andy > > > On Thu, Aug 1, 2013 at 1:48 AM, Juergen Schoenwaelder > wrote: >> Hi, >> >> I have read the document with quite some interest since it kind of >> paves the way to do _network_ management instead of just device >> management. I am wondering about two little technical details: >> >> a) Why do you not use YANG identities to represent topology types? >> >> b) Why do you use inet:uri as the base type for node-id, link-id, and >> tp-id? >> >> The I-D status says 'Intended Status: Experimental' - was your idea to >> submit this for eventual publication as an experimental RFC? >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From bclaise@cisco.com Thu Aug 1 05:25:17 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA7421F9DC6 for ; Thu, 1 Aug 2013 05:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.243 X-Spam-Level: X-Spam-Status: No, score=-10.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 7FNGpJATd1lz for ; Thu, 1 Aug 2013 05:24:47 -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 D57CB21E819E for ; Thu, 1 Aug 2013 05:20:42 -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 r71CKZaX018582 for ; Thu, 1 Aug 2013 14:20:35 +0200 (CEST) Received: from [10.61.99.120] (dhcp-10-61-99-120.cisco.com [10.61.99.120]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r71CKKcP009445 for ; Thu, 1 Aug 2013 14:20:30 +0200 (CEST) Message-ID: <51FA5280.2050505@cisco.com> Date: Thu, 01 Aug 2013 14:20:16 +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: NETMOD Working Group References: <20130731141356.E17E46212E@rfc-editor.org> In-Reply-To: <20130731141356.E17E46212E@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] RFC 6991 on Common YANG Data Types X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:25:19 -0000 Just in time! Congrats the author, chairs, and entire WG. Regards, Benoit > A new Request for Comments is now available in online RFC libraries. > > > RFC 6991 > > Title: Common YANG Data Types > Author: J. Schoenwaelder, Ed. > Status: Standards Track > Stream: IETF > Date: July 2013 > Mailbox: j.schoenwaelder@jacobs-university.de > Pages: 30 > Characters: 60242 > Obsoletes: RFC6021 > > I-D Tag: draft-ietf-netmod-rfc6021-bis-03.txt > > URL: http://www.rfc-editor.org/rfc/rfc6991.txt > > This document introduces a collection of common data types to be used > with the YANG data modeling language. This document obsoletes RFC > 6021. > > This document is a product of the NETCONF Data Modeling Language Working Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php > For downloading RFCs, see http://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > From mbj@tail-f.com Thu Aug 1 09:50:31 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171BC21E80BF for ; Thu, 1 Aug 2013 09:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.250, 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 qXvTtxlCiZaC for ; Thu, 1 Aug 2013 09:50:15 -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 DEAD521F9D1E for ; Thu, 1 Aug 2013 09:50:14 -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 C735612000A3 for ; Thu, 1 Aug 2013 18:50:09 +0200 (CEST) Date: Thu, 01 Aug 2013 18:50:07 +0200 (CEST) Message-Id: <20130801.185007.338342419.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund 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 Subject: [netmod] YANG extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 16:50:31 -0000 Hi, I'd just like to comment on Kent's last comment in the session today. He said that Juniper tried to use YANG, but it wasn't suitable, so they had to add all kinds of YANG extensions. First of all, it is important to understand that YANG's extension mechanism is very powerful, but it be disastrous to interoperability if not used carefully. The way to think about an extension is that if a client does not understand the extension, the clienbt should still be able to communicate with the device correctly. For example, adding an extension to make a key in a list optional would break interoperability, but adding an extension that classifies a config false node into operational state and statistics would not. (I am specificially referring to NETCONF interoperability here). (We have one extension that breaks this rule, and I truly regret that we added it - it has caused much more trouble than it solved) Second, it would be interesting to know what you meant when you said that it was not suitable. If you meant that you could not use YANG to describe all your *current* behavior, it is not all surprising (well...). But if you meant that the YANG-defined behavior is completely unacceptable (even if it wasn't for backwards-compatibility with you current behavior), it would be very useful to know what it is. /martin From j.schoenwaelder@jacobs-university.de Fri Aug 2 00:55:57 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D98311E82A3 for ; Fri, 2 Aug 2013 00:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.24 X-Spam-Level: X-Spam-Status: No, score=-103.24 tagged_above=-999 required=5 tests=[AWL=0.009, 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 IWjE5-rWYqoJ for ; Fri, 2 Aug 2013 00:55:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B200F11E8296 for ; Fri, 2 Aug 2013 00:55:32 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 825A520C1F; Fri, 2 Aug 2013 09:55:27 +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 80t9ZM0vDz07; Fri, 2 Aug 2013 09:55:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DEAF620C14; Fri, 2 Aug 2013 09:55:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 232B827A34D0; Fri, 2 Aug 2013 09:55:22 +0200 (CEST) Date: Fri, 2 Aug 2013 09:55:22 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20130802075522.GA28010@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] ietf 87 meeting summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 07:55:57 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, here is a quick summary of the WG meeting in Berlin. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-summary.txt" The NETMOD working group has met for 1.5 hours on Thursday, August 1st, during the 87th IETF meeting. The meeting was attended by ~50 people. * Several documents are in WG last call and more reviews are needed. Some additional people were recruited during the meeting to perform reviews of the latest version of draft-ietf-netmod-iana-if-type-07 draft-ietf-netmod-interfaces-cfg-12, draft-ietf-netmod-system-mgmt-08, and draft-ietf-netmod-iana-timezones-00. * The routing documents draft-ietf-netmod-iana-afn-safi-00 and draft-ietf-netmod-routing-cfg-10 are technically complete. Lada will work with authors of the I2RS working group to harmonize things with the information model defined by the I2RS working group but this must be completed the latest by the next IETF meeting in Vancouver; the NETMOD WG is not going to wait for the I2RS WG to complete its work. * Some minor issues need to be resolved on the SNMP configuration model. The next revision of draft-ietf-netmod-snmp-cfg-02 is expected to be complete and ready for WG last call. * A new individual draft was presented and discussed which defines a generic data model for presenting network topologies. This I-D is related to an information model submission to the I2RS WG. * The open mike discussion centered around the future role of the WG, if it is time to move data model work out of NETMOD into other working groups, how to provide guidelines to data model writers, and whether the YANG specification should be revised to make it less dependent on NETCONF concepts and whether new features should be added the YANG. --h31gzZEtNLTqOjlF-- From ietfdbh@comcast.net Fri Aug 2 13:18:42 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10BE21F9D80 for ; Fri, 2 Aug 2013 13:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.445 X-Spam-Level: X-Spam-Status: No, score=-99.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 nNHT-qBaVytV for ; Fri, 2 Aug 2013 13:18:38 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:17]) by ietfa.amsl.com (Postfix) with ESMTP id 3646621F9D7B for ; Fri, 2 Aug 2013 13:18:38 -0700 (PDT) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta10.emeryville.ca.mail.comcast.net with comcast id 7ubx1m0031GXsucAAwJdg4; Fri, 02 Aug 2013 20:18:37 +0000 Received: from [172.16.35.20] ([212.80.234.130]) by omta07.emeryville.ca.mail.comcast.net with comcast id 7wJM1m0032pUVVw8UwJQ6J; Fri, 02 Aug 2013 20:18:35 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Fri, 02 Aug 2013 09:28:15 +0200 From: David Harrington To: Martin Bjorklund , Message-ID: Thread-Topic: [netmod] YANG extensions In-Reply-To: <20130801.185007.338342419.mbj@tail-f.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=1375474717; bh=TwD9YBBwCZCnDYBxgMRoYKmeflaU0wUR+9+XS5+6VwE=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=HMCGTJFThKzGgGCwnQMkuYQ3t2EDpYVcWM2nurelLZaI4xKFhV8DxwRmdfYNOWYQk 1iiBcwLY3zX/zspzaGsm+IHdLDSQsjj6L7XFF597V2d1ygD4B19lH3BZtb61wW29Mi uo+NH0dix0kfzrcVvqKPxNvFLGztwtTscWBbz4kDtKDpzh6dzzLO+8EXny4UnhXMdu /zrV3KkgpSw03TQY2p/yUVMHbIKT6oFTng9IYJ7VpcfubuH5JX76chs9bteihaDjUt oID9ISLqGFMvfX7keKlTxZ+phTXz8gfkMXm+93unk/vJxV9f9yiPnCenZUZKROAYkh Cj3Z8HP5DfjLQ== Subject: Re: [netmod] YANG extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 20:18:42 -0000 Maybe YANG is just not a suitable choice for the use case in mind, and making YANG suitable for that use case could break YANG for other use cases for which YANG was designed ... It would certainly be useful to understand the use case for which YANG is considered not suitable. I say this partly in response to yesterday's meeting, where people from other WGs seem to have whole new areas of usage that YANG and Netconf weren't designed for specifically, and the answer to the unsuitability seems to be to redesign YANG and Netconf to meet their specific needs. -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 8/1/13 6:50 PM, "Martin Bjorklund" wrote: >Hi, > >I'd just like to comment on Kent's last comment in the session today. >He said that Juniper tried to use YANG, but it wasn't suitable, so they >had to add all kinds of YANG extensions. > >First of all, it is important to understand that YANG's extension >mechanism is very powerful, but it be disastrous to interoperability >if not used carefully. The way to think about an extension is that if >a client does not understand the extension, the clienbt should still >be able to communicate with the device correctly. For example, adding >an extension to make a key in a list optional would break >interoperability, but adding an extension that classifies a config >false node into operational state and statistics would not. (I am >specificially referring to NETCONF interoperability here). > >(We have one extension that breaks this rule, and I truly regret that >we added it - it has caused much more trouble than it solved) > >Second, it would be interesting to know what you meant when you said >that it was not suitable. If you meant that you could not use YANG to >describe all your *current* behavior, it is not all surprising >(well...). But if you meant that the YANG-defined behavior is >completely unacceptable (even if it wasn't for backwards-compatibility >with you current behavior), it would be very useful to know what it >is. > > >/martin >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Fri Aug 2 14:03:54 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0F521F9CE3 for ; Fri, 2 Aug 2013 14:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.900, 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 tVplRNIIpy+x for ; Fri, 2 Aug 2013 14:03:50 -0700 (PDT) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id 95EB821F9C10 for ; Fri, 2 Aug 2013 14:03:50 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id up15so1100304pbc.40 for ; Fri, 02 Aug 2013 14:03:50 -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=v5815g6/ooucVs2rYZDAKUZnziOBMC/030TVyHq7t88=; b=cUm1poeWrBP/75XLoPWt0eLGEFT+pd/yunapu9iyanHnQsiEa1KQp0fj/wDWgKI5Q7 aGq1OYF1S4g+VYakeMR9SYsa+88r5xT9IhZOfdjnK6E4sCDUQ4UQQ4U5PQNimsSOY+AH npOggarc0J9yTd0punjgIHHg94wQhra13BhjOxgIuf6M/AFvrwCFwqMRcnSDPK+dkBiE k9CXn+FwnnvvzWhuFXSVKOdNty/rHMo2cfJ8GujOwCze4LYNwRU6JCXMKQZ5cdVx4Hl6 fE+4RDODlU8gcRR4PR3u8KhCLIGxooB6oOm/+fY/h/9Kws7ybMl+9JvA1Vzq2lS1Qtp8 d59A== MIME-Version: 1.0 X-Received: by 10.66.232.101 with SMTP id tn5mr12444117pac.132.1375477430254; Fri, 02 Aug 2013 14:03:50 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Fri, 2 Aug 2013 14:03:50 -0700 (PDT) In-Reply-To: References: <20130801.185007.338342419.mbj@tail-f.com> Date: Fri, 2 Aug 2013 14:03:50 -0700 Message-ID: From: Andy Bierman To: David Harrington Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm4w+m3CV9bbmYZcfjkljvUVILtujTWpzX3TD9iERlIEPg2T0QZ5xkI8rsFlaKIsRiLa7Mj Cc: netmod@ietf.org Subject: Re: [netmod] YANG extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 21:03:54 -0000 Hi, This thread is a whole lot of hand-waving, and not at all useful, except Martin's advice on extension transparency. NETCONF deals with a single server, so I am not sure why we need YANG extensions to replicate configs across a cluster. I think the "YANG Mount Point" draft is probably a more comprehensive solution to complex config distribution across multiple servers. The biggest complaint I hear from customers about YANG is the choice-stmt. There are many situations where deleting the old case when a new case is selected is not desirable. IMO, the conditional enablement draft offers the best solution for maintaining data node states other than "active". The notion of using 1 YANG "template" to generate N different variants may be beyond the scope of YANG, but also something customers want. Andy On Fri, Aug 2, 2013 at 12:28 AM, David Harrington wrote: > > Maybe YANG is just not a suitable choice for the use case in mind, and > making YANG suitable for that use case could break YANG for other use > cases for which YANG was designed ... > > It would certainly be useful to understand the use case for which YANG is > considered not suitable. > > I say this partly in response to yesterday's meeting, where people from > other WGs seem to have whole new areas of usage that YANG and Netconf > weren't designed for specifically, and the answer to the unsuitability > seems to be to redesign YANG and Netconf to meet their specific needs. > > > -- > David Harrington > Ietfdbh@comcast.net > +1-603-828-1401 > > > > > > On 8/1/13 6:50 PM, "Martin Bjorklund" wrote: > >>Hi, >> >>I'd just like to comment on Kent's last comment in the session today. >>He said that Juniper tried to use YANG, but it wasn't suitable, so they >>had to add all kinds of YANG extensions. >> >>First of all, it is important to understand that YANG's extension >>mechanism is very powerful, but it be disastrous to interoperability >>if not used carefully. The way to think about an extension is that if >>a client does not understand the extension, the clienbt should still >>be able to communicate with the device correctly. For example, adding >>an extension to make a key in a list optional would break >>interoperability, but adding an extension that classifies a config >>false node into operational state and statistics would not. (I am >>specificially referring to NETCONF interoperability here). >> >>(We have one extension that breaks this rule, and I truly regret that >>we added it - it has caused much more trouble than it solved) >> >>Second, it would be interesting to know what you meant when you said >>that it was not suitable. If you meant that you could not use YANG to >>describe all your *current* behavior, it is not all surprising >>(well...). But if you meant that the YANG-defined behavior is >>completely unacceptable (even if it wasn't for backwards-compatibility >>with you current behavior), it would be very useful to know what it >>is. >> >> >>/martin >>_______________________________________________ >>netmod mailing list >>netmod@ietf.org >>https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From randy_presuhn@mindspring.com Fri Aug 2 14:51:58 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F33511E80D7 for ; Fri, 2 Aug 2013 14:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 mqtKsTgEBYW2 for ; Fri, 2 Aug 2013 14:51:52 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAB711E80F9 for ; Fri, 2 Aug 2013 14:51:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rTmawqwYaBLpJ0CK0LL6tMsqd/6rYsq3bVhrU8FwEjHhBwoTgBgyDb9EeTWmEW+K; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.160.142] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1V5NGJ-0002Oi-49 for netmod@ietf.org; Fri, 02 Aug 2013 17:51:51 -0400 Message-ID: <001301ce8fca$6cb09280$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20130801.185007.338342419.mbj@tail-f.com> Date: Fri, 2 Aug 2013 14:51:16 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ba196d48fc2e3f0821b5cbeebbff70182986866f97a77f36350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.160.142 Subject: Re: [netmod] YANG extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 21:51:58 -0000 Hi - > From: "Andy Bierman" > To: "David Harrington" > Cc: > Sent: Friday, August 02, 2013 2:03 PM > Subject: Re: [netmod] YANG extensions ... > NETCONF deals with a single server, so I am not sure why we > need YANG extensions to replicate configs across a cluster. I think you just anwered your own question here. But I think it's more than just replication across a cluster, which might potentially be handled by the cluster itself. >From the perspective of *network* operation, configuration is not about a single server's configuration, but rather about a set of communicating systems. To the extent that NETCONF still doesn't really address *network* configuration, folks will continue to try to bolt it on through extensions and ad hoc model work-arounds. > I think the "YANG Mount Point" draft is probably a more comprehensive > solution to complex config distribution across multiple servers. Providing a coherent framwork for operating on the set of device-specific configurations that collectively constitue a network's configuration would be the next logical step. Unfortunately, I don't see how netconf's naming architecture woud facilitate such a thing. > The biggest complaint I hear from customers about YANG is > the choice-stmt. There are many situations where deleting > the old case when a new case is selected is not desirable. > IMO, the conditional enablement draft offers the best solution > for maintaining data node states other than "active". Analogous to the source-code problem (or non-problem, depending on how one looks at it) of #ifdef, commented-out, and "dead" code. > The notion of using 1 YANG "template" to generate N different variants > may be beyond the scope of YANG, but also something customers want. For a long time configuration data has included scripts and code. "Conditional enablement" is just a really degenerate case of that. I think when reasoning about the configuration of a system it's important to be able to distinguish between the configuration data and the results of evaluating that configuration data in a particular system in a particular operating environment at a particular point in time. Randy From andy@yumaworks.com Fri Aug 2 15:20:09 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0C711E810E for ; Fri, 2 Aug 2013 15:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[AWL=0.344, 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 lqfEZdjE-otx for ; Fri, 2 Aug 2013 15:20:05 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1B92A11E8109 for ; Fri, 2 Aug 2013 15:20:05 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id p11so1124804pdj.4 for ; Fri, 02 Aug 2013 15:20:04 -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=nnz4jcVbfx+OFCMM89znM5slKbGEvHGq7Wcf4kiGUm8=; b=BITS15/Q46i8kjAAJuU3QU7hTHhS6jOcHIwrp5BSea2187c7xA702zI+Kn+1nFDycl jujpSsfoLsLrr4bn+tKB21Q1YtLFsT2lIXQLTKDj8PkVfx+a6iIZhOfAs/TTaw6la2AW NU3aaM3mtSzCTRXWD+soH3cjduT59mgtcR0pUSoYS1rhxaeSHaHx34uFlJ7OHL3nHDE8 WnzBXFHgE1el29i5aDCgSgqCfvnv5kCloVkmUF9AHa5VZUtCw5qX4ToeUaORKOHKS2yA 7IwBv8gcnzqdJ+nemSYMIgKX091or1FnnqpIixKnmKo7i5JrwjVqi2VUfooCAIBwUwnE zp6g== MIME-Version: 1.0 X-Received: by 10.66.232.101 with SMTP id tn5mr12675062pac.132.1375482004761; Fri, 02 Aug 2013 15:20:04 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Fri, 2 Aug 2013 15:20:04 -0700 (PDT) In-Reply-To: <001301ce8fca$6cb09280$6b01a8c0@oemcomputer> References: <20130801.185007.338342419.mbj@tail-f.com> <001301ce8fca$6cb09280$6b01a8c0@oemcomputer> Date: Fri, 2 Aug 2013 15:20:04 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkrLqNXvE6632zQoWH72QPKyg0gb5n6RA+tsRoiKBwErhMC1CUFPHIDC4fDyyrtJ9ue/Bhy Cc: netmod@ietf.org Subject: Re: [netmod] YANG extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 22:20:09 -0000 On Fri, Aug 2, 2013 at 2:51 PM, Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "David Harrington" >> Cc: >> Sent: Friday, August 02, 2013 2:03 PM >> Subject: Re: [netmod] YANG extensions > ... >> NETCONF deals with a single server, so I am not sure why we >> need YANG extensions to replicate configs across a cluster. > > I think you just anwered your own question here. > But I think it's more than just replication across a cluster, > which might potentially be handled by the cluster itself. Network-wide config is a harder problem than cluster mgmt. A cluster is a set of switches being managed as if it were a single server. Since NETCONF is a protocol between a single client and a single server, it will probably take more than a minor tweak to support network-wide configuration correctly. > > From the perspective of *network* operation, > configuration is not about a single server's configuration, > but rather about a set of communicating systems. > To the extent that NETCONF still doesn't really address > *network* configuration, folks will continue to try to bolt > it on through extensions and ad hoc model work-arounds. > I don't see this as a defect in NETCONF. It does what it was designed to do, and new functionality will require new work. >> I think the "YANG Mount Point" draft is probably a more comprehensive >> solution to complex config distribution across multiple servers. > > Providing a coherent framwork for operating on the set of device-specific > configurations that collectively constitue a network's configuration would > be the next logical step. Unfortunately, I don't see how netconf's > naming architecture woud facilitate such a thing. not sure what this means -- I agree that the NETCONF datastore is associated with a single server. Not sure how data naming could change in a way that does not break old clients. > >> The biggest complaint I hear from customers about YANG is >> the choice-stmt. There are many situations where deleting >> the old case when a new case is selected is not desirable. >> IMO, the conditional enablement draft offers the best solution >> for maintaining data node states other than "active". > > Analogous to the source-code problem (or non-problem, depending > on how one looks at it) of #ifdef, commented-out, and "dead" code. > The conditional enablement draft has several types of config state that allow much more than #ifdef functionality, such as time-based and event-based triggers. >> The notion of using 1 YANG "template" to generate N different variants >> may be beyond the scope of YANG, but also something customers want. > > For a long time configuration data has included scripts and code. > "Conditional enablement" is just a really degenerate case of that. > I think when reasoning about the configuration of a system it's > important to be able to distinguish between the configuration data > and the results of evaluating that configuration data in a particular > system in a particular operating environment at a particular point in time. > A comprehensive YANG pre-processor would be a useful tool for complex variance mgmt -- much better than YANG deviations. > Randy > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Fri Aug 2 23:41:45 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D7921E80DD for ; Fri, 2 Aug 2013 23:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=0.306, 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 UpjUubZxKqDd for ; Fri, 2 Aug 2013 23:41:40 -0700 (PDT) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by ietfa.amsl.com (Postfix) with ESMTP id 09DBF21E80C8 for ; Fri, 2 Aug 2013 23:41:32 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id 10so1404928pdc.33 for ; Fri, 02 Aug 2013 23:41:32 -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=90DZsListGq4cz+I8sOy8vTenar9we8tuIQBWcUq9vU=; b=eBOmVkfcHurDqpwE2Em7mCsJZnjyZzlnFJDEzbRhevzEjM0/0il116hhDymulTZZrV qbKg4IjS8oRrqkTXbF9q1fBmVvVF6/N9YUYM4A3ZYbJ6hN13jEH260QuJqJ+d/524YGF 9q2Hcbzzv1uuenZtb0auWZyCuep2ISpnWXObbaD9FwhQZmG2MJDri6kXKCmcH2/w7vBf XU34T9sl9Rgr6wuac19WvOtEQNwQQo7ORWf6Ni8+/xazMpj86fNVj6LlFts/6Nrgof+H tNu9BCklQJNIAgypTrPcJOSGDBe/PFa58wXQacYAmk7ddfpzLmBt1l6a1qsmfNNnjGIr iMNA== MIME-Version: 1.0 X-Received: by 10.66.159.72 with SMTP id xa8mr14433458pab.38.1375512092609; Fri, 02 Aug 2013 23:41:32 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Fri, 2 Aug 2013 23:41:32 -0700 (PDT) Date: Fri, 2 Aug 2013 23:41:32 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org, Netconf Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmPXMKkxu+42gwGiISDd5BEMK2MMN4FWgJP6wNG9INuMRl6uvA25yb0ab43EKn+WpF/AZlJ Subject: [netmod] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 06:41:45 -0000 Hi, I wold like the NETMOD and NETCONF WGs to establish a development plan and roadmap for the work that will be attempted over the next 1 to 3 years. One draft after another gets presented. Some, like the ACL draft or draft have had almost unanimous support as a problem that needs to be solved. Then quickly forgotten. The complete lack of any development plan discourages people from participating and probably encourages others who are just wasting their time submitting drafts to these WGs. I don't agree with the assertion that NETCONF/YANG will only be useful when it "manages everything" (like the proprietary CLI). It is useful now, but in order to be essential, the community needs to know that it is stable and understand when and how new functionality will be added. Andy From mbj@tail-f.com Sat Aug 3 00:34:00 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E85411E80F6 for ; Sat, 3 Aug 2013 00:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.214, 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 UruzKGNzSjl8 for ; Sat, 3 Aug 2013 00:33: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 AB7BA21F9FBD for ; Sat, 3 Aug 2013 00:33: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 4FBDC12000BC; Sat, 3 Aug 2013 09:33:52 +0200 (CEST) Date: Sat, 03 Aug 2013 09:33:52 +0200 (CEST) Message-Id: <20130803.093352.343329950.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20130801.185007.338342419.mbj@tail-f.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: netmod@ietf.org Subject: Re: [netmod] YANG extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 07:34:00 -0000 Andy Bierman wrote: > Hi, > > This thread is a whole lot of hand-waving, and not at all useful, > except Martin's advice on extension transparency. > > NETCONF deals with a single server, so I am not sure why we > need YANG extensions to replicate configs across a cluster. Where did this come from? I see two messages in this thread (one from me, and one from David), and neither mentions clusters. /martin From andy@yumaworks.com Sat Aug 3 00:44:34 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CAD11E810C for ; Sat, 3 Aug 2013 00:44:34 -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 0KSzoa8P-yXd for ; Sat, 3 Aug 2013 00:44:29 -0700 (PDT) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id 83EA621F95DD for ; Sat, 3 Aug 2013 00:44:26 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id d17so682304eek.14 for ; Sat, 03 Aug 2013 00:44:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=usR4mXX1IECScLXasIMgWdmzqtK8Ng6RRdIxQyW7QVA=; b=HJhNiBAvkqV5Qc048oQeQIfMnBBjUfi6VUl2ZLVxSwkp5yv9Tq2Mu7VFYj0Xgj8Asn UsFGwD9D2deu3RJK2p8YkeGN7mOvkBY8y6BWcUSLA1DYfIIhcQBu/PVQmM5SDPu/NrU9 6YYeZ0h5HfCWnKLQ8auiJPWxS1Y+3ZZayDrgzc6lXAji6Z/Blh3gZWAwXdH7BwkwD7nZ Bl8MvqhZ1pO53d5Gi49gD9fv0KlEatIZqXpP3T9Y5cpH8B5YodQTxvhHGiE+sgGOJUdS E/TPJzFM4pn57yLviwFyuJz2tDWYidjPo+JJ0YJsY5LPmW2qGPFAxARISb807C1MtkBE veFg== X-Received: by 10.15.94.142 with SMTP id bb14mr8612516eeb.112.1375515863474; Sat, 03 Aug 2013 00:44:23 -0700 (PDT) Received: from [10.185.10.179] ([46.189.28.102]) by mx.google.com with ESMTPSA id n42sm17563637eeh.15.2013.08.03.00.44.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 Aug 2013 00:44:22 -0700 (PDT) References: <20130801.185007.338342419.mbj@tail-f.com> <20130803.093352.343329950.mbj@tail-f.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20130803.093352.343329950.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <362CAEB8-6F74-491B-8784-92763E451915@yumaworks.com> X-Mailer: iPhone Mail (10B329) From: Andy Bierman Date: Sat, 3 Aug 2013 09:44:21 +0200 To: Martin Bjorklund X-Gm-Message-State: ALoCoQnTf9K5BeixLLZ1TkcG2ITGAQKtbt+Qwjl+CwWma0NKA5CTL0YItssbkHo4gt5W/AofHMj/ Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 07:44:35 -0000 It was discussed in the meeting. Sent from my iPhone On Aug 3, 2013, at 9:33, Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> This thread is a whole lot of hand-waving, and not at all useful, >> except Martin's advice on extension transparency. >> >> NETCONF deals with a single server, so I am not sure why we >> need YANG extensions to replicate configs across a cluster. > > Where did this come from? I see two messages in this thread (one from > me, and one from David), and neither mentions clusters. > > > /martin From mehmet.ersue@nsn.com Sat Aug 3 01:58:30 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB95221F8B35; Sat, 3 Aug 2013 01:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 g2-RQTIyaQRq; Sat, 3 Aug 2013 01:58:25 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 83C2221F9C34; Sat, 3 Aug 2013 01:58:25 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r738wOXr000626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 3 Aug 2013 10:58:24 +0200 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r738wNZj012912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Aug 2013 10:58:24 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.59]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Sat, 3 Aug 2013 10:58:23 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Andy Bierman , "netmod@ietf.org" , Netconf Thread-Topic: [Netconf] development plan Thread-Index: AQHOkBSbZaVYLzrrfEypVvCB71Bls5mDLUGw Date: Sat, 3 Aug 2013 08:58:23 +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.105] 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: 1446 X-purgate-ID: 151667::1375520304-0000471E-D6FE16C3/0-0/0-0 Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 08:58:30 -0000 We need to start somewhere to discuss the priorities. So, let's start here. What would be your proposal for the development plan?=20 Cheers,=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behal= f Of ext > Andy Bierman > Sent: Saturday, August 03, 2013 8:42 AM > To: netmod@ietf.org; Netconf > Subject: [Netconf] development plan >=20 > Hi, >=20 > I wold like the NETMOD and NETCONF WGs to establish a > development plan and roadmap for the work that will be attempted > over the next 1 to 3 years. >=20 > One draft after another gets presented. > Some, like the ACL draft or draft have had almost unanimous > support as a problem that needs to be solved. Then quickly forgotten. >=20 > The complete lack of any development plan discourages people > from participating and probably encourages others who are just > wasting their time submitting drafts to these WGs. >=20 > I don't agree with the assertion that NETCONF/YANG will only > be useful when it "manages everything" (like the proprietary CLI). > It is useful now, but in order to be essential, the community needs > to know that it is stable and understand when and how new functionality w= ill > be added. >=20 >=20 >=20 > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From andy@yumaworks.com Sat Aug 3 02:13:05 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A013D11E815C for ; Sat, 3 Aug 2013 02:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.775, 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 tYBmgrNxrwjG for ; Sat, 3 Aug 2013 02:13:01 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by ietfa.amsl.com (Postfix) with ESMTP id EA07211E8166 for ; Sat, 3 Aug 2013 02:12:55 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id el20so1003320lab.12 for ; Sat, 03 Aug 2013 02:12:54 -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=PbmKdy6GcRNCRcjS4P7bU0zb2mrHEVnctroMEg7zJ80=; b=HK2N4Lzt2T9I+LbXP/UFVFN/NPYXZsP5S++78zVBe1VRi9Jm8x6EDk9608yfpw0d2h 2ehXYZ1lr5SUbK2pTY5OMoPQ48rF9JTGvBMGr4paISColu/ZwmgUroho0wiA6GloR85h 7F8WzCbOKnm+CUUqvwSYscQbRu5xlO2rwG+8rvZxec8nGicPXHiK4YT9p702UZu1qBzB T9QjUFc3pprLcN8ju68aoH3gW1u+NWKEljwYhTIBwqbm5YLv11NxdfGMb+NJyiSQBW2f 8XfqPSAhoRu4bbuNvIsCbbxSkOsJTOneujyvnmrTu4YZz0XPYnTNQF7alx0LSCn5DZlP POqA== MIME-Version: 1.0 X-Received: by 10.152.27.9 with SMTP id p9mr4619284lag.4.1375521174687; Sat, 03 Aug 2013 02:12:54 -0700 (PDT) Received: by 10.112.30.136 with HTTP; Sat, 3 Aug 2013 02:12:54 -0700 (PDT) In-Reply-To: References: Date: Sat, 3 Aug 2013 02:12:54 -0700 Message-ID: From: Andy Bierman To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkBRbgkZmsign4Yq5F96MF31TaM4DEW8kXhvanwAG2pqfSaCc5896eDy6stHMOSzkMxjf9t Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 09:13:05 -0000 On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > We need to start somewhere to discuss the priorities. So, let's start here. > > What would be your proposal for the development plan? > This will take some time to work out, so I will just start with some design principles and fill in the details later. 1) current functionality that the community agrees is useful MUST NOT be broken in any way 2) current functionality that the community agrees is not useful SHOULD be removed 3) YANG needs to be a multi-protocol DML, but that does not mean written for unknown protocols. The protocol-independent and protocol-dependent aspects need to be clearly separated, allowing specific protocol mapping RFCs to be easily standardized 4) Important module infrastructure such as ACLs and topology need to be standardized in an extensible manner, allowing future (currently unknown) applications to build on these modules and not start over 5) The private candidate datastore is a disaster for multi-client deployments. A real transaction mechanism that does not rely on global or even predictive locking is needed. Concurrent transactions that do not collide can be processed in parallel. 6) Protocol performance and scaling properties need to be addressed 7) Network-wide applications need to be supported in a way that does not break existing single-server use cases > Cheers, > Mehmet Andy > >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] Behalf Of ext >> Andy Bierman >> Sent: Saturday, August 03, 2013 8:42 AM >> To: netmod@ietf.org; Netconf >> Subject: [Netconf] development plan >> >> Hi, >> >> I wold like the NETMOD and NETCONF WGs to establish a >> development plan and roadmap for the work that will be attempted >> over the next 1 to 3 years. >> >> One draft after another gets presented. >> Some, like the ACL draft or draft have had almost unanimous >> support as a problem that needs to be solved. Then quickly forgotten. >> >> The complete lack of any development plan discourages people >> from participating and probably encourages others who are just >> wasting their time submitting drafts to these WGs. >> >> I don't agree with the assertion that NETCONF/YANG will only >> be useful when it "manages everything" (like the proprietary CLI). >> It is useful now, but in order to be essential, the community needs >> to know that it is stable and understand when and how new functionality will >> be added. >> >> >> >> Andy >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf From lhotka@nic.cz Mon Aug 5 02:20:21 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4246D21F9D8A for ; Mon, 5 Aug 2013 02:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, HOST_EQ_CZ=0.904, 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 d42vlIQibxVd for ; Mon, 5 Aug 2013 02:19:57 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7888B21F9130 for ; Mon, 5 Aug 2013 02:15:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 72A5F540289; Mon, 5 Aug 2013 11:13:43 +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 Bw5-u2PqWipT; Mon, 5 Aug 2013 11:13:34 +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 F09A954022B; Mon, 5 Aug 2013 11:13:28 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , David Harrington In-Reply-To: References: <20130801.185007.338342419.mbj@tail-f.com> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: Andy Bierman , David Harrington , netmod@ietf.org Date: Mon, 05 Aug 2013 11:13:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] YANG extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 09:20:26 -0000 Andy Bierman writes: > Hi, > > This thread is a whole lot of hand-waving, and not at all useful, > except Martin's advice on extension transparency. > > NETCONF deals with a single server, so I am not sure why we > need YANG extensions to replicate configs across a cluster. > I think the "YANG Mount Point" draft is probably a more comprehensive > solution to complex config distribution across multiple servers. > > The biggest complaint I hear from customers about YANG is > the choice-stmt. There are many situations where deleting > the old case when a new case is selected is not desirable. I objected repeatedly against this kind of behaviour (also in connection with "when"). It is not server's business to tinker with configuration - it should be client's responsibility to prepare a valid configuration, and the server should only accept it or reject. So it in not a fault of the choice statement. > IMO, the conditional enablement draft offers the best solution > for maintaining data node states other than "active". I think this cannot be considered a replacement for "choice". Lada > > The notion of using 1 YANG "template" to generate N different variants > may be beyond the scope of YANG, but also something customers want. > > > Andy > > > On Fri, Aug 2, 2013 at 12:28 AM, David Harrington wrote: >> >> Maybe YANG is just not a suitable choice for the use case in mind, and >> making YANG suitable for that use case could break YANG for other use >> cases for which YANG was designed ... >> >> It would certainly be useful to understand the use case for which YANG is >> considered not suitable. >> >> I say this partly in response to yesterday's meeting, where people from >> other WGs seem to have whole new areas of usage that YANG and Netconf >> weren't designed for specifically, and the answer to the unsuitability >> seems to be to redesign YANG and Netconf to meet their specific needs. >> >> >> -- >> David Harrington >> Ietfdbh@comcast.net >> +1-603-828-1401 >> >> >> >> >> >> On 8/1/13 6:50 PM, "Martin Bjorklund" wrote: >> >>>Hi, >>> >>>I'd just like to comment on Kent's last comment in the session today. >>>He said that Juniper tried to use YANG, but it wasn't suitable, so they >>>had to add all kinds of YANG extensions. >>> >>>First of all, it is important to understand that YANG's extension >>>mechanism is very powerful, but it be disastrous to interoperability >>>if not used carefully. The way to think about an extension is that if >>>a client does not understand the extension, the clienbt should still >>>be able to communicate with the device correctly. For example, adding >>>an extension to make a key in a list optional would break >>>interoperability, but adding an extension that classifies a config >>>false node into operational state and statistics would not. (I am >>>specificially referring to NETCONF interoperability here). >>> >>>(We have one extension that breaks this rule, and I truly regret that >>>we added it - it has caused much more trouble than it solved) >>> >>>Second, it would be interesting to know what you meant when you said >>>that it was not suitable. If you meant that you could not use YANG to >>>describe all your *current* behavior, it is not all surprising >>>(well...). But if you meant that the YANG-defined behavior is >>>completely unacceptable (even if it wasn't for backwards-compatibility >>>with you current behavior), it would be very useful to know what it >>>is. >>> >>> >>>/martin >>>_______________________________________________ >>>netmod mailing list >>>netmod@ietf.org >>>https://www.ietf.org/mailman/listinfo/netmod >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Mon Aug 5 02:24:48 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3222121F9D5F for ; Mon, 5 Aug 2013 02:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.857 X-Spam-Level: X-Spam-Status: No, score=-0.857 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HOST_EQ_CZ=0.904, 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 WTXIrlUccSLK for ; Mon, 5 Aug 2013 02:24:39 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id A63F721F9702 for ; Mon, 5 Aug 2013 02:22:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 392F3540289 for ; Mon, 5 Aug 2013 11:21:24 +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 hp5vnU7sCG9w for ; Mon, 5 Aug 2013 11:21:20 +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 B159254022B for ; Mon, 5 Aug 2013 11:21:20 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <001301ce8fca$6cb09280$6b01a8c0@oemcomputer> References: <20130801.185007.338342419.mbj@tail-f.com> <001301ce8fca$6cb09280$6b01a8c0@oemcomputer> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 05 Aug 2013 11:21:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] YANG extensions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 09:24:48 -0000 Randy Presuhn writes: > Hi - > >> From: "Andy Bierman" >> To: "David Harrington" >> Cc: >> Sent: Friday, August 02, 2013 2:03 PM >> Subject: Re: [netmod] YANG extensions > ... >> NETCONF deals with a single server, so I am not sure why we >> need YANG extensions to replicate configs across a cluster. > > I think you just anwered your own question here. > But I think it's more than just replication across a cluster, > which might potentially be handled by the cluster itself. > > From the perspective of *network* operation, > configuration is not about a single server's configuration, > but rather about a set of communicating systems. > To the extent that NETCONF still doesn't really address > *network* configuration, folks will continue to try to bolt > it on through extensions and ad hoc model work-arounds. > >> I think the "YANG Mount Point" draft is probably a more comprehensive >> solution to complex config distribution across multiple servers. > > Providing a coherent framwork for operating on the set of device-specific > configurations that collectively constitue a network's configuration would > be the next logical step. Unfortunately, I don't see how netconf's > naming architecture woud facilitate such a thing. > >> The biggest complaint I hear from customers about YANG is >> the choice-stmt. There are many situations where deleting >> the old case when a new case is selected is not desirable. >> IMO, the conditional enablement draft offers the best solution >> for maintaining data node states other than "active". > > Analogous to the source-code problem (or non-problem, depending > on how one looks at it) of #ifdef, commented-out, and "dead" code. > >> The notion of using 1 YANG "template" to generate N different variants >> may be beyond the scope of YANG, but also something customers want. > > For a long time configuration data has included scripts and code. > "Conditional enablement" is just a really degenerate case of that. > I think when reasoning about the configuration of a system it's > important to be able to distinguish between the configuration data > and the results of evaluating that configuration data in a particular > system in a particular operating environment at a particular point in time. Right, so it again comes down to the distinction between configuration and state data or, more precisely, to the process of mapping the former to the latter. Lada > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Mon Aug 5 03:03:12 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E9B21F9E6C; Mon, 5 Aug 2013 03:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.936 X-Spam-Level: X-Spam-Status: No, score=-0.936 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HOST_EQ_CZ=0.904, 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 Tm4Zduc-OM3t; Mon, 5 Aug 2013 03:02:45 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id A07CC21F8A53; Mon, 5 Aug 2013 02:58:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id C0236540289; Mon, 5 Aug 2013 11:56:27 +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 CtVBqclMwsUk; Mon, 5 Aug 2013 11:56:21 +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 2894F5401AF; Mon, 5 Aug 2013 11:56:15 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , "Ersue\, Mehmet \(NSN - DE\/Munich\)" In-Reply-To: References: User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: Andy Bierman , "Ersue\, Mehmet \(NSN - DE\/Munich\)" , Netconf , "netmod\@ietf.org" Date: Mon, 05 Aug 2013 11:56:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 10:03:13 -0000 Andy Bierman writes: > On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) > wrote: >> We need to start somewhere to discuss the priorities. So, let's start here. >> >> What would be your proposal for the development plan? >> > > This will take some time to work out, so I will just start with some > design principles > and fill in the details later. > > 1) current functionality that the community agrees is useful MUST NOT be broken > in any way > > 2) current functionality that the community agrees is not useful > SHOULD be removed > > 3) YANG needs to be a multi-protocol DML, but that does not mean written for > unknown protocols. The protocol-independent and protocol-dependent aspects > need to be clearly separated, allowing specific protocol mapping RFCs to be > easily standardized IMO, YANG 2.0 should be protocol-independent, and a light-weight adaptation layer should be defined for each protocol, including NETCONF. Apart form this, there are several other areas that should be considered. One that comes to my mind are XPath extension functions. An interesting question is whether YANG 2.0 could/should also be made independent of the output encoding so that e.g. JSON is directly supported. > > 4) Important module infrastructure such as ACLs and topology need to > be standardized > in an extensible manner, allowing future (currently unknown) > applications to build > on these modules and not start over The priority for the NETMOD group should be to work on vendor-neutral data models that can be used right away or mapped to vendor-specific data models. > > 5) The private candidate datastore is a disaster for multi-client > deployments. A real > transaction mechanism that does not rely on global or even > predictive locking is needed. > Concurrent transactions that do not collide can be processed in parallel. +1, and I'd also add a sound model of configuration, state data and their interaction. Lada > > 6) Protocol performance and scaling properties need to be addressed > > 7) Network-wide applications need to be supported in a way that does not break > existing single-server use cases > > >> Cheers, >> Mehmet > > Andy > >> >>> -----Original Message----- >>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] Behalf Of ext >>> Andy Bierman >>> Sent: Saturday, August 03, 2013 8:42 AM >>> To: netmod@ietf.org; Netconf >>> Subject: [Netconf] development plan >>> >>> Hi, >>> >>> I wold like the NETMOD and NETCONF WGs to establish a >>> development plan and roadmap for the work that will be attempted >>> over the next 1 to 3 years. >>> >>> One draft after another gets presented. >>> Some, like the ACL draft or draft have had almost unanimous >>> support as a problem that needs to be solved. Then quickly forgotten. >>> >>> The complete lack of any development plan discourages people >>> from participating and probably encourages others who are just >>> wasting their time submitting drafts to these WGs. >>> >>> I don't agree with the assertion that NETCONF/YANG will only >>> be useful when it "manages everything" (like the proprietary CLI). >>> It is useful now, but in order to be essential, the community needs >>> to know that it is stable and understand when and how new functionality will >>> be added. >>> >>> >>> >>> Andy >>> _______________________________________________ >>> 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Aug 5 05:24:01 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F138B21F9E94 for ; Mon, 5 Aug 2013 05:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 JE0mwURdR0so for ; Mon, 5 Aug 2013 05:23:57 -0700 (PDT) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id D820D21F9E4F for ; Mon, 5 Aug 2013 05:23:56 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id jt11so3312939pbb.10 for ; Mon, 05 Aug 2013 05:23:56 -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=Sh6wGC0cpGmQ1ucLvvuQTraHb6xXi6SNdJff3lmNTdo=; b=aSPKbECTOaMhYWxy+CdlXaql+9GjabubPdGCTRY1zFnCy2E4pmTFz0GPXPtjLPreEa 7QdZeRPOYSBy7WglYuO0ItKE7Ny9JMpJ+JSkR5zpcMG8Oq7cHGWM7Mf/BLddSxzjy7w2 /jOl8RsOk/xQvpIxzTUaiUnGMv0cZY5cOuznjyTSE/m4IgXnBMjq6HaXgtdH0Tb2uSzQ FcqZ0fUJAg/iNKsQ17rpXRpMJmYyu2bpMe+AaytjI+B0ZdOyf9yZoeHGnG89Dfjh99/q WB37RGopbM9+WFdEFNYgl7uW3yut2wEKcX8rDhAWtdYjeiCNdCoK4tVca2CSie4kFwGP wUwA== MIME-Version: 1.0 X-Received: by 10.68.19.162 with SMTP id g2mr22099254pbe.140.1375705436348; Mon, 05 Aug 2013 05:23:56 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Mon, 5 Aug 2013 05:23:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Aug 2013 05:23:56 -0700 Message-ID: From: Andy Bierman To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf , "netmod@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn5gpHLgeXrf7zg0jqBRG1XrdHNIxu2ndAXkuzlfNX3qTvcWns7WoxgKqTrCFYrjyQpBn+a Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 12:24:01 -0000 On Mon, Aug 5, 2013 at 2:56 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > >> On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) >> wrote: >>> We need to start somewhere to discuss the priorities. So, let's start here. >>> >>> What would be your proposal for the development plan? >>> >> >> This will take some time to work out, so I will just start with some >> design principles >> and fill in the details later. >> >> 1) current functionality that the community agrees is useful MUST NOT be broken >> in any way >> >> 2) current functionality that the community agrees is not useful >> SHOULD be removed >> >> 3) YANG needs to be a multi-protocol DML, but that does not mean written for >> unknown protocols. The protocol-independent and protocol-dependent aspects >> need to be clearly separated, allowing specific protocol mapping RFCs to be >> easily standardized > > IMO, YANG 2.0 should be protocol-independent, and a light-weight adaptation layer should be defined for each protocol, including NETCONF. > > Apart form this, there are several other areas that should be considered. One that comes to my mind are XPath extension functions. > I don't think it is a good time to start a 6020bis RFC and tell the community YANG 1.0 is unstable and being replaced. > An interesting question is whether YANG 2.0 could/should also be made independent of the output encoding so that e.g. JSON is directly supported. > I don't want YANG 2.0. New standard YANG extensions are OK for now. >> >> 4) Important module infrastructure such as ACLs and topology need to >> be standardized >> in an extensible manner, allowing future (currently unknown) >> applications to build >> on these modules and not start over > > The priority for the NETMOD group should be to work on vendor-neutral data models that can be used right away or mapped to vendor-specific data models. > >> >> 5) The private candidate datastore is a disaster for multi-client >> deployments. A real >> transaction mechanism that does not rely on global or even >> predictive locking is needed. >> Concurrent transactions that do not collide can be processed in parallel. > > +1, and I'd also add a sound model of configuration, state data and their interaction. > I think Kent's conditional enablement draft is the foundation for all the corner-case config state and operational CM requirements. We currently have a very simplistic model for the device configuration. The running config is either there or it is deleted and forgotten. IMO this is #1 or 2 priority for the NETCONF WG. > Lada > Andy >> >> 6) Protocol performance and scaling properties need to be addressed >> >> 7) Network-wide applications need to be supported in a way that does not break >> existing single-server use cases >> >> >>> Cheers, >>> Mehmet >> >> Andy >> >>> >>>> -----Original Message----- >>>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] Behalf Of ext >>>> Andy Bierman >>>> Sent: Saturday, August 03, 2013 8:42 AM >>>> To: netmod@ietf.org; Netconf >>>> Subject: [Netconf] development plan >>>> >>>> Hi, >>>> >>>> I wold like the NETMOD and NETCONF WGs to establish a >>>> development plan and roadmap for the work that will be attempted >>>> over the next 1 to 3 years. >>>> >>>> One draft after another gets presented. >>>> Some, like the ACL draft or draft have had almost unanimous >>>> support as a problem that needs to be solved. Then quickly forgotten. >>>> >>>> The complete lack of any development plan discourages people >>>> from participating and probably encourages others who are just >>>> wasting their time submitting drafts to these WGs. >>>> >>>> I don't agree with the assertion that NETCONF/YANG will only >>>> be useful when it "manages everything" (like the proprietary CLI). >>>> It is useful now, but in order to be essential, the community needs >>>> to know that it is stable and understand when and how new functionality will >>>> be added. >>>> >>>> >>>> >>>> Andy >>>> _______________________________________________ >>>> 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 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Aug 5 05:35:38 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FBE21F9EDF for ; Mon, 5 Aug 2013 05:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=0.671, 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 F4bX0fVSfOYg for ; Mon, 5 Aug 2013 05:35:33 -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 089B221F93FB for ; Mon, 5 Aug 2013 05:35:32 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so3201794pab.39 for ; Mon, 05 Aug 2013 05:35:30 -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=NsIXeR5mensLEg+4IXikSgeytvnQGiOZ1nClGvPe6Ks=; b=kVdNo8s1qfsgk1TcPn4jdHPvHv2A11NN5FL8rG08uW2VeEcCgxufG8hGAHMDAfdK5Y 8Kd4oYH12WSkbcItrvt/Qe1lsubG8DOK/1txwbiSxJWF4TIrAqofkG9+5Cq/dKiglpTH KtmF7hPTg2np2YIjsLph4Hv0Vy7vsWiJjqs3vMefkucfGF2nTw01Ln9nXttu0DBha48f 6jSEcpYFKLjx0+9XYnqR6FfJdQnzo9+u7/nimu4tSs1c1OWGhLjn2s2StFkzsxB+1DBm AafKcj/g/2i0AiOFHAbXrWAk+CQeqJABAUy2fPqRTQ/U0dOha/YLy4Y16QmMhsBbU0+4 3fGw== MIME-Version: 1.0 X-Received: by 10.68.189.162 with SMTP id gj2mr14291797pbc.96.1375706130515; Mon, 05 Aug 2013 05:35:30 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Mon, 5 Aug 2013 05:35:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Aug 2013 05:35:30 -0700 Message-ID: From: Andy Bierman To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn051qHvSxUt2aR5CvVhN/KxIf+1+7fErRzbQT3h4nW549smovj8SmsdN5z+vTNvF3yfUnY Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 12:35:38 -0000 On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > We need to start somewhere to discuss the priorities. So, let's start here. > > What would be your proposal for the development plan? > Here is my development plan priorities: NETCONF WG: #1) RESTCONF (was YANG-API) #2) Config state, operational state, conditional enablement (IMO, all these are related problems) #3) Private Candidates (concurrent transactions) NETMOD WG: #1) Finish current base modules (either publish or abandon) #2) Transition to IETF support mode -- help other WGs create YANG modules for NETCONF and RESTCONF. Start with ACLs and topology. Help other WGs like SACM and I2RS use YANG. Coordinate all new work through YANG Doctors. ** Wait 2 years or so before attempting YANG 2.0 > Cheers, > Mehmet Andy From lhotka@nic.cz Mon Aug 5 05:51:11 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E34A21F9DCE; Mon, 5 Aug 2013 05:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[AWL=0.571, 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 m8pdEkljKgRS; Mon, 5 Aug 2013 05:51:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 36EBE21F9EBE; Mon, 5 Aug 2013 05:50:53 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 322FE140146; Mon, 5 Aug 2013 14:50:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375707052; bh=/bOCqjpeD2lRVZkWUUrOmwzzoqDc0q1TFe/0Ig3HR6M=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=sRtd9JkH9/2bhhc0CyPGS9QixQrTdNY9d7vV60VRU86K3+g3fwXhRkYynPiRy0GiA 9cbtYJ526hhVz94VodfXi71lbvJtrDQcNJYMs4YCXps5YzaKEXwNsCu5faF2ASrLYE YCmDPUteT75Gza7rdZCcwLr9C6Xlox1DmFTqWNtQ= 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: Mon, 5 Aug 2013 14:50:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: 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 , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 12:51:11 -0000 On Aug 5, 2013, at 2:23 PM, Andy Bierman wrote: > On Mon, Aug 5, 2013 at 2:56 AM, Ladislav Lhotka wrote: >>>=20 >>> 3) YANG needs to be a multi-protocol DML, but that does not mean = written for >>> unknown protocols. The protocol-independent and = protocol-dependent aspects >>> need to be clearly separated, allowing specific protocol mapping = RFCs to be >>> easily standardized >>=20 >> IMO, YANG 2.0 should be protocol-independent, and a light-weight = adaptation layer should be defined for each protocol, including NETCONF. >>=20 >> Apart form this, there are several other areas that should be = considered. One that comes to my mind are XPath extension functions. >>=20 >=20 > I don't think it is a good time to start a 6020bis RFC and > tell the community YANG 1.0 is unstable and being replaced. I had the impression that my proposal to decouple YANG from NETCONF was = generally supported, and this is impossible to do without changing 6020, = because some important things like XPath context, 'choice' and 'when' = semantics, or even the concept of validity itself, are defined in = NETCONF-specific terms. >=20 >> An interesting question is whether YANG 2.0 could/should also be made = independent of the output encoding so that e.g. JSON is directly = supported. >>=20 >=20 > I don't want YANG 2.0. > New standard YANG extensions are OK for now. I agree with Martin that extensions should be restricted in scope, so = one can do only as much with them. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Aug 5 06:31:19 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3945421F9DE1 for ; Mon, 5 Aug 2013 06:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=0.119, 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 TaK9YrG9F9sY for ; Mon, 5 Aug 2013 06:31:14 -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 EC22F21F9E04 for ; Mon, 5 Aug 2013 06:31:13 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id q10so3236617pdj.21 for ; Mon, 05 Aug 2013 06:31:13 -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=7akRSAK27tFG6ve+m/kCAOtTxnZF2lptI7IVw2IoRWw=; b=hnhHVrH/nvyUwfN2vPPocdFhN2N4O+7mFnC+Gh0Pg3R+lWSSlkMTataFQd6bvuMlsp bk2fpmDhHzcXvzNCAERtHOpD0HKsPNMccqvr4bBoDvbL/scRfX0ynGGf8/8EvkZ8FLzL DbWdrg3FY2LZ/wdzU+43Ld9Vn5da/eIT1ERE+GT6aeWCeNc09TyDu5+EL5a2N2zuQPu0 usZkmJ8LoN7+jNTKCngb4eatBeM9WRfsCswpqnScP1CDRWAr3AJtRv2p8UYBjzhHc/e3 Bt7ct1xqitnuu4TYq7ADNHpU/GGsV0furiShbXkOnLwvHqzwQz+e/sw1w47g46Chgq+q R2PA== MIME-Version: 1.0 X-Received: by 10.68.19.162 with SMTP id g2mr22415301pbe.140.1375709472928; Mon, 05 Aug 2013 06:31:12 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Mon, 5 Aug 2013 06:31:12 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Aug 2013 06:31:12 -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: ALoCoQmWJ8R5hiRG7A7nPnFyUvWCbb2B2GFgrqp2dRfhTOWDjTjuhKfniwte5WDIZ0/PdlLusn4m Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 13:31:19 -0000 On Mon, Aug 5, 2013 at 5:50 AM, Ladislav Lhotka wrote: > > On Aug 5, 2013, at 2:23 PM, Andy Bierman wrote: > >> On Mon, Aug 5, 2013 at 2:56 AM, Ladislav Lhotka wrote: >>>> >>>> 3) YANG needs to be a multi-protocol DML, but that does not mean writt= en for >>>> unknown protocols. The protocol-independent and protocol-dependent= aspects >>>> need to be clearly separated, allowing specific protocol mapping RF= Cs to be >>>> easily standardized >>> >>> IMO, YANG 2.0 should be protocol-independent, and a light-weight adapta= tion layer should be defined for each protocol, including NETCONF. >>> >>> Apart form this, there are several other areas that should be considere= d. One that comes to my mind are XPath extension functions. >>> >> >> I don't think it is a good time to start a 6020bis RFC and >> tell the community YANG 1.0 is unstable and being replaced. > > > I had the impression that my proposal to decouple YANG from NETCONF was g= enerally supported, and this is impossible to do without changing 6020, bec= ause some important things like XPath context, 'choice' and 'when' semantic= s, or even the concept of validity itself, are defined in NETCONF-specific = terms. > I agree with Dave Harrington's concerns expressed at the NETMOD WG meeting. Introducing a new language version is a serious and drastic step that shoul= d be done very carefully. IMO we do not have enough operational experience with YANG to do a good job at YANG 2.0. >> >>> An interesting question is whether YANG 2.0 could/should also be made i= ndependent of the output encoding so that e.g. JSON is directly supported. >>> >> >> I don't want YANG 2.0. >> New standard YANG extensions are OK for now. > > I agree with Martin that extensions should be restricted in scope, so one= can do only as much with them. > Yes -- we should specify what best practices are YANG extensions. An update to the the YANG Usage Guidelines would probably be a good idea. Consensus on best practice has changed and the guidelines are no longer 100% current. > Lada Andy From lhotka@nic.cz Mon Aug 5 07:03:58 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D8B21F9D7E; Mon, 5 Aug 2013 07:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.542 X-Spam-Level: X-Spam-Status: No, score=-1.542 tagged_above=-999 required=5 tests=[AWL=0.457, 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 zSB8Rc7-Ot0j; Mon, 5 Aug 2013 07:03:57 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CD5CC21F9D70; Mon, 5 Aug 2013 07:03:56 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A32A0140166; Mon, 5 Aug 2013 16:03:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375711435; bh=of1ZkrDhfJPt8C7A9Al/PMMXA1h/f314WZKMfs71RC8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XRIogjYdwXb2Riz5SKCNtfFyaD8ALfnQlsPsNck8JXlwb4k0etpQXAAWwCwqjI9nh yJicIifi7I/nxIChwSyYxqjQuWTHrsTHPhv+rDSMEo2DxsWRmo+P0oqa7APKKqk85m fgR4hiz6Vg7+LlIEAM/CsNTnLNoWr+P78oqF3DnU= 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: Mon, 5 Aug 2013 16:03:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> References: 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 , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 14:03:58 -0000 On Aug 5, 2013, at 3:31 PM, Andy Bierman wrote: > On Mon, Aug 5, 2013 at 5:50 AM, Ladislav Lhotka wrote: >>=20 >> On Aug 5, 2013, at 2:23 PM, Andy Bierman wrote: >>=20 >>> On Mon, Aug 5, 2013 at 2:56 AM, Ladislav Lhotka = wrote: >>>>>=20 >>>>> 3) YANG needs to be a multi-protocol DML, but that does not mean = written for >>>>> unknown protocols. The protocol-independent and = protocol-dependent aspects >>>>> need to be clearly separated, allowing specific protocol mapping = RFCs to be >>>>> easily standardized >>>>=20 >>>> IMO, YANG 2.0 should be protocol-independent, and a light-weight = adaptation layer should be defined for each protocol, including NETCONF. >>>>=20 >>>> Apart form this, there are several other areas that should be = considered. One that comes to my mind are XPath extension functions. >>>>=20 >>>=20 >>> I don't think it is a good time to start a 6020bis RFC and >>> tell the community YANG 1.0 is unstable and being replaced. >>=20 >>=20 >> I had the impression that my proposal to decouple YANG from NETCONF = was generally supported, and this is impossible to do without changing = 6020, because some important things like XPath context, 'choice' and = 'when' semantics, or even the concept of validity itself, are defined in = NETCONF-specific terms. >>=20 >=20 > I agree with Dave Harrington's concerns expressed at the NETMOD WG = meeting. > Introducing a new language version is a serious and drastic step that = should > be done very carefully. IMO we do not have enough operational = experience > with YANG to do a good job at YANG 2.0. It is a fact of life that YANG is being used outside NETCONF, and there = are more plans for doing do, but with 6020 it is a slippery slope. For = example, such non-NETCONF applications of YANG will most likely want to = use "must" for expressing semantic constraints. However, the accessible = tree for "must" is defined like so: o If the context node represents configuration, the tree is the data in the NETCONF datastore where the context node exists. The XPath root node has all top-level configuration data nodes in all modules as children. o If the context node represents state data, the tree is all state data on the device, and the datastore. The XPath root node has all top-level data nodes in all modules as children. ... This cannot be unambiguously interpreted in a non-NETCONF context, so it = is effectively undefined, which is rather dangerous. So I don't mean to completely redesign YANG, but we cannot, on the other = hand, enable non-NETCONF YANG data modelling without providing new = definitions. Lada =20 >=20 >=20 >=20 >>>=20 >>>> An interesting question is whether YANG 2.0 could/should also be = made independent of the output encoding so that e.g. JSON is directly = supported. >>>>=20 >>>=20 >>> I don't want YANG 2.0. >>> New standard YANG extensions are OK for now. >>=20 >> I agree with Martin that extensions should be restricted in scope, so = one can do only as much with them. >>=20 >=20 > Yes -- we should specify what best practices are YANG extensions. > An update to the the YANG Usage Guidelines would probably be > a good idea. Consensus on best practice has changed and the > guidelines are no longer 100% current. >=20 >=20 >> Lada >=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From kwatsen@juniper.net Mon Aug 5 07:11:22 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A47C21F9E5B; Mon, 5 Aug 2013 07:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 XihT4mX6Kz2x; Mon, 5 Aug 2013 07:11:15 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE2321F9AEF; Mon, 5 Aug 2013 07:11:15 -0700 (PDT) Received: from mail181-ch1-R.bigfish.com (10.43.68.230) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 Aug 2013 14:11:14 +0000 Received: from mail181-ch1 (localhost [127.0.0.1]) by mail181-ch1-R.bigfish.com (Postfix) with ESMTP id 75C36220127; Mon, 5 Aug 2013 14:11:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I1432Id799h4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail181-ch1: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=kwatsen@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail181-ch1 (localhost.localdomain [127.0.0.1]) by mail181-ch1 (MessageSwitch) id 1375711871930929_9870; Mon, 5 Aug 2013 14:11:11 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail181-ch1.bigfish.com (Postfix) with ESMTP id D653C26004C; Mon, 5 Aug 2013 14:11:11 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.53) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 Aug 2013 14:11:11 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 5 Aug 2013 07:11:09 -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; Mon, 5 Aug 2013 07:11:09 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.204) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 5 Aug 2013 07:25:02 -0700 Received: from mail60-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE026.bigfish.com (10.3.207.148) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 Aug 2013 14:11:06 +0000 Received: from mail60-am1 (localhost [127.0.0.1]) by mail60-am1-R.bigfish.com (Postfix) with ESMTP id BE78D2403CA; Mon, 5 Aug 2013 14:11:06 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(479174003)(189002)(377454003)(164054003)(51704005)(199002)(54356001)(79102001)(80976001)(19580405001)(36756003)(83322001)(53806001)(19580395003)(561944002)(74366001)(77096001)(16406001)(56816003)(76176001)(63696002)(76796001)(76786001)(59766001)(56776001)(54316002)(77982001)(76482001)(80022001)(4396001)(49866001)(47736001)(551934002)(69226001)(74706001)(74876001)(74662001)(74502001)(47446002)(50986001)(47976001)(31966008)(65816001)(81342001)(51856001)(83072001)(46102001)(81542001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB125; H:BY2PR05MB125.namprd05.prod.outlook.com; CLIP:10.255.159.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail60-am1 (localhost.localdomain [127.0.0.1]) by mail60-am1 (MessageSwitch) id 1375711829516294_4454; Mon, 5 Aug 2013 14:10:29 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.226]) by mail60-am1.bigfish.com (Postfix) with ESMTP id 741262C0046; Mon, 5 Aug 2013 14:10:29 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 Aug 2013 14:10:28 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Mon, 5 Aug 2013 14:10:26 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) by BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) with Microsoft SMTP Server (TLS) id 15.0.731.16; Mon, 5 Aug 2013 14:10:24 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.143]) by BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.13]) with mapi id 15.00.0731.000; Mon, 5 Aug 2013 14:10:24 +0000 From: Kent Watsen To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" Thread-Topic: [Netconf] development plan Thread-Index: AQHOkCeotjTq6+Hl9Eyu6aC6FvZ1HZmGkDsA///XcAA= Date: Mon, 5 Aug 2013 14:10:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.255.159.4] x-forefront-prvs: 0929F1BAED Content-Type: text/plain; charset="us-ascii" Content-ID: <17BFFED8E52AB9419482F256645DFAC1@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%IETF.ORG$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%NSN.COM$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 , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 14:11:22 -0000 My short list: NETCONF WG: =20 (essentially Andy's list with a couple items I'm already into on top) #1) Reverse SSH #2) Zero Conf #3) RESTCONF #4) Config state, operational state, conditional enablement #5) Private Candidates (concurrent transactions) NETMOD WG: #1) Extend as needed to minimize number of proprietary Juniper YANG modules #2) Modules for basic EMS support (hardware, software, licenses, etc.) #3) Data Model Transformation Engine Thanks, Kent On 8/5/13 8:35 AM, "Andy Bierman" wrote: >On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) > wrote: >> We need to start somewhere to discuss the priorities. So, let's start >>here. >> >> What would be your proposal for the development plan? >> > >Here is my development plan priorities: > >NETCONF WG: > > #1) RESTCONF (was YANG-API) > #2) Config state, operational state, conditional enablement > (IMO, all these are related problems) > #3) Private Candidates (concurrent transactions) > >NETMOD WG: > > #1) Finish current base modules (either publish or abandon) > #2) Transition to IETF support mode -- help other WGs > create YANG modules for NETCONF and RESTCONF. > Start with ACLs and topology. Help other WGs like SACM > and I2RS use YANG. Coordinate all new work > through YANG Doctors. > ** Wait 2 years or so before attempting YANG 2.0 > > >> Cheers, >> Mehmet > >Andy >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf > > From andy@yumaworks.com Mon Aug 5 07:22:59 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B447A21F9F34 for ; Mon, 5 Aug 2013 07:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.593, 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 IDAHq+a725xI for ; Mon, 5 Aug 2013 07:22:53 -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 BC97A21F9F08 for ; Mon, 5 Aug 2013 07:22:45 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so3309511pab.39 for ; Mon, 05 Aug 2013 07:22:40 -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=s+fXEg6H3quLEfen8pMpuvqx275o6wHRfZpqpG98YlI=; b=JA7J0YPe/hwZdxztuFkSsGR1JItIrKo3XaxtnNmjr9XTHvwGLFxMoO0jpazSaJDPZt K9NzU0xRo0XFVa1fqA0Nd1W+Dy5xGNIEghvkXuPVfE1M0B4CReEzki8SltG8JnBMr4Yg YYlaffz+pyghqwk2uxaBJtUYOkXcl9dQ/HIs5v+y+5sgAsqMG8eP7X9GrHLxqLcKQ1xu PxD0bpBktkspEu3E1SjPFbuxHzF7dOzo778MlkN4cou/TJemofK1dN6Bbx9Zy1tB+uMV ud8KXKL2d6zKu2ky8f8n5jg5BMe2GBvBBK2mPQ/Yw369WcLO8++t8Ic5M44WN7jSlWPT kSJw== MIME-Version: 1.0 X-Received: by 10.66.232.101 with SMTP id tn5mr25486244pac.132.1375712560180; Mon, 05 Aug 2013 07:22:40 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Mon, 5 Aug 2013 07:22:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Aug 2013 07:22:40 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnV3EWSghmscGwsMDA1Kq72IPh3sGmld/xQoZy6cwNyAaASR68PoV1XrXn4RwqBYXVFKasM Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 14:22:59 -0000 Hi, I omitted NETCONF stuff that is currently chartered. I agree Reverse SSH and TLS-bis are #1 for NETCONF. Zeroconf came out of left field. What does that mean in the context of these 2 WGs? Andy On Mon, Aug 5, 2013 at 7:10 AM, Kent Watsen wrote: > > My short list: > > NETCONF WG: > > (essentially Andy's list with a couple items I'm already into on top) > > #1) Reverse SSH > #2) Zero Conf > #3) RESTCONF > #4) Config state, operational state, conditional enablement > #5) Private Candidates (concurrent transactions) > > > NETMOD WG: > > #1) Extend as needed to minimize number of proprietary Juniper YANG > modules > > #2) Modules for basic EMS support (hardware, software, licenses, etc.) > #3) Data Model Transformation Engine > > > > Thanks, > Kent > > > On 8/5/13 8:35 AM, "Andy Bierman" wrote: > >>On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) >> wrote: >>> We need to start somewhere to discuss the priorities. So, let's start >>>here. >>> >>> What would be your proposal for the development plan? >>> >> >>Here is my development plan priorities: >> >>NETCONF WG: >> >> #1) RESTCONF (was YANG-API) >> #2) Config state, operational state, conditional enablement >> (IMO, all these are related problems) >> #3) Private Candidates (concurrent transactions) >> >>NETMOD WG: >> >> #1) Finish current base modules (either publish or abandon) >> #2) Transition to IETF support mode -- help other WGs >> create YANG modules for NETCONF and RESTCONF. >> Start with ACLs and topology. Help other WGs like SACM >> and I2RS use YANG. Coordinate all new work >> through YANG Doctors. >> ** Wait 2 years or so before attempting YANG 2.0 >> >> >>> Cheers, >>> Mehmet >> >>Andy >>_______________________________________________ >>Netconf mailing list >>Netconf@ietf.org >>https://www.ietf.org/mailman/listinfo/netconf >> >> > > > From kwatsen@juniper.net Mon Aug 5 08:29:14 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCE321E804B; Mon, 5 Aug 2013 08:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.967 X-Spam-Level: X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 nBkri8pyL-6z; Mon, 5 Aug 2013 08:29:09 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id AD96D11E8131; Mon, 5 Aug 2013 08:29:08 -0700 (PDT) Received: from mail122-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 Aug 2013 15:29:07 +0000 Received: from mail122-ch1 (localhost [127.0.0.1]) by mail122-ch1-R.bigfish.com (Postfix) with ESMTP id 2997D140267; Mon, 5 Aug 2013 15:29:07 +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: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I1432Id799h4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail122-ch1: 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.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail122-ch1 (localhost.localdomain [127.0.0.1]) by mail122-ch1 (MessageSwitch) id 1375716544906042_23254; Mon, 5 Aug 2013 15:29:04 +0000 (UTC) Received: from CH1EHSMHS023.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail122-ch1.bigfish.com (Postfix) with ESMTP id D86564E0047; Mon, 5 Aug 2013 15:29:04 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.52) by CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 Aug 2013 15:29:04 +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; Mon, 5 Aug 2013 08:29:03 -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; Mon, 5 Aug 2013 08:29:03 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.188) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 5 Aug 2013 08:42:57 -0700 Received: from mail20-co1-R.bigfish.com (10.243.78.244) by CO1EHSOBE026.bigfish.com (10.243.66.89) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 Aug 2013 15:29:02 +0000 Received: from mail20-co1 (localhost [127.0.0.1]) by mail20-co1-R.bigfish.com (Postfix) with ESMTP id 65101400A3; Mon, 5 Aug 2013 15:29:02 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(479174003)(164054003)(377454003)(51704005)(199002)(189002)(77982001)(59766001)(63696002)(76796001)(76786001)(36756003)(76176001)(46102001)(56816003)(77096001)(79102001)(4396001)(69226001)(51856001)(561944002)(54316002)(74876001)(83322001)(19580395003)(19580405001)(76482001)(56776001)(83072001)(54356001)(74366001)(81542001)(74706001)(551934002)(81342001)(53806001)(65816001)(74662001)(16406001)(47976001)(49866001)(31966008)(74502001)(80022001)(47446002)(50986001)(80976001)(47736001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB126; H:BY2PR05MB125.namprd05.prod.outlook.com; CLIP:10.255.159.4; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail20-co1 (localhost.localdomain [127.0.0.1]) by mail20-co1 (MessageSwitch) id 1375716540502001_23515; Mon, 5 Aug 2013 15:29:00 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.250]) by mail20-co1.bigfish.com (Postfix) with ESMTP id 764728C004A; Mon, 5 Aug 2013 15:29:00 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 Aug 2013 15:28:59 +0000 Received: from BY2PR05MB126.namprd05.prod.outlook.com (10.242.38.22) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Mon, 5 Aug 2013 15:28:58 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) by BY2PR05MB126.namprd05.prod.outlook.com (10.242.38.22) with Microsoft SMTP Server (TLS) id 15.0.731.16; Mon, 5 Aug 2013 15:28:55 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.143]) by BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.13]) with mapi id 15.00.0731.000; Mon, 5 Aug 2013 15:28:55 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] development plan Thread-Index: AQHOkCeotjTq6+Hl9Eyu6aC6FvZ1HZmGkDsA///XcACAAEaBAP//z2+A Date: Mon, 5 Aug 2013 15:28:54 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.255.159.4] x-forefront-prvs: 0929F1BAED Content-Type: text/plain; charset="us-ascii" Content-ID: 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%IETF.ORG$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%NSN.COM$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 , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 15:29:14 -0000 >From the WG summary Mehmet sent out: "...and Zero-configuration. The latter has been seen as essentially important and should be done in a separate draft. Steve Hanna volunteered to work on this together with Kent. Manual configuration will be done in the Reverse SSH draft." My understanding was that there was interest in doing ZeroConf (for both SSH and TLS), especially now that we have the Security experts attention. I think the chairs were going to check if the current charter covers it or not... K. On 8/5/13 10:22 AM, "Andy Bierman" wrote: >Hi, > >I omitted NETCONF stuff that is currently chartered. >I agree Reverse SSH and TLS-bis are #1 for NETCONF. >Zeroconf came out of left field. What does >that mean in the context of these 2 WGs? > >Andy > > >On Mon, Aug 5, 2013 at 7:10 AM, Kent Watsen wrote: >> >> My short list: >> >> NETCONF WG: >> >> (essentially Andy's list with a couple items I'm already into on top) >> >> #1) Reverse SSH >> #2) Zero Conf >> #3) RESTCONF >> #4) Config state, operational state, conditional enablement >> #5) Private Candidates (concurrent transactions) >> >> >> NETMOD WG: >> >> #1) Extend as needed to minimize number of proprietary Juniper YANG >> modules >> >> #2) Modules for basic EMS support (hardware, software, licenses, etc.) >> #3) Data Model Transformation Engine >> >> >> >> Thanks, >> Kent >> >> >> On 8/5/13 8:35 AM, "Andy Bierman" wrote: >> >>>On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) >>> wrote: >>>> We need to start somewhere to discuss the priorities. So, let's start >>>>here. >>>> >>>> What would be your proposal for the development plan? >>>> >>> >>>Here is my development plan priorities: >>> >>>NETCONF WG: >>> >>> #1) RESTCONF (was YANG-API) >>> #2) Config state, operational state, conditional enablement >>> (IMO, all these are related problems) >>> #3) Private Candidates (concurrent transactions) >>> >>>NETMOD WG: >>> >>> #1) Finish current base modules (either publish or abandon) >>> #2) Transition to IETF support mode -- help other WGs >>> create YANG modules for NETCONF and RESTCONF. >>> Start with ACLs and topology. Help other WGs like SACM >>> and I2RS use YANG. Coordinate all new work >>> through YANG Doctors. >>> ** Wait 2 years or so before attempting YANG 2.0 >>> >>> >>>> Cheers, >>>> Mehmet >>> >>>Andy >>>_______________________________________________ >>>Netconf mailing list >>>Netconf@ietf.org >>>https://www.ietf.org/mailman/listinfo/netconf >>> >>> >> >> >> > > From balazs.lengyel@ericsson.com Mon Aug 5 08:50:03 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC1521F9971; Mon, 5 Aug 2013 08:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=-0.889, 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 Ta+XmhBSYT5T; Mon, 5 Aug 2013 08:49:56 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 22BCD21F93C4; Mon, 5 Aug 2013 08:49:55 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-8a-51ffc9a29fd2 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 61.9E.11907.2A9CFF15; Mon, 5 Aug 2013 17:49:55 +0200 (CEST) Received: from [159.107.197.207] (153.88.183.18) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.2.328.9; Mon, 5 Aug 2013 17:49:54 +0200 Message-ID: <51FFC9A1.7050207@ericsson.com> Date: Mon, 5 Aug 2013 17:49:53 +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: Ladislav Lhotka References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> In-Reply-To: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+Jvre7ik/8DDT6dYLF4cGQWu8WFVXPZ LKZuus1qMf9iI6sDi8eSJT+ZPDZdvsPo0dJ/kSWAOYrLJiU1J7MstUjfLoEr48nyqoIzfBVr f15mbWBcw93FyMkhIWAicW/xcjYIW0ziwr31QDYXh5DAUUaJOQfOMkE4qxkl7u//zQRSxSug LfFm5wlWEJtFQEVi/cmzLCA2m4CRxNT+82C2qECURGvvVGaIekGJkzOfgMVFBJQlLk74CWYz C2RIbNsyC6xGWMBA4s6rA+wQy64yS/xq/AF2EqeAlcTcBYcYIRpsJS7MuQ7VLC+x/e0csGYh AQ2Jhxf+sk5gFJyFZN8sJC2zkLQsYGRexchRnFqclJtuZLCJERi0B7f8ttjBePmvzSFGaQ4W JXHeLXpnAoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwOjz8ZnblEVvch+fXJc4kh0SdCOH8 Fu/g8mPPtv1nXlxOOx991y00a95rFalbzL3npyz9OmveIkuG58KnXWSclrUdjo7ck7nBZJ8V +9tNdz4qVb99IJK9TfbZ6+tn7FiO6L5r+lITmZj9RK7iyJEoR5OmimpXvYsv8pXv5hxY8THA yHGSL1fLHSWW4oxEQy3mouJEACHJQI8oAgAA Cc: "netmod@ietf.org" , Netconf Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 15:50:03 -0000 On 2013-08-05 16:03, Ladislav Lhotka wrote: > It is a fact of life that YANG is being used outside NETCONF, and there are more plans for doing do, but with 6020 it is a slippery slope. For example, such non-NETCONF applications of YANG will most likely want to use "must" for expressing semantic constraints. However, the accessible tree for "must" is defined like so: > > o If the context node represents configuration, the tree is the data > in the NETCONF datastore where the context node exists. The XPath > root node has all top-level configuration data nodes in all > modules as children. > > o If the context node represents state data, the tree is all state > data on the device, and the datastore. The XPath root > node has all top-level data nodes in all modules as children. > > This cannot be unambiguously interpreted in a non-NETCONF context, so it is effectively undefined, which is rather dangerous. > So I don't mean to completely redesign YANG, but we cannot, on the other hand, enable non-NETCONF YANG data modelling without providing new definitions. > > Lada In my view Netconf contains the "pure" protocol (encoding, operations, transactional behavior...) and background plumbing (datastores, separation of state and config data, hierarchical data organisation, filtering, connection requirements, session concept, capability negotiation, many of the capabilites, error messages). The background plumbing is valid for all access methods (CLI, Netconf, YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be redefined. 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 andy@yumaworks.com Mon Aug 5 09:53:58 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E9C21E80DB for ; Mon, 5 Aug 2013 09:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.553, 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 5EGwfvWZFTNs for ; Mon, 5 Aug 2013 09:53:54 -0700 (PDT) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id 625991F0D52 for ; Mon, 5 Aug 2013 09:53:54 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr4so3576854pbb.6 for ; Mon, 05 Aug 2013 09:53:54 -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=MZLqxqyCIXi0G8KtGxc/EGP3pQdpSiq/uy8DxUiIEYc=; b=U3oXv+m99thnDJWmIQYQDtN4twpQWrI3V080K80vHJK7PVCxoRsWkooK3cjwCP28BM nEBR5/xD96JsjQTKWJg6+Kfxl65OmfaF8PI9BMml3Sn/oX+NqUWtGaAw1Hg1zh2Wv8oF jD/6fvfOAepsshnM9YAS5Tt27luVEsP0WLJ/hWK962Qf51eeROVnjAvNIv+7m9mI1q6C d6bKoh2TyxLcESN+bkpwFzczMG8TW6cXh8S8a8XWZYL/09mEAP0qsMRjmy3XDWAHsLQl IKgzdSwZVljko5wlGe57kgzWHey8qy4tnZW//dIqq13QItAFLMSkJmpUYH7cCWP5wPE5 paJQ== MIME-Version: 1.0 X-Received: by 10.68.60.132 with SMTP id h4mr23337570pbr.177.1375721633771; Mon, 05 Aug 2013 09:53:53 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Mon, 5 Aug 2013 09:53:53 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Aug 2013 09:53:53 -0700 Message-ID: From: Andy Bierman To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl9Yz3EK1lQzQSOQD0RnDkqb9F09S2lgUj6XjKElbtRX1+cWVZY/jtct1eEZkOkwMPOgkey Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 16:53:58 -0000 ... > #1) RESTCONF (was YANG-API) This item also includes a complete protocol encoding for JSON (in addition to XML). Lada's JSON draft is required for this item. http://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-json/ > Andy Andy From yihuan@cisco.com Mon Aug 5 10:20:48 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D887321F9FF6; Mon, 5 Aug 2013 10:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 Va4LKYNQPfKp; Mon, 5 Aug 2013 10:20:44 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D7C3421F9FED; Mon, 5 Aug 2013 10:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1396; q=dns/txt; s=iport; t=1375723242; x=1376932842; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=pxlYUN0mzWF/JbSXbrqXEEpOFLlZuqprykF5QeJugWM=; b=JCz9a/xmMrngSe9RbicLklqGT9iPjQRPzxLiSjLRYlCN3LPI/K38UYPQ SReWmZR1caoBYFl18UmjXS/Kb2omK8vTQHXBDbT6tFNFSA1fVDaN3wK5M F8wkkCm+g7ZKTvG66lp1F/L9hLjtACh+/2eU5U3Y0s9+spvUambHCQmur E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FANfd/1GtJXG//2dsb2JhbABbgwY1UL51gSEWdIImAQQBAQE3NB0BCCIUNwslAgQBEggMh3wMtSkEjluBDTiDGXQDlAmVJoMXgWhC X-IronPort-AV: E=Sophos;i="4.89,819,1367971200"; d="scan'208";a="243468785" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 05 Aug 2013 17:20:41 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r75HKf6m023131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Aug 2013 17:20:41 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 12:20:41 -0500 From: "Lisa Huang (yihuan)" To: Andy Bierman , "netmod@ietf.org" , Netconf Thread-Topic: [netmod] development plan Thread-Index: AQHOkBSpf9/ypW85fkCMYLfhDIaFdZmGvoQA Date: Mon, 5 Aug 2013 17:20:39 +0000 Message-ID: <559E176269AD64429F1582D4EB94F86FE8FD4F@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.167.216] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:20:49 -0000 Hi, I echo what Andy said below. When I invited people from other WGs, like BGP etc, to join netmod session, they were disappointed when they found that the WG has only a limited models and were still discussing basic models. Encouraging more model submission is very important and should be part of development plan. Thanks, Lisa On 8/2/13 11:41 PM, "Andy Bierman" wrote: >Hi, > >I wold like the NETMOD and NETCONF WGs to establish a >development plan and roadmap for the work that will be attempted >over the next 1 to 3 years. > >One draft after another gets presented. >Some, like the ACL draft or draft have had almost unanimous >support as a problem that needs to be solved. Then quickly forgotten. > >The complete lack of any development plan discourages people >from participating and probably encourages others who are just >wasting their time submitting drafts to these WGs. > >I don't agree with the assertion that NETCONF/YANG will only >be useful when it "manages everything" (like the proprietary CLI). >It is useful now, but in order to be essential, the community needs >to know that it is stable and understand when and how new functionality >will >be added. > > > >Andy >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Mon Aug 5 10:45:56 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C13721F9D0A; Mon, 5 Aug 2013 10:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.381, 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 jqbqbdrflRaB; Mon, 5 Aug 2013 10:45:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD7B21F9CBF; Mon, 5 Aug 2013 10:45:55 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 28E27140145; Mon, 5 Aug 2013 19:45:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375724754; bh=j7k9gRIi/Diyc6gLuKQdHLu3mkJ8jv+5oGdcaNZmAd8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DPFEpKvwsgg0cZwVjLkIObk8uiTVI6fFSrTRUAMcxLu/sXEHIM53NFXx0ScupdeiG V6+I//4tsfYjDlY+q4HYW/F4iqrQuYNITH3ONisgMpSBf+qrZFZamEr2upE973a3rm LAYpZdRiBHFg23RUh4VpHwSb5VuZq0OyxtKqaBOI= 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: <51FFC9A1.7050207@ericsson.com> Date: Mon, 5 Aug 2013 19:45:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" , Netconf Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:45:56 -0000 On Aug 5, 2013, at 5:49 PM, Balazs Lengyel = wrote: >=20 > On 2013-08-05 16:03, Ladislav Lhotka wrote: >> It is a fact of life that YANG is being used outside NETCONF, and = there are more plans for doing do, but with 6020 it is a slippery slope. = For example, such non-NETCONF applications of YANG will most likely want = to use "must" for expressing semantic constraints. However, the = accessible tree for "must" is defined like so: >>=20 >> o If the context node represents configuration, the tree is the = data >> in the NETCONF datastore where the context node exists. The = XPath >> root node has all top-level configuration data nodes in all >> modules as children. >>=20 >> o If the context node represents state data, the tree is all = state >> data on the device, and the datastore. The XPath = root >> node has all top-level data nodes in all modules as children. >>=20 >> This cannot be unambiguously interpreted in a non-NETCONF context, so = it is effectively undefined, which is rather dangerous. >> So I don't mean to completely redesign YANG, but we cannot, on the = other hand, enable non-NETCONF YANG data modelling without providing new = definitions. >>=20 >> Lada > In my view Netconf contains the "pure" protocol (encoding, operations, = transactional behavior...) and background plumbing (datastores, = separation of state and config data, hierarchical data organisation, = filtering, connection requirements, session concept, capability = negotiation, many of the capabilites, error messages). > The background plumbing is valid for all access methods (CLI, Netconf, = YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be = redefined. I don't think this is true. I2RS will probably have no distinction = between config and state data, though they may have read-write and = read-only. Sessions and capability negotiation are by no means necessary = (RESTCONF doesn't have it). I can actually imagine data modelling = without any specific protocol for data exchange. Lada > regards Balazs >=20 > --=20 > 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 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Aug 5 10:50:44 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD78921F9B52; Mon, 5 Aug 2013 10:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.241 X-Spam-Level: X-Spam-Status: No, score=-103.241 tagged_above=-999 required=5 tests=[AWL=0.008, 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 GS2hD0qew5ay; Mon, 5 Aug 2013 10:50:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9008521F9AEF; Mon, 5 Aug 2013 10:50:39 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F30C420BF1; Mon, 5 Aug 2013 19:50:38 +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 rklmBwEsLAeH; Mon, 5 Aug 2013 19:50:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96A1B20BDE; Mon, 5 Aug 2013 19:50:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 16E5F27B8254; Mon, 5 Aug 2013 19:50:33 +0200 (CEST) Date: Mon, 5 Aug 2013 19:50:33 +0200 From: Juergen Schoenwaelder To: "Lisa Huang (yihuan)" Message-ID: <20130805175033.GB897@elstar.local> Mail-Followup-To: "Lisa Huang (yihuan)" , Andy Bierman , "netmod@ietf.org" , Netconf References: <559E176269AD64429F1582D4EB94F86FE8FD4F@xmb-aln-x03.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <559E176269AD64429F1582D4EB94F86FE8FD4F@xmb-aln-x03.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" , Netconf Subject: Re: [netmod] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:50:45 -0000 On Mon, Aug 05, 2013 at 05:20:39PM +0000, Lisa Huang (yihuan) wrote: > Hi, > > I echo what Andy said below. When I invited people from other WGs, like > BGP etc, to join netmod session, they were disappointed when they found > that the WG has only a limited models and were still discussing basic > models. Encouraging more model submission is very important and should be > part of development plan. > Reviews help to finish up things faster. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Aug 5 10:53:04 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765B821F9CC5; Mon, 5 Aug 2013 10:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.241 X-Spam-Level: X-Spam-Status: No, score=-103.241 tagged_above=-999 required=5 tests=[AWL=0.008, 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 KaRH1kNdxlOM; Mon, 5 Aug 2013 10:52:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AB34121F9C22; Mon, 5 Aug 2013 10:52:50 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A86620BF5; Mon, 5 Aug 2013 19:52:49 +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 jU0Ojt-dhVcg; Mon, 5 Aug 2013 19:52:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E584220BF1; Mon, 5 Aug 2013 19:52:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 39D4F27B82A1; Mon, 5 Aug 2013 19:52:45 +0200 (CEST) Date: Mon, 5 Aug 2013 19:52:45 +0200 From: Juergen Schoenwaelder To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf , "netmod@ietf.org" Message-ID: <20130805175245.GC897@elstar.local> Mail-Followup-To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf , "netmod@ietf.org" 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) Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:53:05 -0000 On Mon, Aug 05, 2013 at 11:56:14AM +0200, Ladislav Lhotka wrote: > > IMO, YANG 2.0 should be protocol-independent, and a light-weight adaptation layer should be defined for each protocol, including NETCONF. > Someone needs to define 'protocol-independent'. If you want to make YANG fully protocol-independent, then you will likely not finish and create just another example of the 2nd systems effect [1]. /js [1] http://en.wikipedia.org/wiki/Second-system_effect -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Aug 5 10:54:04 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFC721F8F3C; Mon, 5 Aug 2013 10:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.241 X-Spam-Level: X-Spam-Status: No, score=-103.241 tagged_above=-999 required=5 tests=[AWL=0.008, 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 8h5H8k5vkOZ5; Mon, 5 Aug 2013 10:53:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5D221F9B4B; Mon, 5 Aug 2013 10:53:45 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A265720BF5; Mon, 5 Aug 2013 19:53:44 +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 BkDtQsa_eNpf; Mon, 5 Aug 2013 19:53:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C4BD20BF1; Mon, 5 Aug 2013 19:53:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8BCAE27B830C; Mon, 5 Aug 2013 19:53:40 +0200 (CEST) Date: Mon, 5 Aug 2013 19:53:40 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130805175340.GD897@elstar.local> Mail-Followup-To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf , "netmod@ietf.org" 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 , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:54:04 -0000 On Mon, Aug 05, 2013 at 05:35:30AM -0700, Andy Bierman wrote: > On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) > wrote: > > We need to start somewhere to discuss the priorities. So, let's start here. > > > > What would be your proposal for the development plan? > > > > Here is my development plan priorities: > > NETCONF WG: > > #1) RESTCONF (was YANG-API) > #2) Config state, operational state, conditional enablement > (IMO, all these are related problems) What is to be done about config state and operational state? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Aug 5 10:55:19 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1EEB21F9D83; Mon, 5 Aug 2013 10:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.242 X-Spam-Level: X-Spam-Status: No, score=-103.242 tagged_above=-999 required=5 tests=[AWL=0.007, 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 3eUKPxLlGKQj; Mon, 5 Aug 2013 10:55:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D21C421F99AB; Mon, 5 Aug 2013 10:55:09 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4539820BF5; Mon, 5 Aug 2013 19:55:09 +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 pL2bNE33SGwm; Mon, 5 Aug 2013 19:55: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 A8C7820BF1; Mon, 5 Aug 2013 19:55:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F1DEC27B8355; Mon, 5 Aug 2013 19:55:04 +0200 (CEST) Date: Mon, 5 Aug 2013 19:55:04 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20130805175504.GE897@elstar.local> Mail-Followup-To: Kent Watsen , Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf , "netmod@ietf.org" 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: "netmod@ietf.org" , Netconf Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:55:19 -0000 On Mon, Aug 05, 2013 at 02:10:23PM +0000, Kent Watsen wrote: > > NETMOD WG: > > #1) Extend as needed to minimize number of proprietary Juniper YANG > modules Any Juniper submissions I can look at to see what this means? > #2) Modules for basic EMS support (hardware, software, licenses, etc.) > #3) Data Model Transformation Engine What is a 'data model transformation engine' doing? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Mon Aug 5 11:16:28 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7279C21F9F5E; Mon, 5 Aug 2013 11:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.673 X-Spam-Level: X-Spam-Status: No, score=-1.673 tagged_above=-999 required=5 tests=[AWL=0.326, 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 o04w0BR4dA7D; Mon, 5 Aug 2013 11:16:27 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7E27A21F9F3D; Mon, 5 Aug 2013 11:16:27 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id ACBA613FD8D; Mon, 5 Aug 2013 20:16:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375726586; bh=TNczM848qB7APdhIv7xjfaW6wTdDF/iE/Jt8a+JpjB8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZRRZjkEuReLBDLPlRMy4u+Tdow2/z9hX/HX/zYaZHoUNrBRkxSWOCoqstnz5ywe7g J2Rc79vkzItKNTzG7YgltYLxxF4Llw5Iv6nr/jty07ttXs17Dyl1I4xhqwB4wArnIq FPW/kcodzTKvCDS3AfgAQtDsW8gF6F4Cw8BHJQ0E= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130805175245.GC897@elstar.local> Date: Mon, 5 Aug 2013 20:16:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <46EC47D7-A350-47BF-868D-26D0B61A6A88@nic.cz> References: <20130805175245.GC897@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" , Netconf Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 18:16:28 -0000 On Aug 5, 2013, at 7:52 PM, Juergen Schoenwaelder = wrote: > On Mon, Aug 05, 2013 at 11:56:14AM +0200, Ladislav Lhotka wrote: >>=20 >> IMO, YANG 2.0 should be protocol-independent, and a light-weight = adaptation layer should be defined for each protocol, including NETCONF. >>=20 >=20 > Someone needs to define 'protocol-independent'. If you want to make > YANG fully protocol-independent, then you will likely not finish and > create just another example of the 2nd systems effect [1]. XML schema languages are protocol-independent and IMO they are good = examples of what YANG specification should aim at. In fact, DSDL mapping = of YANG (RFC 6110) can help in this respect because the resulting DSDL = schemas can be used, by extension, in any non-NETCONF context already = now. Lada=20 >=20 > /js >=20 > [1] http://en.wikipedia.org/wiki/Second-system_effect >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Aug 5 12:26:05 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC26621F9DAA; Mon, 5 Aug 2013 12:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.242 X-Spam-Level: X-Spam-Status: No, score=-103.242 tagged_above=-999 required=5 tests=[AWL=0.007, 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 4TN6E1oiE+f5; Mon, 5 Aug 2013 12:26:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8CE21F8E8E; Mon, 5 Aug 2013 12:25:59 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2232020BE2; Mon, 5 Aug 2013 21:25:58 +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 yGOWU8aDrgNw; Mon, 5 Aug 2013 21:25:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 50B3B20BE1; Mon, 5 Aug 2013 21:25:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D0D2B27B8635; Mon, 5 Aug 2013 21:25:52 +0200 (CEST) Date: Mon, 5 Aug 2013 21:25:52 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20130805192552.GA1120@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf , "netmod@ietf.org" References: <20130805175245.GC897@elstar.local> <46EC47D7-A350-47BF-868D-26D0B61A6A88@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46EC47D7-A350-47BF-868D-26D0B61A6A88@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" , Netconf Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 19:26:05 -0000 On Mon, Aug 05, 2013 at 08:16:26PM +0200, Ladislav Lhotka wrote: > > On Aug 5, 2013, at 7:52 PM, Juergen Schoenwaelder wrote: > > > On Mon, Aug 05, 2013 at 11:56:14AM +0200, Ladislav Lhotka wrote: > >> > >> IMO, YANG 2.0 should be protocol-independent, and a light-weight adaptation layer should be defined for each protocol, including NETCONF. > >> > > > > Someone needs to define 'protocol-independent'. If you want to make > > YANG fully protocol-independent, then you will likely not finish and > > create just another example of the 2nd systems effect [1]. > > XML schema languages are protocol-independent and IMO they are good examples of what YANG specification should aim at. In fact, DSDL mapping of YANG (RFC 6110) can help in this respect because the resulting DSDL schemas can be used, by extension, in any non-NETCONF context already now. > YANG was designed to support NETCONF and as such it has a number of features that are related to NETCONF - and NETCONF is not just an XML editing tool. Do you propose to remove them? If so, do you propose these 'elements' become YANG 2.0 extensions? If the DSDL mapping of YANG already does the job and others are fine to use YANG as it is today, perhaps there is no problem to be solved. Note: I am just trying to find out what people mean when they use certain terms in this thread since we might easily speak past each other (or worse agree on something just to find out later that we have N different interpretations of 'something'). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Aug 5 13:04:47 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBBF21F8F4A; Mon, 5 Aug 2013 13:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.167, 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 zVg+oTLChGdq; Mon, 5 Aug 2013 13:04:41 -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 2A4D421F8C93; Mon, 5 Aug 2013 13:04:41 -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 3D75B12000A9; Mon, 5 Aug 2013 22:04:39 +0200 (CEST) Date: Mon, 05 Aug 2013 22:04:38 +0200 (CEST) Message-Id: <20130805.220438.348428424.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> 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, netmod@ietf.org Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 20:04:47 -0000 Ladislav Lhotka wrote: > > On Aug 5, 2013, at 5:49 PM, Balazs Lengyel > wrote: > > > > > On 2013-08-05 16:03, Ladislav Lhotka wrote: > >> It is a fact of life that YANG is being used outside NETCONF, and > >> there are more plans for doing do, but with 6020 it is a slippery > >> slope. For example, such non-NETCONF applications of YANG will most > >> likely want to use "must" for expressing semantic > >> constraints. However, the accessible tree for "must" is defined like > >> so: > >> > >> o If the context node represents configuration, the tree is the data > >> in the NETCONF datastore where the context node exists. The XPath > >> root node has all top-level configuration data nodes in all > >> modules as children. > >> > >> o If the context node represents state data, the tree is all state > >> data on the device, and the datastore. The XPath root > >> node has all top-level data nodes in all modules as children. > >> > >> This cannot be unambiguously interpreted in a non-NETCONF context, so > >> it is effectively undefined, which is rather dangerous. > >> So I don't mean to completely redesign YANG, but we cannot, on the > >> other hand, enable non-NETCONF YANG data modelling without providing > >> new definitions. > >> > >> Lada > > In my view Netconf contains the "pure" protocol (encoding, operations, > > transactional behavior...) and background plumbing (datastores, > > separation of state and config data, hierarchical data organisation, > > filtering, connection requirements, session concept, capability > > negotiation, many of the capabilites, error messages). > > The background plumbing is valid for all access methods (CLI, Netconf, > > YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be > > redefined. > > I don't think this is true. I2RS will probably have no distinction > between config and state data FWIW, this is not how I understand I2RS - I think they explicitly mention the configuration data as being one thing, and that they want another "direct" method to modify the operational state. /martin From j.schoenwaelder@jacobs-university.de Mon Aug 5 23:45:20 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2F721F9A33; Mon, 5 Aug 2013 23:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.242 X-Spam-Level: X-Spam-Status: No, score=-103.242 tagged_above=-999 required=5 tests=[AWL=0.007, 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 7tIJfNKxoUVG; Mon, 5 Aug 2013 23:45:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D00DA21F90CC; Mon, 5 Aug 2013 23:45:14 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 660B820BE9; Tue, 6 Aug 2013 08:45:12 +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 ux8JeFFJhMcz; Tue, 6 Aug 2013 08:45:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C320220BE2; Tue, 6 Aug 2013 08:45:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EBC3F27B911E; Tue, 6 Aug 2013 08:45:07 +0200 (CEST) Date: Tue, 6 Aug 2013 08:45:07 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130806064507.GA2435@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netconf@ietf.org, netmod@ietf.org References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <20130805.220438.348428424.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130805.220438.348428424.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org, netconf@ietf.org Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 06:45:20 -0000 On Mon, Aug 05, 2013 at 10:04:38PM +0200, Martin Bjorklund wrote: > > FWIW, this is not how I understand I2RS - I think they explicitly > mention the configuration data as being one thing, and that they want > another "direct" method to modify the operational state. > Yes, this is also my reading of draft-atlas-i2rs-architecture-01.txt, which is likely going to become the I2RS architecture document soon. /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 Aug 6 02:47:17 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939D521F9BAD; Tue, 6 Aug 2013 02:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.165 X-Spam-Level: X-Spam-Status: No, score=-5.165 tagged_above=-999 required=5 tests=[AWL=1.084, 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 MzAfBgLJwcMY; Tue, 6 Aug 2013 02:47:11 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A6B7A21F9B5C; Tue, 6 Aug 2013 02:47:10 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-31-5200c61dc5f8 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2F.B9.19388.D16C0025; Tue, 6 Aug 2013 11:47:09 +0200 (CEST) Received: from [159.107.197.78] (153.88.183.148) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.2.328.9; Tue, 6 Aug 2013 11:47:09 +0200 Message-ID: <5200C61C.4090103@ericsson.com> Date: Tue, 6 Aug 2013 11:47:08 +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: Ladislav Lhotka References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> In-Reply-To: <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+Jvra7sMYYggyXzTCweHJnFbnFh1Vw2 i6mbbrNazL/YyOrA4rFkyU8mj02X7zB6tPRfZAlgjuKySUnNySxLLdK3S+DK2NBgVLBLquLE sVOMDYwLRbsYOTgkBEwk5i8y7mLkBDLFJC7cW8/WxcjFISRwmFGifUo7C4SzmlHi8YSzjCBV vALaElf3HmAHsVkEVCR+tXaDxdkEjCSm9p9nAbFFBaIkWnunMkPUC0qcnPkELC4ioCxxccJP MJtZIENi25ZZYDXCAgYSd16BzARZtphFYmHfJ7AEp4CVxITWiYwQDbYSF+Zch2qWl9j+dg5Y jZCAhsTDC39ZJzAKzkKybxaSlllIWhYwMq9iZM9NzMxJLzffxAgM2INbfhvsYNx0X+wQozQH i5I472a9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGK01hcU6Gy/zd1+ayFg07bX6B8vD UafWXeSU+f5MusLF1D0uu0v7IMv0R9bv/1jcs13OOGM7e6KQb+TcJraJbe/u6DU4njfJTnx7 PH7/7I17N1Wf0Y9h4ZS5JBL0eOqe5P9GwZtf89wU7jbe/UzLZsrbfWJd9zhvXVfu2+xpL1bT pVFQb6b1WYmlOCPRUIu5qDgRAIVXIpImAgAA Cc: "netmod@ietf.org" , Netconf Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 09:47:17 -0000 On 2013-08-05 19:45, Ladislav Lhotka wrote: > On Aug 5, 2013, at 5:49 PM, Balazs Lengyel wrote: > >> On 2013-08-05 16:03, Ladislav Lhotka wrote: >>> It is a fact of life that YANG is being used outside NETCONF, and there are more plans for doing do, but with 6020 it is a slippery slope. For example, such non-NETCONF applications of YANG will most likely want to use "must" for expressing semantic constraints. However, the accessible tree for "must" is defined like so: >>> >>> o If the context node represents configuration, the tree is the data >>> in the NETCONF datastore where the context node exists. The XPath >>> root node has all top-level configuration data nodes in all >>> modules as children. >>> >>> o If the context node represents state data, the tree is all state >>> data on the device, and the datastore. The XPath root >>> node has all top-level data nodes in all modules as children. >>> >>> This cannot be unambiguously interpreted in a non-NETCONF context, so it is effectively undefined, which is rather dangerous. >>> So I don't mean to completely redesign YANG, but we cannot, on the other hand, enable non-NETCONF YANG data modelling without providing new definitions. >>> >>> Lada >> In my view Netconf contains the "pure" protocol (encoding, operations, transactional behavior...) and background plumbing (datastores, separation of state and config data, hierarchical data organisation, filtering, connection requirements, session concept, capability negotiation, many of the capabilites, error messages). >> The background plumbing is valid for all access methods (CLI, Netconf, YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be redefined. > I don't think this is true. I2RS will probably have no distinction between config and state data, though they may have read-write and read-only. Sessions and capability negotiation are by no means necessary (RESTCONF doesn't have it). I can actually imagine data modelling without any specific protocol for data exchange. > > Lada IMHO we can debate whether some protocols need some of the features, or whether some of the features belong to the plumbing or the pure protocol, but I still believe that many of the concepts like "NETCONF datastore" above are actually easily understandable without considering the protocol on the wire. If you would just remove the word Netconf from your example paragraphs IMHO they are quite understandable in a protocol independent way. Let me just try as an exercise: Running Datastore: A configuration datastore is defined as the complete set of configuration data that is required to get a device from its initial default state into a desired operational state. The configuration datastore does not include state data or executive commands. The running configuration datastore holds the complete configuration currently active on the network device. Only one configuration datastore of this type exists on the device, and it is always present. The above defeinition is extracted from RFC6241 (I just removed 2 sentences). I think it is a very nice protocol independent definition. Does anyone have a list of features that make YANG protocol (Netconf) dependent? Balazs From lhotka@nic.cz Tue Aug 6 03:21:59 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3C821F9346 for ; Tue, 6 Aug 2013 03:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, HOST_EQ_CZ=0.904, 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 vd-1pF0Fh0jq for ; Tue, 6 Aug 2013 03:21:53 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id E021F21F9DF1 for ; Tue, 6 Aug 2013 03:21:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6A20054047B for ; Tue, 6 Aug 2013 12:21:01 +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 Wi3aLQ2KrM1r for ; Tue, 6 Aug 2013 12:20:46 +0200 (CEST) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 0F59B5401AF for ; Tue, 6 Aug 2013 12:20:41 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20130805192552.GA1120@elstar.local> References: <20130805175245.GC897@elstar.local> <46EC47D7-A350-47BF-868D-26D0B61A6A88@nic.cz> <20130805192552.GA1120@elstar.local> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 06 Aug 2013 12:20:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 10:21:59 -0000 Juergen Schoenwaelder writes: > On Mon, Aug 05, 2013 at 08:16:26PM +0200, Ladislav Lhotka wrote: >> >> On Aug 5, 2013, at 7:52 PM, Juergen Schoenwaelder wrote: >> >> > On Mon, Aug 05, 2013 at 11:56:14AM +0200, Ladislav Lhotka wrote: >> >> >> >> IMO, YANG 2.0 should be protocol-independent, and a light-weight adaptation layer should be defined for each protocol, including NETCONF. >> >> >> > >> > Someone needs to define 'protocol-independent'. If you want to make >> > YANG fully protocol-independent, then you will likely not finish and >> > create just another example of the 2nd systems effect [1]. >> >> XML schema languages are protocol-independent and IMO they are good examples of what YANG specification should aim at. In fact, DSDL mapping of YANG (RFC 6110) can help in this respect because the resulting DSDL schemas can be used, by extension, in any non-NETCONF context already now. >> > > YANG was designed to support NETCONF and as such it has a number of > features that are related to NETCONF - and NETCONF is not just an XML > editing tool. Do you propose to remove them? If so, do you propose > these 'elements' become YANG 2.0 extensions? It depends. YANG 2.0 could work with the general notion of a "document" and an adaptation specification for a particular protocol would have to say what the document is supposed to be. For NETCONF, it could be (depending on the context) one of the datastores, running + state data, etc. The "rpc" and "rpc-reply" statements in YANG 2.0 would only determine the data contents, and the adaptation spec for a protocol would specify encapsulation, framing etc. - for instance, for NETCONF it would be while for RESTCONF it would be HTTP POST. And, for example, the "config" statement could possibly be a NETCONF specific extension. > > If the DSDL mapping of YANG already does the job and others are fine > to use YANG as it is today, perhaps there is no problem to be solved. The problem to be solved is to decouple YANG from NETCONF. What I meant is that semantics of DSDL languages are not defined in terms of NETCONF concept, so it might be possible to "backport" that semantics to YANG. > > Note: I am just trying to find out what people mean when they use > certain terms in this thread since we might easily speak past each > other (or worse agree on something just to find out later that we have > N different interpretations of 'something'). I hope I explained what I meant by 'protocol-independent DML' satisfactorily. :-) Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Aug 6 03:38:19 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEA321F9D82 for ; Tue, 6 Aug 2013 03:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.518, 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 qa9SH1XbXLHY for ; Tue, 6 Aug 2013 03:38:14 -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 EE7DD21F9D87 for ; Tue, 6 Aug 2013 03:38:13 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lj1so550195pab.29 for ; Tue, 06 Aug 2013 03:38:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VWm+1gQWkec3RZrNdf/OWDTzmKFdcipOCR5sehQjllM=; b=H7Eq7ZLCTTZkukcSbZyePf96xnP4WouxzhgT1pTO7sg+HeFmxlz6W1/nWarfcBsgxP U9daZXGnGLcgB8y6gFn9u84qAes9QRZ30DQtdMgpbO1yFUaZiuVL4GtkqWoVupbedzFZ Bvn7kwOakU86q9NGQ9YCGuqAkRUF1XerbsOPCqhhnU7xZkJi0/VHoiDNDpFm2+zpVO7d Vxcb31vepwVpWbc+BSG6mc7XFAhsbqEQjJzrgiuwy+KLxHAwooaXTMRTdA8yCDA4WjB3 jAB4oGZLGzrnwy6584cSnofLNl995A0C8b5DqtSXNpzNtjvfc6QnGDJvdZlgCPZhxlFU Q8HQ== X-Gm-Message-State: ALoCoQltn0TO3Wd+szJcdL5swPBqUPzUjkla6/Tz4LOiCOjIM6hIg9gulYYRkjaOKVtVm/zWTSWz MIME-Version: 1.0 X-Received: by 10.67.4.197 with SMTP id cg5mr2472396pad.10.1375785493551; Tue, 06 Aug 2013 03:38:13 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 6 Aug 2013 03:38:13 -0700 (PDT) In-Reply-To: <5200C61C.4090103@ericsson.com> References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> Date: Tue, 6 Aug 2013 03:38:13 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: text/plain; charset=ISO-8859-1 Cc: "netmod@ietf.org" , Netconf Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 10:38:19 -0000 Hi, I implemented the entire YANG-API (-01) draft within our server. There was no problem adapting the XPath at all, because the running config + state is exactly the same context in both. The XPath can be easily applied for calls such as /yang-api/oerations/get-config because the exact same message payload structure is expected. When we add notifications to RESTCONF, we will also make sure that the notification context is exactly the same. The only part of YANG we had to ignore was the insert operation parameters, encoded as XML attributes. The 'point' query string parameter is used instead of embedded XML attributes in the config. The yang-api-01 draft only allows the target node to be inserted, not arbitrary subnodes like an payload. IMO, all proposals to all WGs should be backed up by some running code, even experiments. When theorizing about solutions, it is easy to identify huge problems that actually do not exist, and just as easy to miss huge problems hiding in the implementation details. Andy On Tue, Aug 6, 2013 at 2:47 AM, Balazs Lengyel wrote: > > On 2013-08-05 19:45, Ladislav Lhotka wrote: >> >> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel >> wrote: >> >>> On 2013-08-05 16:03, Ladislav Lhotka wrote: >>>> >>>> It is a fact of life that YANG is being used outside NETCONF, and there >>>> are more plans for doing do, but with 6020 it is a slippery slope. For >>>> example, such non-NETCONF applications of YANG will most likely want to use >>>> "must" for expressing semantic constraints. However, the accessible tree for >>>> "must" is defined like so: >>>> >>>> o If the context node represents configuration, the tree is the >>>> data >>>> in the NETCONF datastore where the context node exists. The >>>> XPath >>>> root node has all top-level configuration data nodes in all >>>> modules as children. >>>> >>>> o If the context node represents state data, the tree is all state >>>> data on the device, and the datastore. The XPath root >>>> node has all top-level data nodes in all modules as children. >>>> >>>> This cannot be unambiguously interpreted in a non-NETCONF context, so it >>>> is effectively undefined, which is rather dangerous. >>>> So I don't mean to completely redesign YANG, but we cannot, on the other >>>> hand, enable non-NETCONF YANG data modelling without providing new >>>> definitions. >>>> >>>> Lada >>> >>> In my view Netconf contains the "pure" protocol (encoding, operations, >>> transactional behavior...) and background plumbing (datastores, separation >>> of state and config data, hierarchical data organisation, filtering, >>> connection requirements, session concept, capability negotiation, many of >>> the capabilites, error messages). >>> The background plumbing is valid for all access methods (CLI, Netconf, >>> YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be redefined. >> >> I don't think this is true. I2RS will probably have no distinction between >> config and state data, though they may have read-write and read-only. >> Sessions and capability negotiation are by no means necessary (RESTCONF >> doesn't have it). I can actually imagine data modelling without any specific >> protocol for data exchange. >> >> Lada > > IMHO we can debate whether some protocols need some of the features, or > whether some of the features belong to the plumbing or the pure protocol, > but I still believe that many of the concepts like "NETCONF datastore" above > are actually easily understandable without considering the protocol on the > wire. If you would just remove the word Netconf from your example paragraphs > IMHO they are quite understandable in a protocol independent way. > > Let me just try as an exercise: > Running Datastore: > > A configuration datastore is defined as the complete set of configuration > data that > is required to get a device from its initial default state into a > desired operational state. The configuration datastore does not > include state data or executive commands. > > The running configuration datastore holds the complete configuration > currently active on the network device. Only one configuration > datastore of this type exists on the device, and it is always > present. > > The above defeinition is extracted from RFC6241 (I just removed 2 > sentences). I think it is a very nice protocol independent definition. > > > Does anyone have a list of features that make YANG protocol (Netconf) > dependent? > > Balazs > From lhotka@nic.cz Tue Aug 6 03:56:07 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDCE21F9E2B; Tue, 6 Aug 2013 03:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.243 X-Spam-Level: X-Spam-Status: No, score=-1.243 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, HOST_EQ_CZ=0.904, 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 oO8J5D5bNu4z; Tue, 6 Aug 2013 03:56:02 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE7721F9E0D; Tue, 6 Aug 2013 03:56:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id C534154047B; Tue, 6 Aug 2013 12:55:55 +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 ehmmIyl9YEOU; Tue, 6 Aug 2013 12:55:48 +0200 (CEST) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 082D35401FC; Tue, 6 Aug 2013 12:55:41 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , Martin Bjorklund In-Reply-To: <20130806064507.GA2435@elstar.local> References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <20130805.220438.348428424.mbj@tail-f.com> <20130806064507.GA2435@elstar.local> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: Juergen Schoenwaelder , Martin Bjorklund , netconf@ietf.org, netmod@ietf.org Date: Tue, 06 Aug 2013 12:55:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 10:56:07 -0000 Juergen Schoenwaelder writes: > On Mon, Aug 05, 2013 at 10:04:38PM +0200, Martin Bjorklund wrote: >> >> FWIW, this is not how I understand I2RS - I think they explicitly >> mention the configuration data as being one thing, and that they want >> another "direct" method to modify the operational state. >> > > Yes, this is also my reading of draft-atlas-i2rs-architecture-01.txt, > which is likely going to become the I2RS architecture document soon. That document clearly states (Sec. 5.3): "... local device configuration is considered to be separate from the I2RS data store." So if Fig. 1 indicates that I2RS agents interact with Local Config, I assume it has to do so as a compliant NETCONF client. So "config true" data stay fully in the NETCONF realm. My conclusion from the discussion with the authors of draft-nitinb-i2rs-rib-info-model-01 is that I2RS data store is a subset of "config false" data from the NETCONF viewpoint, except that they are all read-only for NETCONF whereas the I2RS agent can write some of them. Maybe I2RS folks reading this thread can shed more light on this issue. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Aug 6 04:15:42 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E4321F9CBF for ; Tue, 6 Aug 2013 04:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.503, 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 mpE-oPdeJY1P for ; Tue, 6 Aug 2013 04:15:37 -0700 (PDT) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id CEEBD21F9B5C for ; Tue, 6 Aug 2013 04:15:37 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp2so278511pbb.14 for ; Tue, 06 Aug 2013 04:15:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=DMlRI5aZma9X7II5JKDQFH26sKNR6j+1HhJnRusW+kc=; b=dFshK6ftNwQ4ZsdLzou9lKw7A/gXAUMdbShXBCq7fm5R1Cr1a2mH6XY1bfmEG4p4AQ lABhbw0Rc50WrFd9vE9oXc6K4Uuo+crERQBam6dXnWVWa4Jj3piiTwwQNPpjDKvblwS8 ZWI4EhVRTyeY0Hp6EZ3oEhHrSl3hdRl8hU5MFWilLWhymQFeHUG63n2Y2gdM/K3DbU9d lwZFuS4wz405IVHilVoB3UPFrX+K9ty/oww0f4QCpWiX7USU9vsELHk1r7Y2FXQZNEMk TL6czNmK//eiUiWz9Mf7kVpV0FajGPwSEKJujL3EsFnc7o4/HiaRQu5s5alywudVz09l NTwA== X-Gm-Message-State: ALoCoQkoux0HZrd/J/Mpu93wyhFWXDk1w8M+x5VckqlVxbUjQgWcJwXV9jdhSyy+N38DB6NnYNpg MIME-Version: 1.0 X-Received: by 10.68.135.162 with SMTP id pt2mr969240pbb.42.1375787737451; Tue, 06 Aug 2013 04:15:37 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 6 Aug 2013 04:15:37 -0700 (PDT) In-Reply-To: References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <20130805.220438.348428424.mbj@tail-f.com> <20130806064507.GA2435@elstar.local> Date: Tue, 6 Aug 2013 04:15:37 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Martin Bjorklund , netconf@ietf.org, netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 11:15:43 -0000 On Tue, Aug 6, 2013 at 3:55 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > >> On Mon, Aug 05, 2013 at 10:04:38PM +0200, Martin Bjorklund wrote: >>> >>> FWIW, this is not how I understand I2RS - I think they explicitly >>> mention the configuration data as being one thing, and that they want >>> another "direct" method to modify the operational state. >>> >> >> Yes, this is also my reading of draft-atlas-i2rs-architecture-01.txt, >> which is likely going to become the I2RS architecture document soon. > > That document clearly states (Sec. 5.3): "... local device configuration = is considered to be separate from the I2RS data store." So if Fig. 1 indica= tes that I2RS agents interact with Local Config, I assume it has to do so a= s a compliant NETCONF client. So "config true" data stay fully in the NETCO= NF realm. > > My conclusion from the discussion with the authors of draft-nitinb-i2rs-r= ib-info-model-01 is that I2RS data store is a subset of "config false" data= from the NETCONF viewpoint, except that they are all read-only for NETCONF= whereas the I2RS agent can write some of them. > I have not finished the code yet, so I will not comment on details, but it should be quite possible to allow writable operational state to be supported so it is compatible with NETCONF. This meeting it was decided the injected state will not be tied to local config (i.e., made to persist). It only lasts until explicitly removed or the next server reboot. If you remember from the BoF, they want a fast path. So implementing I2RS with RESTCONF or NETCONF is just a matter of eliminating the slow parts ;-) > Maybe I2RS folks reading this thread can shed more light on this issue. > > Lada > >> >> /js >> Andy From j.schoenwaelder@jacobs-university.de Tue Aug 6 04:25:58 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD8921F9BD8; Tue, 6 Aug 2013 04:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.242 X-Spam-Level: X-Spam-Status: No, score=-103.242 tagged_above=-999 required=5 tests=[AWL=0.007, 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 FqePkUGhU09K; Tue, 6 Aug 2013 04:25:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5A85321F9AA3; Tue, 6 Aug 2013 04:25:51 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66F2420BE0; Tue, 6 Aug 2013 13:25:50 +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 LucUJCObH2_J; Tue, 6 Aug 2013 13:25:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAC9820BDF; Tue, 6 Aug 2013 13:25:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5F30127BC3BA; Tue, 6 Aug 2013 13:25:43 +0200 (CEST) Date: Tue, 6 Aug 2013 13:25:43 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund , netconf@ietf.org, netmod@ietf.org Message-ID: <20130806112543.GA3573@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org, netmod@ietf.org References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <20130805.220438.348428424.mbj@tail-f.com> <20130806064507.GA2435@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) Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 11:25:58 -0000 On Tue, Aug 06, 2013 at 12:55:37PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Mon, Aug 05, 2013 at 10:04:38PM +0200, Martin Bjorklund wrote: > >> > >> FWIW, this is not how I understand I2RS - I think they explicitly > >> mention the configuration data as being one thing, and that they want > >> another "direct" method to modify the operational state. > >> > > > > Yes, this is also my reading of draft-atlas-i2rs-architecture-01.txt, > > which is likely going to become the I2RS architecture document soon. > > That document clearly states (Sec. 5.3): "... local device configuration is considered to be separate from the I2RS data store." So if Fig. 1 indicates that I2RS agents interact with Local Config, I assume it has to do so as a compliant NETCONF client. So "config true" data stay fully in the NETCONF realm. > My reading of the I-D is that the want to read config, not write it. Nothing seems to persists in I2RS. The I2RS Agent will not attempt to retain or reapply state across routing element reboot. Anyway, we may have to check this document to make sure it really clearly says this when it gets final using a terminology we do understand. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Aug 6 04:28:01 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B72521F9CBD for ; Tue, 6 Aug 2013 04:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.242 X-Spam-Level: X-Spam-Status: No, score=-103.242 tagged_above=-999 required=5 tests=[AWL=0.007, 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 kbmLwXyPzMeb for ; Tue, 6 Aug 2013 04:27:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 74E5F21F9AA3 for ; Tue, 6 Aug 2013 04:27:56 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D8A9420BE9; Tue, 6 Aug 2013 13:27:55 +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 mqmUFjgZA18d; Tue, 6 Aug 2013 13:27:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EF0A20BDF; Tue, 6 Aug 2013 13:27:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8621727BC429; Tue, 6 Aug 2013 13:27:51 +0200 (CEST) Date: Tue, 6 Aug 2013 13:27:51 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20130806112751.GB3573@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20130805175245.GC897@elstar.local> <46EC47D7-A350-47BF-868D-26D0B61A6A88@nic.cz> <20130805192552.GA1120@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) Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 11:28:01 -0000 On Tue, Aug 06, 2013 at 12:20:40PM +0200, Ladislav Lhotka wrote: > > > > Note: I am just trying to find out what people mean when they use > > certain terms in this thread since we might easily speak past each > > other (or worse agree on something just to find out later that we have > > N different interpretations of 'something'). > > I hope I explained what I meant by 'protocol-independent DML' satisfactorily. :-) > Lets see: You want YANG to evolve into a general XML schema language if you say "protocol-independent". Is that a correct summary? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Tue Aug 6 04:36:35 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D8D21F96CA; Tue, 6 Aug 2013 04:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.319, 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 dtIJBQYUENKz; Tue, 6 Aug 2013 04:36: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 2D6C121F9D30; Tue, 6 Aug 2013 04:36: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 0F88813F889; Tue, 6 Aug 2013 13:36:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375788993; bh=WtzLsy+IS3S9diJuGMrPuEgmlx/GuWGcrk4RW+nIJqo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=meAds/J1yhbaFdmONt/chopCAMd9L/13IqCXNbiBoGR6u+IILahWmkiyye29cGRVx wO3Z4Hirwdc5RJXa1ens6Y4uk02Pl/uQhmDcirsU5D5iRvPbAIYkwanZo5r8ZLD+8m hM3e8VzWDAoy4TuZAwEZPyiVVT8wOagIMd4QLcto= 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: <5200C61C.4090103@ericsson.com> Date: Tue, 6 Aug 2013 13:36:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" , Netconf Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 11:36:35 -0000 On Aug 6, 2013, at 11:47 AM, Balazs Lengyel = wrote: >=20 > On 2013-08-05 19:45, Ladislav Lhotka wrote: >> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel = wrote: >>=20 >>> On 2013-08-05 16:03, Ladislav Lhotka wrote: >>>> It is a fact of life that YANG is being used outside NETCONF, and = there are more plans for doing do, but with 6020 it is a slippery slope. = For example, such non-NETCONF applications of YANG will most likely want = to use "must" for expressing semantic constraints. However, the = accessible tree for "must" is defined like so: >>>>=20 >>>> o If the context node represents configuration, the tree is the = data >>>> in the NETCONF datastore where the context node exists. The = XPath >>>> root node has all top-level configuration data nodes in all >>>> modules as children. >>>>=20 >>>> o If the context node represents state data, the tree is all = state >>>> data on the device, and the datastore. The XPath = root >>>> node has all top-level data nodes in all modules as children. >>>>=20 >>>> This cannot be unambiguously interpreted in a non-NETCONF context, = so it is effectively undefined, which is rather dangerous. >>>> So I don't mean to completely redesign YANG, but we cannot, on the = other hand, enable non-NETCONF YANG data modelling without providing new = definitions. >>>>=20 >>>> Lada >>> In my view Netconf contains the "pure" protocol (encoding, = operations, transactional behavior...) and background plumbing = (datastores, separation of state and config data, hierarchical data = organisation, filtering, connection requirements, session concept, = capability negotiation, many of the capabilites, error messages). >>> The background plumbing is valid for all access methods (CLI, = Netconf, YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to = be redefined. >> I don't think this is true. I2RS will probably have no distinction = between config and state data, though they may have read-write and = read-only. Sessions and capability negotiation are by no means necessary = (RESTCONF doesn't have it). I can actually imagine data modelling = without any specific protocol for data exchange. >>=20 >> Lada > IMHO we can debate whether some protocols need some of the features, = or whether some of the features belong to the plumbing or the pure = protocol, but I still believe that many of the concepts like "NETCONF = datastore" above are actually easily understandable without considering = the protocol on the wire. If you would just remove the word Netconf from = your example paragraphs IMHO they are quite understandable in a protocol = independent way. >=20 > Let me just try as an exercise: > Running Datastore: >=20 > A configuration datastore is defined as the complete set of = configuration data that > is required to get a device from its initial default state into a > desired operational state. The configuration datastore does not > include state data or executive commands. >=20 > The running configuration datastore holds the complete configuration > currently active on the network device. Only one configuration > datastore of this type exists on the device, and it is always > present. >=20 > The above defeinition is extracted from RFC6241 (I just removed 2 = sentences). I think it is a very nice protocol independent definition. This is certainly NOT a NETCONF-independent definition! Consider a data = model for an entire network: there is no single device to apply the data = to, and the "protocol" for updating the data store could be Emacs. But = then one may be able to transform such a document into real = configurations for real devices. =20 >=20 >=20 > Does anyone have a list of features that make YANG protocol (Netconf) = dependent? Apart from many definitions, there are (CL) rules that follow from how = NETCONF was designed. For example: in general it is not necessary that = lists have keys. Databases such as mongodb work fine without keys, = although they allow for defining optional keys for indexing (performance = reasons). YANG has mandatory list keys for config data because edit-config cannot = work without them. Maybe it is easier to start with features that should be common to all = YANG data models: They should be able to describe a schema for a data hierarchy following = the (restricted) XML model, including grammar, data types, semantic = rules and defaults, and similar schemas for RPCs and notifications. I believe it is possible to write a new YANG spec without referring to = any NETCONF data stores, state data or operations. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Aug 6 04:46:24 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5416921F9C4E for ; Tue, 6 Aug 2013 04:46:24 -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=[AWL=-0.011, 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 eJ64BTt1mdKp for ; Tue, 6 Aug 2013 04:46:19 -0700 (PDT) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4920721F9C72 for ; Tue, 6 Aug 2013 04:46:18 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id 10so240937pdc.33 for ; Tue, 06 Aug 2013 04:46:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=cobD45x0NUlV/bY75byBXQH/BSY2L70vvh1zcawJkgY=; b=KWCmDPgON80HR6LxhSAex+YCpkd6wtt/w75vJ5du2bH7FmIcHQJk8i4YGWAUQeFnfG XFBLHPsoczmrsF+akHsuE2oUpch9yQ3x62nSW+xaEa++ZgM1V/w7WcAiWJZ9UvNp9TwE vUX9XNtPJOMh0GpKoicwg1EqjbE15GtL0jj0O/02fn4GuFCw2WPhaVLG/8GHKd6jIwWB UpqL4dLFPJ/c5zqQrRuPODUUoTmIjNlWSIuqQ0IimkTSm36x8Smgrw2JE0FzmhszBnx/ aPhz9Y2BtyhFoFQ829DWs5Ex5IXmruV4ulWK7QOD+USEsGsaPXzfgsnwvxKyq2FoSHRK IJ/g== X-Gm-Message-State: ALoCoQmRJ0zMnOKFBfFrgaWrF3nUbdvLxPrhPwNEvyzDyNgkXYwG74RjTEfin0gqDmMHSXclQ6+8 MIME-Version: 1.0 X-Received: by 10.66.219.38 with SMTP id pl6mr2825358pac.59.1375789577599; Tue, 06 Aug 2013 04:46:17 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 6 Aug 2013 04:46:17 -0700 (PDT) In-Reply-To: References: <20130805175245.GC897@elstar.local> <46EC47D7-A350-47BF-868D-26D0B61A6A88@nic.cz> <20130805192552.GA1120@elstar.local> Date: Tue, 6 Aug 2013 04:46:17 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 11:46:24 -0000 On Tue, Aug 6, 2013 at 3:20 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: ... >>> > Someone needs to define 'protocol-independent'. If you want to make >>> > YANG fully protocol-independent, then you will likely not finish and >>> > create just another example of the 2nd systems effect [1]. >>> .... > It depends. YANG 2.0 could work with the general notion of a "document" a= nd an adaptation specification for a particular protocol would have to say = what the document is supposed to be. For NETCONF, it could be (depending on= the context) one of the datastores, running + state data, etc. > We got chartered to create YANG because it is not a general instance document definition language. I misspoke when I said "separate" protocol-independent parts. I meant just identify any differences in the protocol mapping document. No update to RFC 6020 is needed for this purpose. Your YANG-to-JSON draft is not quite what is needed. The real translation is YANG to RESTCONF (to NETCONF is already embedded in RFC 6020). Then there are JSON or XML encoding rules for the RESTCONF protocol. Andy From lhotka@nic.cz Tue Aug 6 04:47:16 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4670921F8FCE for ; Tue, 6 Aug 2013 04:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=0.290, 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 XI20BGcgVRtx for ; Tue, 6 Aug 2013 04:47:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 58E0721F9D87 for ; Tue, 6 Aug 2013 04:47:15 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 8265D13F889; Tue, 6 Aug 2013 13:47:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375789634; bh=2zh+74ANzV0pxlsYorjpjppakycXk/aMHCIuaIoG4e0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Z+e/z/dM+ndBYdw2oWEJYXAtVj/x9Zw4kL/QvtmCAEdCETgh1uEXqPJUOGkVSvhPM 7r/JU/P3mr6O81g8SijsbwG61hvJ4Erj6EmCtPnKQ8DbPC+2g55a9fwInKAe0BwyEC gkzboNXkz/lNVB+1yzkyuwxNNgU2Rr8iYnjWWjBk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130806112751.GB3573@elstar.local> Date: Tue, 6 Aug 2013 13:47:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3F7410B5-67CB-489B-8762-06BDD66157A2@nic.cz> References: <20130805175245.GC897@elstar.local> <46EC47D7-A350-47BF-868D-26D0B61A6A88@nic.cz> <20130805192552.GA1120@elstar.local> <20130806112751.GB3573@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 11:47:16 -0000 On Aug 6, 2013, at 1:27 PM, Juergen Schoenwaelder = wrote: > On Tue, Aug 06, 2013 at 12:20:40PM +0200, Ladislav Lhotka wrote: >>>=20 >>> Note: I am just trying to find out what people mean when they use >>> certain terms in this thread since we might easily speak past each >>> other (or worse agree on something just to find out later that we = have >>> N different interpretations of 'something'). >>=20 >> I hope I explained what I meant by 'protocol-independent DML' = satisfactorily. :-) >>=20 >=20 > Lets see: You want YANG to evolve into a general XML schema language > if you say "protocol-independent". Is that a correct summary? Essentially, yes. However, since YANG only addresses a subset of XML, it = could also work for JSON. And then there would be special parts defining RPCs and notifications. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Aug 6 05:00:01 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E4621F963C for ; Tue, 6 Aug 2013 05:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.489, 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 a9fFfFfCH+rQ for ; Tue, 6 Aug 2013 04:59:55 -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 8587921F95A6 for ; Tue, 6 Aug 2013 04:59:55 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so627673pab.11 for ; Tue, 06 Aug 2013 04:59:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=35fOb8LAzuKKVUzgCBzsJQVkl4rHQsK/TzTS5wFKqZw=; b=SKYIN+fBRF/cn0owSCe/7t4h+n1225YR8d30gwm1pjyAhTgDZb/xJGQmvCkjjxAL+E aTNY1alO4+dD96kDDy+w9V1VoEXXejZsEA8Ctb/c2+E1yH9BT3Lx6Euz+vXSxA9FsAIi z9vMMhBY7zut67YYLZsphPbG1lPFurpUI73GJ1rYZNt5Zrmh4w3rzEGH/H3Fk4wDwWg+ A9s5i+HRIla5k80ZkvhiTlW3PG21sdOWAfvUwU2NHq1gkGjSBE4RC+9dfbk+SEkxxAPw a5BW/PsFQVqH+m0Y/QJitGeJf/QDxNz+a+4D5MFQ1P8qH97b0U7EOcsAx9xVpuU03f94 fT9Q== X-Gm-Message-State: ALoCoQmcvfmaN7jLrhb+ZM0cmVb3FRjTZDJ0p8IDXd8ZiuhJVuzvMFpBJtKtsE2NZv1qBxtKC/za MIME-Version: 1.0 X-Received: by 10.66.159.72 with SMTP id xa8mr2899720pab.38.1375790395165; Tue, 06 Aug 2013 04:59:55 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 6 Aug 2013 04:59:54 -0700 (PDT) In-Reply-To: References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> Date: Tue, 6 Aug 2013 04:59:54 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 12:00:01 -0000 On Tue, Aug 6, 2013 at 4:36 AM, Ladislav Lhotka wrote: > > On Aug 6, 2013, at 11:47 AM, Balazs Lengyel = wrote: > >> >> On 2013-08-05 19:45, Ladislav Lhotka wrote: >>> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel wrote: >>> >>>> On 2013-08-05 16:03, Ladislav Lhotka wrote: ... > Apart from many definitions, there are (CL) rules that follow from how NE= TCONF was designed. For example: in general it is not necessary that lists = have keys. Databases such as mongodb work fine without keys, although they = allow for defining optional keys for indexing (performance reasons). > > YANG has mandatory list keys for config data because edit-config cannot w= ork without them. > I started implementing the optional-key feature in yang-api-01 but bailed on it because it was not going to be compatible with NETCONF, and the corner-cases for network device data structures that don't need keys are very limited. Fortunately we had the foresight to model the operation layer in YANG, so it is trivial to add a custom operation to let the server pick the key value (that is what mongodb is doing as well) like . > Maybe it is easier to start with features that should be common to all YA= NG data models: > They should be able to describe a schema for a data hierarchy following t= he (restricted) XML model, including grammar, data types, semantic rules an= d defaults, and similar schemas for RPCs and notifications. > > I believe it is possible to write a new YANG spec without referring to an= y NETCONF data stores, state data or operations. So far I have not heard anything that indicates RFC 6020 is broken. A new type of choice-stmt or XPath extensions, etc. are new features, not bug fixes. They can go in new RFCs that may update RFC 6020. > > Lada > Andy From andy@yumaworks.com Tue Aug 6 05:15:10 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF67821F9AC5 for ; Tue, 6 Aug 2013 05:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=-0.036, 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 7omLawf22Bks for ; Tue, 6 Aug 2013 05:15:05 -0700 (PDT) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by ietfa.amsl.com (Postfix) with ESMTP id 99DEE21F8C65 for ; Tue, 6 Aug 2013 05:15:05 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id r10so264032pdi.13 for ; Tue, 06 Aug 2013 05:15:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=N6ww8jBtJcG0uedTOta5loyKaWmy91gX6n3/pMUtTHA=; b=e9ZVE/E6IXqCB7JunD7oJmYMHDUvPF2QhfBdy45YkApyCUFAbtyNKN2OfXLb6cnLJs xFxGRt13TfImP70s7ZVwnbC7mZPJOQa1CfnAbEafasFSvzucX638QC84B0Y+fngaXBl+ mqqz8OU0U965fetbpokFnisf2G0D3mZ38Br+cgk7W28jgo7iFWqH+0oRF3RCvjozZgLz zTcLGNFz3wSYVonTHlcO89/hKvwEsVCVG3W1zSsWGNXnIg3EW/+R3see6d34R7E2190G AipcTHVIpAmaOGNnS5UHlbDl++YMoWws8wSspxHN1rvYs4SsYaGOGum4zU9t0ddFgwPp Nohg== X-Gm-Message-State: ALoCoQnj5pcHjzSBp0NHZxUDCiOv2VV7esxQKghW8eyFxD+azo1kZNjVHzgd02kkr7tO3GmisQf9 MIME-Version: 1.0 X-Received: by 10.68.19.162 with SMTP id g2mr1127030pbe.140.1375791305013; Tue, 06 Aug 2013 05:15:05 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 6 Aug 2013 05:15:04 -0700 (PDT) Date: Tue, 6 Aug 2013 05:15:04 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [netmod] Process for updating YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 12:15:10 -0000 Hi, It just occurred to me that we already have a way to update the YANG language that should work for 90% of use-cases: A feature should be deployed as a YANG extension and the NETMOD WG must agree it is needed. The YANG extension should be published in an RFC for 1 year before it can be promoted to a YANG language statement. When sufficient published extensions are ready for promotion a new YANG language version is published, making the promoted extensions YANG language statements, while deprecating the extension RFCs. A tiered release train might be familiar to software engineers. YANG is past the tinkering and experimenting phase. Companies want to use a stable specification that is properly maintained. Andy From lhotka@nic.cz Tue Aug 6 05:18:09 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF67321F9B0E; Tue, 6 Aug 2013 05:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.266, 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 1WbtM2FYMtci; Tue, 6 Aug 2013 05:18:09 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3941C21F9B0D; Tue, 6 Aug 2013 05:18:09 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 91B4A14011E; Tue, 6 Aug 2013 14:18:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375791487; bh=O+tQI0RYvwUOPPyiGbkecgd83njclmkXKc+4ea9oFP4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=is6yPoGNLkDhoaYg2Frc03hnnqtcqtOIE0LnPbto+TBunQ0yDXnyoiBq/P6gaOAAi pUPE3fIKoh2WZN1Fp3tI9aAwOcK6jbHtx7T/kkKTrsw1ynn2qDNjn80bFXxpR9TbJO 97F5w0nJ09FYWibHQ271lLnc4ITaR8eG71KUbT9I= 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: Tue, 6 Aug 2013 14:18:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130805175245.GC897@elstar.local> <46EC47D7-A350-47BF-868D-26D0B61A6A88@nic.cz> <20130805192552.GA1120@elstar.local> To: Netconf , netmod@ietf.org X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 12:18:10 -0000 On Aug 6, 2013, at 1:46 PM, Andy Bierman wrote: > On Tue, Aug 6, 2013 at 3:20 AM, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: > ... >>>>> Someone needs to define 'protocol-independent'. If you want to = make >>>>> YANG fully protocol-independent, then you will likely not finish = and >>>>> create just another example of the 2nd systems effect [1]. >>>>=20 > .... >> It depends. YANG 2.0 could work with the general notion of a = "document" and an adaptation specification for a particular protocol = would have to say what the document is supposed to be. For NETCONF, it = could be (depending on the context) one of the datastores, running + = state data, etc. >>=20 >=20 > We got chartered to create YANG because it is not > a general instance document definition language. >=20 > I misspoke when I said "separate" protocol-independent parts. > I meant just identify any differences in the protocol mapping > document. No update to RFC 6020 is needed for this purpose. RESTCONF (YANG-API) is pretty close to NETCONF in that it uses the same = datastores, but still, you have to use RFC 6020 in a very casual way. = For example: 6020 defines a precise encoding for "rpc" nodes, but there = is no element inside in the data part of the HTTP POST method.=20 >=20 > Your YANG-to-JSON draft is not quite what is needed. > The real translation is YANG to RESTCONF (to NETCONF > is already embedded in RFC 6020). Then there are JSON > or XML encoding rules for the RESTCONF protocol. Show me an XML snippet that can be modelled with YANG and cannot be = converted to JSON using my draft (and please don't use anyxml:-). Lada >=20 >=20 > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Aug 6 05:27:24 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F49921F9DA9 for ; Tue, 6 Aug 2013 05:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.465, 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 TNY9m3BTGzZI for ; Tue, 6 Aug 2013 05:27:19 -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 56C5421F9DF1 for ; Tue, 6 Aug 2013 05:27:15 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un15so350832pbc.15 for ; Tue, 06 Aug 2013 05:27:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1XQUgmNuZdpIOhfizgo+FAeY2BhtUCeFXtdBKXe0Sdo=; b=lMOeB1KXHq+yR9D2AV+yNge/DFjrk0ibRo3TRd4/e4NH4/ayfxSj/QGaKOwe3tKl6F sFIk+QScGtWGn8uX0cov8O7P7NJeWBK9WSq8dbTSaR3BX2JNCnapE4SerCEW/sKvxIu9 NA214a5JXw5GuJKdw+i34AbbJtg5iTuLSTCxj/NCXCIeM42CwHRagIr2E+0eVRHRLvNL 4lLF8q+N0utyqkGsr1ozoNNDO3O/DssUv81b/36w+pOGl8fx7Y+pg8lcEs4ur8buq/Kl 4vwDSHRd3+3TkswUfNAhKIXMge6XhkDWXVoWetaC7DpVYK1YHDUToQYu8trzGHQUDBgr S0Wg== X-Gm-Message-State: ALoCoQnQJaXEG3glw84ndDoqSQ5JJ0qay80MrxyfOroGbpo7kD6KgPj3p+I2kOnbQeCSUkQoCaKB MIME-Version: 1.0 X-Received: by 10.68.189.162 with SMTP id gj2mr1232100pbc.96.1375792029403; Tue, 06 Aug 2013 05:27:09 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 6 Aug 2013 05:27:09 -0700 (PDT) In-Reply-To: References: <20130805175245.GC897@elstar.local> <46EC47D7-A350-47BF-868D-26D0B61A6A88@nic.cz> <20130805192552.GA1120@elstar.local> Date: Tue, 6 Aug 2013 05:27:09 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Netconf , netmod@ietf.org Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 12:27:24 -0000 On Tue, Aug 6, 2013 at 5:18 AM, Ladislav Lhotka wrote: > > On Aug 6, 2013, at 1:46 PM, Andy Bierman wrote: > >> On Tue, Aug 6, 2013 at 3:20 AM, Ladislav Lhotka wrote: >>> Juergen Schoenwaelder writes: >> ... >>>>>> Someone needs to define 'protocol-independent'. If you want to make >>>>>> YANG fully protocol-independent, then you will likely not finish and >>>>>> create just another example of the 2nd systems effect [1]. >>>>> >> .... >>> It depends. YANG 2.0 could work with the general notion of a "document"= and an adaptation specification for a particular protocol would have to sa= y what the document is supposed to be. For NETCONF, it could be (depending = on the context) one of the datastores, running + state data, etc. >>> >> >> We got chartered to create YANG because it is not >> a general instance document definition language. >> >> I misspoke when I said "separate" protocol-independent parts. >> I meant just identify any differences in the protocol mapping >> document. No update to RFC 6020 is needed for this purpose. > > RESTCONF (YANG-API) is pretty close to NETCONF in that it uses the same d= atastores, but still, you have to use RFC 6020 in a very casual way. For ex= ample: 6020 defines a precise encoding for "rpc" nodes, but there is no element inside in the data part of the HTTP POST method. > That will have to get fixed before RFC publication. >> >> Your YANG-to-JSON draft is not quite what is needed. >> The real translation is YANG to RESTCONF (to NETCONF >> is already embedded in RFC 6020). Then there are JSON >> or XML encoding rules for the RESTCONF protocol. > > Show me an XML snippet that can be modelled with YANG and cannot be conve= rted to JSON using my draft (and please don't use anyxml:-). > You missed the point. NETCONF or RESTCONF peers do not send YANG messages. They send NETCONF or RESTCONF protocol messages. Various protocol operations return protocol-related meta-data associated with particular YANG data nodes. Your draft does not support protocol-related meta-data. Maybe this should be specified in the protocol document as an extension to your base encoding document. > Lada > >> Andy From lhotka@nic.cz Tue Aug 6 05:52:08 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DBC21F9E46; Tue, 6 Aug 2013 05:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=0.245, 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 HxpZHc8WHGPK; Tue, 6 Aug 2013 05:52:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7277521F9E36; Tue, 6 Aug 2013 05:51:52 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5F21F14011E; Tue, 6 Aug 2013 14:51:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375793509; bh=ZYv0AVK+R8Y00qQIEhHgM0hnOCAHpnmxsrH+pDxUDs0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=oRZtNesdEeo4XU4yNydxaknFJqF7d/DOGHoB8oHdplmVJbBzF6YPWMf5hPddsx1pP OQIHDeaGJAxFrmoa7j68g6VqxpiAneLC59/zwJa7GTCb8UQk6KDNWTQ1ejvAQXmn9W G852pdSCzMBT0cwPJdtwHiVp5QMcXE1Vb9jJmdg8= 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: Tue, 6 Aug 2013 14:51:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> 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 , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 12:52:08 -0000 On Aug 6, 2013, at 1:59 PM, Andy Bierman wrote: > On Tue, Aug 6, 2013 at 4:36 AM, Ladislav Lhotka wrote: >>=20 >> On Aug 6, 2013, at 11:47 AM, Balazs Lengyel = wrote: >>=20 >>>=20 >>> On 2013-08-05 19:45, Ladislav Lhotka wrote: >>>> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel = wrote: >>>>=20 >>>>> On 2013-08-05 16:03, Ladislav Lhotka wrote: > ... >> Apart from many definitions, there are (CL) rules that follow from = how NETCONF was designed. For example: in general it is not necessary = that lists have keys. Databases such as mongodb work fine without keys, = although they allow for defining optional keys for indexing (performance = reasons). >>=20 >> YANG has mandatory list keys for config data because edit-config = cannot work without them. >>=20 >=20 > I started implementing the optional-key feature in yang-api-01 but = bailed > on it because it was not going to be compatible with NETCONF, and the > corner-cases for network device data structures that don't need keys > are very limited. I do see the opposite: there is no sensible key to be assigned to routes = in routing tables (or a list of static routes). It would be nice to be = able to locate a route using *any* subset of route attributes. Of = course, preformance-wise it might be desirable to create indices for = some attributes, but using other attributes should still be allowed. =20 >=20 > Fortunately we had the foresight to model the operation layer in YANG, > so it is trivial to add a custom operation to let the server pick the > key value (that is what mongodb is doing as well) like > . >=20 >=20 >> Maybe it is easier to start with features that should be common to = all YANG data models: >> They should be able to describe a schema for a data hierarchy = following the (restricted) XML model, including grammar, data types, = semantic rules and defaults, and similar schemas for RPCs and = notifications. >>=20 >> I believe it is possible to write a new YANG spec without referring = to any NETCONF data stores, state data or operations. >=20 > So far I have not heard anything that indicates RFC 6020 is broken. Well, I am sure you've heard at least about the "when" statement: Its = context node is ill-defined, and 6020 states no constraints for its = XPath expression, which could lead to various race conditions. This has = been discussed several times in the NETMOD mailing list. > A new type of choice-stmt or XPath extensions, etc. are new features, > not bug fixes. They can go in new RFCs that may update RFC 6020. Introducing a new (alternative) choice statement via an extension should = be a taboo. Instead, it is necessary to change the semantics of the = existing choice statement.=20 Lada >=20 >>=20 >> Lada >>=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Aug 6 06:11:11 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B143421F99A8; Tue, 6 Aug 2013 06:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.228, 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 9vjGXHPMpOOE; Tue, 6 Aug 2013 06:11:11 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DCA5B21F8B4E; Tue, 6 Aug 2013 06:11:10 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 1E4FC14011E; Tue, 6 Aug 2013 15:11:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375794670; bh=98SRLeTKR1gDOaWgEhDmaa2Q+V5Rozj9Tip8WPwlAnQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=R4znIxN+1YQ/GgcrymBXJIgJzWFuMIqZgUmN5bfmJBnFdSyx4A1YkN7zdrVAkneN2 vaNLRFXjIoSGeQo4B+OtMCZTczrQAVvMoqUwjEiEl40qsRlyAZJo6+KbBAiwqqRwcb H2r5Jn8Eo+DBJxtXyyLxNWMsolNsSd+Z6GTokAwc= 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: Tue, 6 Aug 2013 15:11:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7F060156-9DD7-4538-880D-704C9C5AE62B@nic.cz> References: <20130805175245.GC897@elstar.local> <46EC47D7-A350-47BF-868D-26D0B61A6A88@nic.cz> <20130805192552.GA1120@elstar.local> To: netmod@ietf.org, Netconf X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 13:11:11 -0000 On Aug 6, 2013, at 2:27 PM, Andy Bierman wrote: > On Tue, Aug 6, 2013 at 5:18 AM, Ladislav Lhotka wrote: >>=20 >> On Aug 6, 2013, at 1:46 PM, Andy Bierman wrote: >>=20 >>> On Tue, Aug 6, 2013 at 3:20 AM, Ladislav Lhotka = wrote: >>>> Juergen Schoenwaelder = writes: >>> ... >>>>>>> Someone needs to define 'protocol-independent'. If you want to = make >>>>>>> YANG fully protocol-independent, then you will likely not finish = and >>>>>>> create just another example of the 2nd systems effect [1]. >>>>>>=20 >>> .... >>>> It depends. YANG 2.0 could work with the general notion of a = "document" and an adaptation specification for a particular protocol = would have to say what the document is supposed to be. For NETCONF, it = could be (depending on the context) one of the datastores, running + = state data, etc. >>>>=20 >>>=20 >>> We got chartered to create YANG because it is not >>> a general instance document definition language. >>>=20 >>> I misspoke when I said "separate" protocol-independent parts. >>> I meant just identify any differences in the protocol mapping >>> document. No update to RFC 6020 is needed for this purpose. >>=20 >> RESTCONF (YANG-API) is pretty close to NETCONF in that it uses the = same datastores, but still, you have to use RFC 6020 in a very casual = way. For example: 6020 defines a precise encoding for "rpc" nodes, but = there is no element inside in the data part of the HTTP POST = method. >>=20 >=20 > That will have to get fixed before RFC publication. >=20 >>>=20 >>> Your YANG-to-JSON draft is not quite what is needed. >>> The real translation is YANG to RESTCONF (to NETCONF >>> is already embedded in RFC 6020). Then there are JSON >>> or XML encoding rules for the RESTCONF protocol. >>=20 >> Show me an XML snippet that can be modelled with YANG and cannot be = converted to JSON using my draft (and please don't use anyxml:-). >>=20 >=20 > You missed the point. > NETCONF or RESTCONF peers do not send YANG messages. > They send NETCONF or RESTCONF protocol messages. > Various protocol operations return protocol-related meta-data > associated with particular YANG data nodes. The document deals just with the data part and it is not intended only = for RESTCONF. >=20 > Your draft does not support protocol-related meta-data. > Maybe this should be specified in the protocol document as an > extension to your base encoding document. Yes, this is possible and IMO better. Lada >=20 >=20 >> Lada >>=20 >>>=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From ietfc@btconnect.com Tue Aug 6 06:13:55 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FA121F9EAA; Tue, 6 Aug 2013 06:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.313 X-Spam-Level: X-Spam-Status: No, score=-3.313 tagged_above=-999 required=5 tests=[AWL=-0.714, 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 hBMzSMXTwxxN; Tue, 6 Aug 2013 06:13:49 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC1621F8B4E; Tue, 6 Aug 2013 06:13:48 -0700 (PDT) Received: from mail164-db9-R.bigfish.com (10.174.16.253) by DB9EHSOBE026.bigfish.com (10.174.14.89) with Microsoft SMTP Server id 14.1.225.22; Tue, 6 Aug 2013 13:13:47 +0000 Received: from mail164-db9 (localhost [127.0.0.1]) by mail164-db9-R.bigfish.com (Postfix) with ESMTP id 6EF161C0154; Tue, 6 Aug 2013 13:13:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.254.197; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0711HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -15 X-BigFish: PS-15(zz98dI9371I542I1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h8275bh8275dh1de097hz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail164-db9 (localhost.localdomain [127.0.0.1]) by mail164-db9 (MessageSwitch) id 1375794826196143_16496; Tue, 6 Aug 2013 13:13:46 +0000 (UTC) Received: from DB9EHSMHS020.bigfish.com (unknown [10.174.16.251]) by mail164-db9.bigfish.com (Postfix) with ESMTP id 2C7D9A0051; Tue, 6 Aug 2013 13:13:46 +0000 (UTC) Received: from DB3PRD0711HT001.eurprd07.prod.outlook.com (157.56.254.197) by DB9EHSMHS020.bigfish.com (10.174.14.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 6 Aug 2013 13:13:42 +0000 Received: from AMXPRD0111HT002.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.183.34) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 6 Aug 2013 13:13:41 +0000 Message-ID: <032801ce92a6$b971ea40$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder References: <20130805175340.GD897@elstar.local> Date: Tue, 6 Aug 2013 11:34:34 +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.250.117] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Netconf , netmod@ietf.org Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 13:13:55 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Andy Bierman" Cc: "Netconf" ; Sent: Monday, August 05, 2013 6:53 PM > On Mon, Aug 05, 2013 at 05:35:30AM -0700, Andy Bierman wrote: > > On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) > > wrote: > > > We need to start somewhere to discuss the priorities. So, let's start here. > > > > > > What would be your proposal for the development plan? > > > > Here is my development plan priorities: > > > > NETCONF WG: > > > > #1) RESTCONF (was YANG-API) > > #2) Config state, operational state, conditional enablement > > (IMO, all these are related problems) > > What is to be done about config state and operational state? Define them in a standards track RFC. I did look to review some of the modules in Last Call, decided I lacked sufficient understanding of the current thinking on how many 'states' there were and what the differences between them are, went looking for definitions, was unable to find any in any RFC or current I-Ds - and gave up:-( I suspect that if you are full time Netxxx, then this is not a problem; I am not and it is. Tom Petch > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Aug 6 06:29:52 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F23F21F8B4E; Tue, 6 Aug 2013 06:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=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 dkHdJIp9AQpe; Tue, 6 Aug 2013 06:29:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E3B7B21F84DB; Tue, 6 Aug 2013 06:29:46 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56B4720BE2; Tue, 6 Aug 2013 15:29:46 +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 nFASzq3gvCEV; Tue, 6 Aug 2013 15:29:46 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F16AD20BDC; Tue, 6 Aug 2013 15:29:45 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id E8B3927BCE38; Tue, 6 Aug 2013 15:29:40 +0200 (CEST) Date: Tue, 6 Aug 2013 15:29:40 +0200 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20130806132940.GA3995@elstar.jacobs.jacobs-university.de> Mail-Followup-To: "t.petch" , Netconf , netmod@ietf.org References: <20130805175340.GD897@elstar.local> <032801ce92a6$b971ea40$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <032801ce92a6$b971ea40$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf , netmod@ietf.org Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 13:29:52 -0000 On Tue, Aug 06, 2013 at 11:34:34AM +0100, t.petch wrote: > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "Andy Bierman" > Cc: "Netconf" ; > Sent: Monday, August 05, 2013 6:53 PM > > > On Mon, Aug 05, 2013 at 05:35:30AM -0700, Andy Bierman wrote: > > > On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) > > > wrote: > > > > We need to start somewhere to discuss the priorities. So, let's > start here. > > > > > > > > What would be your proposal for the development plan? > > > > > > Here is my development plan priorities: > > > > > > NETCONF WG: > > > > > > #1) RESTCONF (was YANG-API) > > > #2) Config state, operational state, conditional enablement > > > (IMO, all these are related problems) > > > > What is to be done about config state and operational state? > > Define them in a standards track RFC. > > I did look to review some of the modules in Last Call, decided I lacked > sufficient understanding of the current thinking on how many 'states' > there were and what the differences between them are, went looking for > definitions, was unable to find any in any RFC or current I-Ds - and > gave up:-( > What about RFC 6244 Section 4.3 as a start? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jmh@joelhalpern.com Tue Aug 6 08:42:50 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E03521E8088; Tue, 6 Aug 2013 08:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 CwG3R1NuYeZh; Tue, 6 Aug 2013 08:42:45 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 0542421E804D; Tue, 6 Aug 2013 08:42:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E6D27102318; Tue, 6 Aug 2013 08:42:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-254.clppva.east.verizon.net [70.106.134.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id ED6041021D7; Tue, 6 Aug 2013 08:42:43 -0700 (PDT) Message-ID: <52011972.5050406@joelhalpern.com> Date: Tue, 06 Aug 2013 11:42:42 -0400 From: "Joel M. Halpern" 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: Juergen Schoenwaelder , Martin Bjorklund , netconf@ietf.org, netmod@ietf.org References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <20130805.220438.348428424.mbj@tail-f.com> <20130806064507.GA2435@elstar.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 15:42:50 -0000 If there is an arrow in figure 1 of the I2RS architecture implying that an I2RS agent manipulates the config data, then we need to fix that. The intention of the authors (and the intention agreed in earlier documents) is that I2RS does not mes with config data. The amplification in the architecture document is that I2RS simply does not mess with any persistent data storage at all. I2RS state is lost at reboot. The working group sounded happy with this proposal in Berlin. We will see what happens on the list. Yours, Joel M. Halpern, I2RS Architecture coauthor and netconf/netmod spectator. On 8/6/13 6:55 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > >> On Mon, Aug 05, 2013 at 10:04:38PM +0200, Martin Bjorklund wrote: >>> >>> FWIW, this is not how I understand I2RS - I think they explicitly >>> mention the configuration data as being one thing, and that they want >>> another "direct" method to modify the operational state. >>> >> >> Yes, this is also my reading of draft-atlas-i2rs-architecture-01.txt, >> which is likely going to become the I2RS architecture document soon. > > That document clearly states (Sec. 5.3): "... local device configuration is considered to be separate from the I2RS data store." So if Fig. 1 indicates that I2RS agents interact with Local Config, I assume it has to do so as a compliant NETCONF client. So "config true" data stay fully in the NETCONF realm. > > My conclusion from the discussion with the authors of draft-nitinb-i2rs-rib-info-model-01 is that I2RS data store is a subset of "config false" data from the NETCONF viewpoint, except that they are all read-only for NETCONF whereas the I2RS agent can write some of them. > > Maybe I2RS folks reading this thread can shed more light on this issue. > > Lada > >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > From bertietf@bwijnen.net Fri Aug 9 01:55:00 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B3121F9F80 for ; Fri, 9 Aug 2013 01:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ewbbZe+aRZTx for ; Fri, 9 Aug 2013 01:54:55 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 35E4C21F9E9C for ; Fri, 9 Aug 2013 01:54:54 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V7iTD-0004Ed-SM for netmod@ietf.org; Fri, 09 Aug 2013 10:54:53 +0200 Received: from kitten.ripe.net ([193.0.1.240] helo=guest137.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1V7iTD-0006FE-QK for netmod@ietf.org; Fri, 09 Aug 2013 10:54:51 +0200 Message-ID: <5204AE5C.6000307@bwijnen.net> Date: Fri, 09 Aug 2013 10:54:52 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130809 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd437196f157e98d9f30c00cfc4374875c8 Subject: [netmod] WG LC review of draft-ietf-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 08:55:00 -0000 I have read and reviewed draft-ietf-netmod-iana-timezones-00.txt I see that on page http://www.iana.org/time-zones there is a Latest version Time Zone Data v. 2013d (Released 2013-07-05) The module in the draft (createdmid 2012) states: revision 2012-07-09 { description "Initial revision. Using IANA Time Zone Data v. 2012c (Released 2012-03-27)"; reference "RFC XXXX: TITLE"; Does it make sense to update to the latest revision? Or is that something IANA should do? Other than that I think this document is ready for publication as a standards track RFC. I have not checked all the entries/enumerations, I assume that has already been done. Or probably the entries were programatically extracted from the tz database. Bert From balazs.lengyel@ericsson.com Fri Aug 9 03:43:19 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1636021F99CD for ; Fri, 9 Aug 2013 03:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.32 X-Spam-Level: X-Spam-Status: No, score=-5.32 tagged_above=-999 required=5 tests=[AWL=0.929, 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 64KkUYujouIa for ; Fri, 9 Aug 2013 03:43:12 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E6E5121F9FCA for ; Fri, 9 Aug 2013 03:43:03 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-62-5204c7b6a642 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 66.37.19388.6B7C4025; Fri, 9 Aug 2013 12:43:02 +0200 (CEST) Received: from [159.107.197.114] (153.88.183.18) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.2.328.9; Fri, 9 Aug 2013 12:43:02 +0200 Message-ID: <5204C7B5.8060706@ericsson.com> Date: Fri, 9 Aug 2013 12:43:01 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ladislav Lhotka , "netmod@ietf.org" References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvre624yxBBiu/qVlcWDWXzWL+xUZW ByaPJUt+MnlsunyHMYApissmJTUnsyy1SN8ugStjz+k57AU7xStezZzI3sC4V6iLkZNDQsBE Ys2qTUwQtpjEhXvr2UBsIYHDjBJPHvN1MXIB2asZJV5tPQlWxCugLdG7cyNYEYuAisTXu8vB bDYBI4mp/edZQGxRgSiJDdsvsEDUC0qcnPkEzBYR8JC43n+REcQWFjCQuPPqADvEgo8sErs6 IBKcAlYSN391sYPYzAK2EhfmXGeBsOUltr+dwwxxnYbEwwt/WScwCsxCsmMWkpZZSFoWMDKv YmTPTczMSS8338QIDL6DW34b7GDcdF/sEKM0B4uSOO9mvTOBQgLpiSWp2ampBalF8UWlOanF hxiZODilGhgL/lQfinrJPSfiXmbwzMRZjuy3OM9d/xqYFyAmprLE64RtgWVDwre5rmu8b8p+ Z2mPDTdYIb3zaJWs2wm3okrz+P3zSiKqOtZZ+YbtcVN6sqNg87TcGaXcUo7iR6XnP3p3KriO 91G6uoGfeW3d60cSZiW83mcYz1zg7p6/9chLPr2WPbcdbiuxFGckGmoxFxUnAgAtMfY8DAIA AA== Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 10:43:19 -0000 See the end! On 2013-08-06 13:36, Ladislav Lhotka wrote: > > A configuration datastore is defined as the complete set of configuration data that > is required to get a device from its initial default state into a > desired operational state. The configuration datastore does not > include state data or executive commands. > > The running configuration datastore holds the complete configuration > currently active on the network device. Only one configuration > datastore of this type exists on the device, and it is always > present. > > The above defeinition is extracted from RFC6241 (I just removed 2 sentences). I think it is a very nice protocol independent definition. > This is certainly NOT a NETCONF-independent definition! Consider a data model for an entire network: there is no single device to apply the data to, and the "protocol" for updating the data store could be Emacs. But then one may be able to transform such a document into real configurations for real devices. > >> >> Does anyone have a list of features that make YANG protocol (Netconf) dependent? > Apart from many definitions, there are (CL) rules that follow from how NETCONF was designed. For example: in general it is not necessary that lists have keys. Databases such as mongodb work fine without keys, although they allow for defining optional keys for indexing (performance reasons). > > YANG has mandatory list keys for config data because edit-config cannot work without them. > > Maybe it is easier to start with features that should be common to all YANG data models: > They should be able to describe a schema for a data hierarchy following the (restricted) XML model, including grammar, data types, semantic rules and defaults, and similar schemas for RPCs and notifications. > > I believe it is possible to write a new YANG spec without referring to any NETCONF data stores, state data or operations. > > Lada {BALAZS}: I don't see why we would want to get read of multiple datastores or state versus configuration data. These are basic device management concepts that are relevant to any protocol managing a device. E.g. the exsistence of a startup datastore is dependent on the data storage and and restart methods used by the device, but is independent of the protocol. They are already used by Netconf, CLI, GUI so three ways to manipulate the config. Yes, I can imagine a device, that doesn't use these concepts , but do we want to accomodate them as well, or are trying to provide additional interfaces that depend on the same basic concepts used by Netconf. If we throw out such basic concepts, the deviation from Netconf becomes too big for my liking, that is I would not like to see. Balazs IMHO: -- 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 lhotka@nic.cz Fri Aug 9 04:11:23 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA2621F9F0A for ; Fri, 9 Aug 2013 04:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=0.188, 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 U1vwEfYQrC8T for ; Fri, 9 Aug 2013 04:11:17 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4A64A21F9F44 for ; Fri, 9 Aug 2013 04:11:16 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 4AF6613FB93; Fri, 9 Aug 2013 13:11:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1376046675; bh=ZD1HKpNqJ5Mca96B+W1WzzqsP2AMWB5xQ97JZFPfP/Q=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qReDoPpsfnmmx4d0V+enFULr4rfQ5O8BR8GDeOO1aQegf95CFR10TrZw8b0jEWXtJ D7Q7IVMgThKKvYF9peLrK4NTMchNYybfzv2x01m20Cu1IeFkbIJ/8pS0tUk4R4x/BH 9PxoBSLJtCGMHzwyxJ9vK2U1NWFIiOqG0p1iASdw= 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: <5204C7B5.8060706@ericsson.com> Date: Fri, 9 Aug 2013 13:11:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <5204C7B5.8060706@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 11:11:23 -0000 On Aug 9, 2013, at 12:43 PM, Balazs Lengyel = wrote: > See the end! >=20 > On 2013-08-06 13:36, Ladislav Lhotka wrote: >>=20 >> A configuration datastore is defined as the complete set of = configuration data that >> is required to get a device from its initial default state into a >> desired operational state. The configuration datastore does not >> include state data or executive commands. >>=20 >> The running configuration datastore holds the complete = configuration >> currently active on the network device. Only one configuration >> datastore of this type exists on the device, and it is always >> present. >>=20 >> The above defeinition is extracted from RFC6241 (I just removed 2 = sentences). I think it is a very nice protocol independent definition. >> This is certainly NOT a NETCONF-independent definition! Consider a = data model for an entire network: there is no single device to apply the = data to, and the "protocol" for updating the data store could be Emacs. = But then one may be able to transform such a document into real = configurations for real devices. >> =20 >>>=20 >>> Does anyone have a list of features that make YANG protocol = (Netconf) dependent? >> Apart from many definitions, there are (CL) rules that follow from = how NETCONF was designed. For example: in general it is not necessary = that lists have keys. Databases such as mongodb work fine without keys, = although they allow for defining optional keys for indexing (performance = reasons). >>=20 >> YANG has mandatory list keys for config data because edit-config = cannot work without them. >>=20 >> Maybe it is easier to start with features that should be common to = all YANG data models: >> They should be able to describe a schema for a data hierarchy = following the (restricted) XML model, including grammar, data types, = semantic rules and defaults, and similar schemas for RPCs and = notifications. >>=20 >> I believe it is possible to write a new YANG spec without referring = to any NETCONF data stores, state data or operations. >>=20 >> Lada > {BALAZS}: I don't see why we would want to get read of multiple = datastores or state versus configuration data. These are basic device = management concepts that are relevant to any protocol managing a device. = E.g. the exsistence of a startup datastore is dependent on the data = storage and and restart methods used by the device, but is independent = of the protocol. They are already used by Netconf, CLI, GUI so three = ways to manipulate the config. >=20 > Yes, I can imagine a device, that doesn't use these concepts , but do = we want to accomodate them as well, or are trying to provide additional = interfaces that depend on the same basic concepts used by Netconf. If we = throw out such basic concepts, the deviation from Netconf becomes too = big for my liking, that is I would not like to see. Do you mean we should recommend the authors of = draft-clemm-netmod-yang-network-topo-00 to drop YANG and use XML schema = languages instead? Their data model is clearly outside the scope of = device-oriented network management - in fact, the very question whether = the contents are config true or false doesn't make much sense to me. What I had in mind with YANG 2.0 was a more generic data modelling = language that could be used for such cases, too. A small "adaptation" = document could then provide specific info for a particular use or = protocol. The result of this combination for NETCONF could be pretty = much the same as RFC 6020. Lada >=20 > Balazs > IMHO: >=20 > --=20 > 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 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Fri Aug 9 05:11:22 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A4C21F9B7F for ; Fri, 9 Aug 2013 05:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.237 X-Spam-Level: X-Spam-Status: No, score=-103.237 tagged_above=-999 required=5 tests=[AWL=0.012, 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 Ct8nhTSHXAwR for ; Fri, 9 Aug 2013 05:11:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 090F121F9FE7 for ; Fri, 9 Aug 2013 05:11:06 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4585320C12; Fri, 9 Aug 2013 14:11:05 +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 ghPFwS6qWVzj; Fri, 9 Aug 2013 14:11:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B855E20BFE; Fri, 9 Aug 2013 14:11:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A50EB27C3D36; Fri, 9 Aug 2013 14:10:58 +0200 (CEST) Date: Fri, 9 Aug 2013 14:10:58 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20130809121057.GA13342@elstar.local> Mail-Followup-To: Ladislav Lhotka , Balazs Lengyel , "netmod@ietf.org" References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <5204C7B5.8060706@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 12:11:23 -0000 On Fri, Aug 09, 2013 at 01:11:14PM +0200, Ladislav Lhotka wrote: > > Do you mean we should recommend the authors of draft-clemm-netmod-yang-network-topo-00 to drop YANG and use XML schema languages instead? Their data model is clearly outside the scope of device-oriented network management - in fact, the very question whether the contents are config true or false doesn't make much sense to me. > > What I had in mind with YANG 2.0 was a more generic data modelling language that could be used for such cases, too. A small "adaptation" document could then provide specific info for a particular use or protocol. The result of this combination for NETCONF could be pretty much the same as RFC 6020. > I do not see why YANG can't be used to read/write configuration to a network manager that generates device configuration. I do not know whether this is the intention behind the I-D but ultimately I hope we start working at some point in time on _network_ management rather than just _device_ management. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Fri Aug 9 06:16:09 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062C311E80D2 for ; Fri, 9 Aug 2013 06:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.177, 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 IdIkNOWHPJy3 for ; Fri, 9 Aug 2013 06:16:08 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4266321F9F95 for ; Fri, 9 Aug 2013 06:16:08 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 16A0F13FB93 for ; Fri, 9 Aug 2013 15:16:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1376054166; bh=53evk3aLGLNuERqbgMU48a79Sjff52FQDDT6FLjiJis=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=Urj32LZfwaWZjPn47zbOVRPBQiJmw4qXBXVSV7xbul3TQzVOEf+RG1WCIFndEoivF S4UzF91wXleH8rTjbwPhJGRgOq8+pChYMuz/BlB8TyPUn33WbTAcLXFs33B0pmwiGw CgdI6CMUlfbyg5D8tYQgobhQ7G9zdVzSf1adr+7s= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130809121057.GA13342@elstar.local> Date: Fri, 9 Aug 2013 15:16:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <47D65CBB-664F-4517-A601-D900DB4B9B9B@nic.cz> References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <5204C7B5.8060706@ericsson.com> <20130809121057.GA13342@elstar.local> To: netmod@ietf.org X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 13:16:09 -0000 On Aug 9, 2013, at 2:10 PM, Juergen Schoenwaelder = wrote: > On Fri, Aug 09, 2013 at 01:11:14PM +0200, Ladislav Lhotka wrote: >>=20 >> Do you mean we should recommend the authors of = draft-clemm-netmod-yang-network-topo-00 to drop YANG and use XML schema = languages instead? Their data model is clearly outside the scope of = device-oriented network management - in fact, the very question whether = the contents are config true or false doesn't make much sense to me. >>=20 >> What I had in mind with YANG 2.0 was a more generic data modelling = language that could be used for such cases, too. A small "adaptation" = document could then provide specific info for a particular use or = protocol. The result of this combination for NETCONF could be pretty = much the same as RFC 6020. >>=20 >=20 > I do not see why YANG can't be used to read/write configuration to a > network manager that generates device configuration. I do not know > whether this is the intention behind the I-D but ultimately I hope we > start working at some point in time on _network_ management rather > than just _device_ management. The fact of the matter is that YANG is used there as an XML schema = language, unrelated to NETCONF. I can imagine YANG to be a good candidate language for modelling the = I2RS data store, which by definition isn't NETCONF data store. On a practical side: YANG might be useful to people that have no idea = about NETCONF and don't want to get any. For them, reading RFC 6020 = would be an unnecessarily difficult and long exercise, with all the = references to NETCONF data stores, operations, server = behaviour etc. Lada=20 >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Fri Aug 9 06:48:03 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F66A21F9E7E for ; Fri, 9 Aug 2013 06:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[AWL=0.168, 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 Juuu0RNE3u4A for ; Fri, 9 Aug 2013 06:48:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5CB11E80D2 for ; Fri, 9 Aug 2013 06:48:01 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C34A7140179 for ; Fri, 9 Aug 2013 15:47:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1376056071; bh=WTfDHS1ZANiJ1GeryoJgjDYDKKOM4WeLxP9DmdDF3Yo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=HPJcOeIWKEJI7bDY+Y5msqQBIbDtQV+DG6diE8be1lslI22x5bPUInxbevzRbFriR 1w6oiuUJgwJRWmVspnQc9wAP25OBVUHB0E3on29yUpttBPAasaXgbRNTpCHTOfrqjg Z6oA6QS9RXvpJPf7sGy7A64LrnlYG4OAhlaNPoRg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130809133851.GA13879@elstar.local> Date: Fri, 9 Aug 2013 15:47:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <5204C7B5.8060706@ericsson.com> <20130809121057.GA13342@elstar.local> <278060A8-8092-4773-B89A-063E0875ED74@nic.cz> <20130809133851.GA13879@elstar.local> To: netmod@ietf.org X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 13:48:03 -0000 On Aug 9, 2013, at 3:38 PM, Juergen Schoenwaelder = wrote: > On Fri, Aug 09, 2013 at 03:14:42PM +0200, Ladislav Lhotka wrote: >>=20 >> The fact of the matter is that YANG is used there as an XML schema = language, unrelated to NETCONF. >=20 > This is your interpretation. Sure. >=20 >> I can imagine YANG to be a good candidate language for modelling the = I2RS data store, which by definition isn't NETCONF data store. >=20 > This is your interpretation. Sure. >=20 >> On a practical side: YANG might be useful to people that have no idea = about NETCONF and don't want to get any. For them, reading RFC 6020 = would be an unnecessarily difficult and long exercise, with all the = references to NETCONF data stores, operations, server = behaviour etc. >>=20 >=20 > It would be nice if those people trying to use YANG for completely > different purposes would stand up and tell us that there indeed is a > problem with using RFC 6020 and what exactly this problem is. At the end of the NETMOD session I heard several voices in support of my = proposal to decouple YANG from NETCONF. Lada >=20 > Your position seems clear to me - no need to repeat it. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Fri Aug 9 06:56:33 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A8711E810C for ; Fri, 9 Aug 2013 06:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.231 X-Spam-Level: X-Spam-Status: No, score=-103.231 tagged_above=-999 required=5 tests=[AWL=0.018, 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 cjajjDas2TKN for ; Fri, 9 Aug 2013 06:56:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BCAF311E8100 for ; Fri, 9 Aug 2013 06:56:27 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 324C320C12; Fri, 9 Aug 2013 15:56:27 +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 qw1nfba_sIQb; Fri, 9 Aug 2013 15:56:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD31620C0B; Fri, 9 Aug 2013 15:56:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 64B9927C46A7; Fri, 9 Aug 2013 15:56:22 +0200 (CEST) Date: Fri, 9 Aug 2013 15:56:22 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20130809135622.GA13994@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <5204C7B5.8060706@ericsson.com> <20130809121057.GA13342@elstar.local> <278060A8-8092-4773-B89A-063E0875ED74@nic.cz> <20130809133851.GA13879@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: netmod@ietf.org Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 13:56:33 -0000 On Fri, Aug 09, 2013 at 03:47:51PM +0200, Ladislav Lhotka wrote: > > At the end of the NETMOD session I heard several voices in support of my proposal to decouple YANG from NETCONF. > The problem is that people sometimes agree to something where the same people afterwards find out it means very different things to them. Hence I am trying to find out what people really want - there are apparently different definitions for "decouple YANG from NETCONF" that people have in their minds. /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 Fri Aug 9 07:11:53 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4540921F9E40 for ; Fri, 9 Aug 2013 07:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.404, 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 Q2SJP3w7jH6C for ; Fri, 9 Aug 2013 07:11:48 -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 CF6C411E8100 for ; Fri, 9 Aug 2013 07:11:47 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un15so4641385pbc.29 for ; Fri, 09 Aug 2013 07:11:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zQcK5WSQdoQOdhk+/tD2tW+8qG30j1n4JjxaCcK9PmU=; b=P7djPWCsw1jgPWMEaKgY9BuNx8yKrChFTCFwqbPITrSv4E8iv4vc/HmsHpEvriUspf GiojGxno/zjQzl0ZFMM9TKeFSTK0hhrERP7nozjLMd8VSmfKxmIxyupiyfAICzM3FwZn TYr3MYsUaxyMtQLQT0SliF3DJ111CU0rT8LPesQwJfx2X4ZsVHWsp3/PseRmTFsb/j06 EU+4TsTf5KjbPNjjyF7ysLUwfZsVB661I+Z2Y3i+2Q1+TxEA0e+1YMvSQxTgCZeFT9Vn pv4NImC0exU7DH7DShzGxCNZqMfQevsq3nNfa3fiZiYdSL4pYG7M7guWFicrK2gLiaff PzRQ== X-Gm-Message-State: ALoCoQnaRE/UJp+EmjnK+v/njyUjMEKgMKGQuVSrr84EachRiF+Mt7YF8Q+gM1TZbxvZuZbMrP9T MIME-Version: 1.0 X-Received: by 10.66.159.72 with SMTP id xa8mr11899842pab.38.1376057505916; Fri, 09 Aug 2013 07:11:45 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Fri, 9 Aug 2013 07:11:45 -0700 (PDT) In-Reply-To: <47D65CBB-664F-4517-A601-D900DB4B9B9B@nic.cz> References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <5204C7B5.8060706@ericsson.com> <20130809121057.GA13342@elstar.local> <47D65CBB-664F-4517-A601-D900DB4B9B9B@nic.cz> Date: Fri, 9 Aug 2013 07:11:45 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 14:11:53 -0000 On Fri, Aug 9, 2013 at 6:16 AM, Ladislav Lhotka wrote: > > On Aug 9, 2013, at 2:10 PM, Juergen Schoenwaelder wrote: > >> On Fri, Aug 09, 2013 at 01:11:14PM +0200, Ladislav Lhotka wrote: >>> >>> Do you mean we should recommend the authors of draft-clemm-netmod-yang-= network-topo-00 to drop YANG and use XML schema languages instead? Their da= ta model is clearly outside the scope of device-oriented network management= - in fact, the very question whether the contents are config true or false= doesn't make much sense to me. >>> >>> What I had in mind with YANG 2.0 was a more generic data modelling lang= uage that could be used for such cases, too. A small "adaptation" document = could then provide specific info for a particular use or protocol. The resu= lt of this combination for NETCONF could be pretty much the same as RFC 602= 0. >>> >> I don't agree YANG 2.0 is needed at this time. >> I do not see why YANG can't be used to read/write configuration to a >> network manager that generates device configuration. I do not know >> whether this is the intention behind the I-D but ultimately I hope we >> start working at some point in time on _network_ management rather >> than just _device_ management. > Just implement a mid-level-manager and you have network management. There is nothing in NETCONF/YANG that says it can only be used by an NMS to manage an end-device. Write the code -- have the MLM talk to multiple southbound devices. Then you will have network management. I don't think the industry needs the IETF to do everything for them. I don't see any barriers preventing the IETF from standardizing network configuration. Write a draft if you think it is that important. > The fact of the matter is that YANG is used there as an XML schema langua= ge, unrelated to NETCONF. > This is incorrect. > I can imagine YANG to be a good candidate language for modelling the I2RS= data store, which by definition isn't NETCONF data store. > > On a practical side: YANG might be useful to people that have no idea abo= ut NETCONF and don't want to get any. For them, reading RFC 6020 would be a= n unnecessarily difficult and long exercise, with all the references to NET= CONF data stores, operations, server behaviour etc. > > Lada > >> >> /js >> Andy From bertietf@bwijnen.net Fri Aug 9 07:27:32 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D7D21F9957 for ; Fri, 9 Aug 2013 07:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.179 X-Spam-Level: X-Spam-Status: No, score=-102.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, 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 5AeERMxKFBvX for ; Fri, 9 Aug 2013 07:27:26 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBC021F8F4F for ; Fri, 9 Aug 2013 07:27:25 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V7nf1-0003KV-1q for netmod@ietf.org; Fri, 09 Aug 2013 16:27:25 +0200 Received: from kitten.ripe.net ([193.0.1.240] helo=guest137.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1V7nf0-0003li-Ux for netmod@ietf.org; Fri, 09 Aug 2013 16:27:23 +0200 Message-ID: <5204FC4C.8000508@bwijnen.net> Date: Fri, 09 Aug 2013 16:27:24 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: netmod Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130809 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4fc6822913297320e2aa81fef49d4fb75 Subject: [netmod] WG LC review of draft-ietf-netmod-system-mgmt-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 14:27:32 -0000 I did read and review document draft-ietf-netmod-system-mgmt-08.txt - With regard to the use of MD5, I wonder if the security considerations section should discuss and point to RFC6151 titled: "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms" - I see leaf name { type string; description "An arbitrary name for the DNS server."; } choice transport { mandatory true; description "The transport protocol specific parameters for this server."; case udp-and-tcp { container udp-and-tcp { description "Contains UDP and TCP specific configuration parameters for DNS."; reference "RFC 1035: Domain Implementation and Specification RFC 5966: DNS over TCP"; leaf address { type inet:ip-address; mandatory true; description "The address of the DNS server."; } leaf port { if-feature dns-udp-tcp-port; type inet:port-number; default 53; description "The UDP and TCP port number of the DNS server."; } } So it seems we are FORCING the tcp and udp port to be the same. I know that in reality this is often (always?) the case. But if you make it configurable, does it ALWAYS have to be the same port? I can live with it. Just wondering. - I see: container clock { description "Monitoring of the system date and time properties."; leaf current-datetime { type yang:date-and-time; config false; description "The current system date and time."; } leaf boot-datetime { type yang:date-and-time; config false; description "The system date and time when the system last restarted."; } } } why not make the container a "config: false" ??? I think nothing underneath this container will ever be config: true will it? - But maybe, since I see: container system-state { config false; description "System group operational state."; container platform { config false; description "Contains vendor-specific information for identifying the system platform and operating system."; reference "IEEE Std 1003.1-2008 - sys/utsname.h"; leaf os-name { type string; description ..... container clock { description "Monitoring of the system date and time properties."; leaf current-datetime { type yang:date-and-time; config false; description "The current system date and time."; } leaf boot-datetime { type yang:date-and-time; config false; description "The system date and time when the system last restarted."; } } } container clock is underneath container system-state and so the leafs current-datetime and boot-datetime are already config:false by inheriting from container system-state. Same for container platform I guess? Other than that, this document seems ready for publication as a stds track RFC. Bert From lhotka@nic.cz Fri Aug 9 07:45:07 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CC521F9FF2 for ; Fri, 9 Aug 2013 07:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.159, 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 eXENX5F5Xsos for ; Fri, 9 Aug 2013 07:45:06 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EC87A21E8055 for ; Fri, 9 Aug 2013 07:44:48 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id EF83F140179; Fri, 9 Aug 2013 16:44:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1376059488; bh=7a6Yf9Eyn2e60wwrCnItrW6G+i9oLuO89wZiyAvbt50=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=d0UY7IWdVNchyeAmiUPwIrpYdTJ9jHJStwm4hf0tRBm4Q/wfLBqdTQ7sODxFmlGtW aeVzzoNVMYzR1Vi/eNbdDrxYwNlt6NcUDRVvTdg2QF17kuz2BA+y12S6qrcxf3oxfS VPYH0DXY1bkwOZ99hDyKM+w0HhKUMD/4N46e40YA= 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: Fri, 9 Aug 2013 16:44:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <5204C7B5.8060706@ericsson.com> <20130809121057.GA13342@elstar.local> <47D65CBB-664F-4517-A601-D900DB4B9B9B@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 14:45:07 -0000 On Aug 9, 2013, at 4:11 PM, Andy Bierman wrote: > On Fri, Aug 9, 2013 at 6:16 AM, Ladislav Lhotka wrote: >=20 >=20 >> The fact of the matter is that YANG is used there as an XML schema = language, unrelated to NETCONF. >>=20 >=20 > This is incorrect. Why? It just models a single XML document without any special = relationship to NETCONF datastores, state data, RPCs or whatever. Tell = me a single aspect that goes beyond plain XML. During Jan's presentation in Berlin, Martin asked via Jabber: "Why did = you model this as configuration data?" And indeed, how can one decide = which part of the data is configuration and which is operational state = data? The answer actually must be "It depends." But this is important, = because several rules in YANG rely on the distinction between config = true and false nodes. Lada >=20 >> I can imagine YANG to be a good candidate language for modelling the = I2RS data store, which by definition isn't NETCONF data store. >>=20 >> On a practical side: YANG might be useful to people that have no idea = about NETCONF and don't want to get any. For them, reading RFC 6020 = would be an unnecessarily difficult and long exercise, with all the = references to NETCONF data stores, operations, server = behaviour etc. >>=20 >> Lada >>=20 >>>=20 >>> /js >>>=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Fri Aug 9 08:45:49 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD5421F8528 for ; Fri, 9 Aug 2013 08:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.681 X-Spam-Level: X-Spam-Status: No, score=-1.681 tagged_above=-999 required=5 tests=[AWL=-0.504, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 gwcKXtLF1EQP for ; Fri, 9 Aug 2013 08:45:44 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id A800611E81C3 for ; Fri, 9 Aug 2013 08:38:04 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl13so5018767pab.20 for ; Fri, 09 Aug 2013 08:38:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dPCNmDbANzWDSJ1Wk20woIwrgGx1BmZpUPW56evRG3c=; b=c5D8vC/6yvqxxchmJ4udJ8NRZbtEgacZFkN9ffEnFJgCSKEaqO75iZ3Wuv+xYmk97a G7oqEaIcpVsZYkTZK6QUkPFcgcAhOhWOcyW1NeSeqU2f2OxMazLFNnglMZbSUcZQAsBF 1O3FDMFBsE9dJGflImfoIn24bdQ9XpA9OpTnnFXaRNJC0gCKJKgTwSGxbD0vSwWFqwzK 4/iF76lvUEWsFNaHhEnlGUdi0OTDnaUTAEMZLtQElRzA246k52GRDZeamhSt6dSIWbiU hWC8u/+wpGLuwOisYBf4S3y5kr2WUUCu+vt/Ds9ewQA3/NC5+Ogpb/kH/D88235fUqpx chZw== X-Gm-Message-State: ALoCoQmpuMd5YoYNv5pxdlg4nOfu4+o3LanwfLIzv4BmwaOEhf5+Cy1aX15GyTv5MzYBFyMtj32Z MIME-Version: 1.0 X-Received: by 10.66.159.72 with SMTP id xa8mr12310931pab.38.1376062684338; Fri, 09 Aug 2013 08:38:04 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Fri, 9 Aug 2013 08:38:04 -0700 (PDT) In-Reply-To: References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <5204C7B5.8060706@ericsson.com> <20130809121057.GA13342@elstar.local> <47D65CBB-664F-4517-A601-D900DB4B9B9B@nic.cz> Date: Fri, 9 Aug 2013 08:38:04 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:45:49 -0000 On Fri, Aug 9, 2013 at 7:44 AM, Ladislav Lhotka wrote: > > On Aug 9, 2013, at 4:11 PM, Andy Bierman wrote: > >> On Fri, Aug 9, 2013 at 6:16 AM, Ladislav Lhotka wrote: >> >> >>> The fact of the matter is that YANG is used there as an XML schema lang= uage, unrelated to NETCONF. >>> >> >> This is incorrect. > > Why? It just models a single XML document without any special relationshi= p to NETCONF datastores, state data, RPCs or whatever. Tell me a single asp= ect that goes beyond plain XML. > I think a protocol mapping document (YANG for I2RS) could specify the relationship to NETCONF datastore concepts and new datastores. I like the 'dynamic' datastore that Juniper proposed awhile back for I2RS purposes. The NETCONF-specific aspects of YANG are not hard to map to other protocols. The concept of a running datastore (local config) is fairly universal. The and XPath context details can be ignored if those messages do not apply. The "dynamic" datastore is a stretch (wrt/ standard text) because YANG has datastore validation requirements that may get bypassed if fast-path edits do not use full validation. > During Jan's presentation in Berlin, Martin asked via Jabber: "Why did yo= u model this as configuration data?" And indeed, how can one decide which p= art of the data is configuration and which is operational state data? The a= nswer actually must be "It depends." But this is important, because several= rules in YANG rely on the distinction between config true and false nodes. > We don't have the right YANG meta-data to describe writable operational state. IMO, config=3Dfalse clearly means that no editing is allowed. Unfortunately, config=3Dtrue means "validate and persist as part of the running datastore" in NETCONF. A simple YANG extension to overwrite that property can fix that. The YANG RFC does not discuss the startup datastore. Any YANG-to-??? protocol mapping document needs to define how new datastores interact with the NETCONF datastores. > Lada Andy > >> >>> I can imagine YANG to be a good candidate language for modelling the I2= RS data store, which by definition isn't NETCONF data store. >>> >>> On a practical side: YANG might be useful to people that have no idea a= bout NETCONF and don't want to get any. For them, reading RFC 6020 would be= an unnecessarily difficult and long exercise, with all the references to N= ETCONF data stores, operations, server behaviour etc. >>> >>> Lada >>> >>>> >>>> /js >>>> >> >> Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From lhotka@nic.cz Fri Aug 9 09:35:57 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9BF21F9CBD for ; Fri, 9 Aug 2013 09:35:57 -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.448, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 Rka0Hu703jsz for ; Fri, 9 Aug 2013 09:35:57 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 919BB11E8144 for ; Fri, 9 Aug 2013 09:29:09 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9113D140179; Fri, 9 Aug 2013 18:29:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1376065748; bh=h0rPeu5ZTO6qzHWgRJhhZw26YnM85HkQulTrjS7IqFg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cHgkDHb7G4FsN8M5maqh0P8aYeIYrRfz/pnGNmicUl7YMti2nYf+816k6S+ZDb2gD WvBX3YH+F0INVw8ZezP2Z+QG/RGfLitmshqQSQsluzz8BOIqcH8GPg85ucvqShyW4c c7FUR7DElBPinbUjHWJB3fqQqxyunQ2LLQd5VU6M= 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: Fri, 9 Aug 2013 18:29:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <79E244C2-C910-4AB7-A6FA-BFEA5E373898@nic.cz> References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <5204C7B5.8060706@ericsson.com> <20130809121057.GA13342@elstar.local> <47D65CBB-664F-4517-A601-D900DB4B9B9B@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 16:35:57 -0000 X-List-Received-Date: Fri, 09 Aug 2013 16:35:57 -0000 On Aug 9, 2013, at 5:38 PM, Andy Bierman wrote: > On Fri, Aug 9, 2013 at 7:44 AM, Ladislav Lhotka wrote: >>=20 >> On Aug 9, 2013, at 4:11 PM, Andy Bierman wrote: >>=20 >>> On Fri, Aug 9, 2013 at 6:16 AM, Ladislav Lhotka = wrote: >>>=20 >>>=20 >>>> The fact of the matter is that YANG is used there as an XML schema = language, unrelated to NETCONF. >>>>=20 >>>=20 >>> This is incorrect. >>=20 >> Why? It just models a single XML document without any special = relationship to NETCONF datastores, state data, RPCs or whatever. Tell = me a single aspect that goes beyond plain XML. >>=20 >=20 > I think a protocol mapping document (YANG for I2RS) could specify > the relationship to NETCONF datastore concepts and new datastores. > I like the 'dynamic' datastore that Juniper proposed awhile back for > I2RS purposes. >=20 > The NETCONF-specific aspects of YANG are not hard to map > to other protocols. The concept of a running datastore (local config) Sometimes there even needn't be any protocol involved. > is fairly universal. The and XPath context = details > can be ignored if those messages do not apply. >=20 > The "dynamic" datastore is a stretch (wrt/ standard text) because > YANG has datastore validation requirements that may get bypassed > if fast-path edits do not use full validation. It would be possible to define various validation steps in a general = way, e.g., (i) grammar + data types and (ii) semantical rules, and then = state which of them are to be applied to a particular datastore. >=20 >> During Jan's presentation in Berlin, Martin asked via Jabber: "Why = did you model this as configuration data?" And indeed, how can one = decide which part of the data is configuration and which is operational = state data? The answer actually must be "It depends." But this is = important, because several rules in YANG rely on the distinction between = config true and false nodes. >>=20 >=20 > We don't have the right YANG meta-data to describe writable > operational state. Yup. >=20 > IMO, config=3Dfalse clearly means that no editing is allowed. > Unfortunately, config=3Dtrue means "validate and persist as part > of the running datastore" in NETCONF. A simple YANG > extension to overwrite that property can fix that. Hmm, how can you override the semantics of an existing YANG statement = with an extension? Isn't it the kind of extension that Martin warned = against? A much simpler approach would be to talk just in terms of RW and RO, and = specify special properties and behaviour of each datastore/protocol = where needed.=20 Lada >=20 > The YANG RFC does not discuss the startup datastore. > Any YANG-to-??? protocol mapping document needs to > define how new datastores interact with the NETCONF datastores. >=20 >=20 >> Lada >=20 > Andy >=20 >>=20 >>>=20 >>>> I can imagine YANG to be a good candidate language for modelling = the I2RS data store, which by definition isn't NETCONF data store. >>>>=20 >>>> On a practical side: YANG might be useful to people that have no = idea about NETCONF and don't want to get any. For them, reading RFC 6020 = would be an unnecessarily difficult and long exercise, with all the = references to NETCONF data stores, operations, server = behaviour etc. >>>>=20 >>>> Lada >>>>=20 >>>>>=20 >>>>> /js >>>>>=20 >>>=20 >>> Andy >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From balazs.lengyel@ericsson.com Fri Aug 9 09:59:38 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B7511E8132 for ; Fri, 9 Aug 2013 09:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.836 X-Spam-Level: X-Spam-Status: No, score=-4.836 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 JoawiYbM1sXC for ; Fri, 9 Aug 2013 09:59:32 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 559FE21F90AC for ; Fri, 9 Aug 2013 09:52:46 -0700 (PDT) X-AuditID: c1b4fb2d-b7f1c8e000000f62-5e-52051e5cd597 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 09.CE.03938.C5E15025; Fri, 9 Aug 2013 18:52:45 +0200 (CEST) Received: from [159.107.96.216] (153.88.183.147) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.2.328.9; Fri, 9 Aug 2013 18:52:44 +0200 Message-ID: <52051E5B.4080700@ericsson.com> Date: Fri, 9 Aug 2013 18:52:43 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ladislav Lhotka References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> <5204C7B5.8060706@ericsson.com> <20130809121057.GA13342@elstar.local> <47D65CBB-664F-4517-A601-D900DB4B9B9B@nic.cz> <79E244C2-C910-4AB7-A6FA-BFEA5E373898@nic.cz> In-Reply-To: <79E244C2-C910-4AB7-A6FA-BFEA5E373898@nic.cz> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+JvrW6sHGuQQetUNosHR2axW1xYNZfN Yv7FRlYHZo8lS34yeWy6fIfRo6X/IksAcxSXTUpqTmZZapG+XQJXxsdt69kLrrFWPL02hbGB 8RxLFyMnh4SAicTOJf/ZIWwxiQv31rN1MXJxCAkcZpR4tXcCE4SzmlGi4foKZpAqXgFtiefd B8BsFgEVia4751hBbDYBI4mp/efBpooKREls2H6BBaJeUOLkzCdgtoiAssTFCT/BbGYBC4l9 z46D2cICBhJ3Xh1gh1g2lU1i5aonYEM5Bawkln5ZwATRYCtxYc51qGZ5ie1v54AdISSgIfHw wl/WCYyCs5Dsm4WkZRaSlgWMzKsY2XMTM3PSyw03MQJD9eCW37o7GE+dEznEKM3BoiTOu0nv TKCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRvvZYonBWrM8v3e2bex3usWbx994a9vd+6e/ z/4otlvm7/XfK89yR64/I7Y+d2mCb9Zmg0RJqa3BhokT1m2Q3XJO4PFWDWW2ew7c9y5fnSb6 xHJ99o+tlyp1/6+6b9FXsobr/vsSl3rjQy8MHrxbJXxV5PLSPtbl6xNXzWb8fTDRK/7rwxql flclluKMREMt5qLiRAAvV98dIwIAAA== Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 16:59:39 -0000 > IMO, config=false clearly means that no editing is allowed. > Unfortunately, config=true means "validate and persist as part > of the running datastore" in NETCONF. A simple YANG > extension to overwrite that property can fix that. > Hmm, how can you override the semantics of an existing YANG statement with an extension? Isn't it the kind of extension that Martin warned against? > > A much simpler approach would be to talk just in terms of RW and RO, and specify special properties and behaviour of each datastore/protocol where needed. > > Lada IMHO it was a mistake to combine two concepts writability and persistence in the single config=true/false statement. So I very much like your comment. Balazs From jmedved@cisco.com Fri Aug 9 10:01:37 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FF621F977A for ; Fri, 9 Aug 2013 10:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 JEkzaOlfHjAC for ; Fri, 9 Aug 2013 10:01:32 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A92FB21F90DC for ; Fri, 9 Aug 2013 09:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=925; q=dns/txt; s=iport; t=1376067339; x=1377276939; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/lrYkN8VibYnWKoPqJSz5mK4ReN7BBJV2hULhGbuPM8=; b=kb+2j5KXRTOOPkuRl5lk4qzKLM9LlcZT7UNo7DAvSVFtmslhNxuoU0It 66srSKeiQtGXfqKLgIg5QrEcRNAmXS5GGN/trXBJOiuFS3OlvTox8d6ae URvEzTxKWdOaG+U8gIFuehs+MRVWkA80m6fywa00JJkzoaRkWpgKtQrQf I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0FAP8dBVKtJV2Z/2dsb2JhbABbgwaBBYJMvAWBGhZ0giYBBDo/EgEIIhRCJQIEAQ0FCIgIuUSQATEHgxp1A6kxgxuCKg X-IronPort-AV: E=Sophos;i="4.89,846,1367971200"; d="scan'208";a="245556408" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 09 Aug 2013 16:55:39 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r79GtduH011443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 16:55:39 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.158]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 11:55:39 -0500 From: "Jan Medved (jmedved)" To: Ladislav Lhotka , Andy Bierman Thread-Topic: [netmod] [Netconf] development plan Thread-Index: AQHOlO1FHmUWxYGkdUmeRGSMbjsllJmNDEkAgAAQsQCAABIxgIAAD46AgAAJOoCAAA7jAIAADkUA//+SDwA= Date: Fri, 9 Aug 2013 16:55:38 +0000 Message-ID: In-Reply-To: <79E244C2-C910-4AB7-A6FA-BFEA5E373898@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.27.7.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <97EADE107083D74192D09621F50BBDFD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:01:37 -0000 [Snip] On 8/9/13 9:29 AM, "Ladislav Lhotka" wrote: >>>During Jan's presentation in Berlin, Martin asked via Jabber: "Why did >>>you model this as configuration data?" And indeed, how can one decide >>>which part of the data is configuration and which is operational state >>>data? The answer actually must be "It depends." But this is important, >>>because several rules in YANG rely on the distinction between config >>>true and false nodes. >>We don't have the right YANG meta-data to describe writable >>operational state. > >Yup. > +1.=20 The topology model described in the draft is a relatively easy use case - it's read-only, so it can be (and should have been :-)) modeled as operational data.=20 But we need to model any kind of service services, which in general can be read-write and writes could be either ephemeral or persistent (config). [snip] Thanks, Jan From mbj@tail-f.com Fri Aug 9 10:14:07 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC5D11E8130 for ; Fri, 9 Aug 2013 10:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 zclRmP-qEylc for ; Fri, 9 Aug 2013 10:14:01 -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 3B5DE11E810D for ; Fri, 9 Aug 2013 10:08:13 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id C1EBA1200287; Fri, 9 Aug 2013 19:08:10 +0200 (CEST) Date: Fri, 09 Aug 2013 19:08:10 +0200 (CEST) Message-Id: <20130809.190810.157037284.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <79E244C2-C910-4AB7-A6FA-BFEA5E373898@nic.cz> References: <79E244C2-C910-4AB7-A6FA-BFEA5E373898@nic.cz> 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: netmod@ietf.org Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:14:07 -0000 Ladislav Lhotka wrote: > > On Aug 9, 2013, at 5:38 PM, Andy Bierman wrote: > > IMO, config=false clearly means that no editing is allowed. I disagree. (but maybe we mean the same thing anyway). config false means that the data node is not part of any configuration datastore. Since NETCONF just has two classes, config and state, and currently the only standard operations to modify anything are edit-config and copy-config, which are used to modify the configuration datastores, it follows that you cannot edit a config false node with these two operations. But nothing prevents us from defining a new edit-operational operation, for example. Or special rpcs to modify say a routing table. So in this sense config false does not mean that the node is strictly read-only. > > Unfortunately, config=true means "validate and persist as part > > of the running datastore" in NETCONF. A simple YANG > > extension to overwrite that property can fix that. > > Hmm, how can you override the semantics of an existing YANG statement > with an extension? Isn't it the kind of extension that Martin warned > against? No, since you do not override the existing semantics. A config false node with an extension "writable-operational" is still not part of the configuration datastores. Old clients can still communicate properly with new servers. > A much simpler approach would be to talk just in terms of RW and RO, > and specify special properties and behaviour of each > datastore/protocol where needed. I strongly disagree. config true is (obviously) very specific to configuration management, but this is one thing that makes NETCONF / YANG different compared to other solutions. /martin From andy@yumaworks.com Fri Aug 9 10:17:29 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF0621F9D39 for ; Fri, 9 Aug 2013 10:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.471 X-Spam-Level: X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=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 43bN-LNClhIc for ; Fri, 9 Aug 2013 10:17:24 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 815E111E8127 for ; Fri, 9 Aug 2013 10:13:04 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so802862pdj.12 for ; Fri, 09 Aug 2013 10:13:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0/MTnXqPicnSYDVQrXscdp3XLvP853W/inhxqAhlbFw=; b=oIc4ijgF26aTNbOla2hJMGOAzyTzxJF1DCKCDwIaP8PvOjkkiDwEI1ytfHE+R1vmHu LfJPH4pl3inqsqzmOKUZVSu6yRvv3wxaDZI5alZKPXSEr2BAj+d5PUAMLiB8hR7JA6A5 +cs6utS0ZBdRZparMfjj6gLsiR0pCA4uHx8MzLd9mRO5gqp25byR/5jI7c1YzWCniAY3 ny4FoMoBCQnHZV1F2aPn+uf3eJwxdeWMbkp1cNJsuAVA/pxuzgxJCt4ka0WhwLgK377R GNdmAzMNwDFL/g5sg6cA2b+nZez05o61+ZPca5qmooy1p4D3bXDIsXq9uMCH5pQNBDtV tnIQ== X-Gm-Message-State: ALoCoQkSj+y4IF3jWIWLnv734vVZZLnC+8LFREbixwlTinjHb3fLRCfnGz3Hp68dXn9wtWZ+Lv1g MIME-Version: 1.0 X-Received: by 10.68.19.162 with SMTP id g2mr12419421pbe.140.1376068384160; Fri, 09 Aug 2013 10:13:04 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Fri, 9 Aug 2013 10:13:04 -0700 (PDT) In-Reply-To: <20130809.190810.157037284.mbj@tail-f.com> References: <79E244C2-C910-4AB7-A6FA-BFEA5E373898@nic.cz> <20130809.190810.157037284.mbj@tail-f.com> Date: Fri, 9 Aug 2013 10:13:04 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] development plan X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:17:29 -0000 On Fri, Aug 9, 2013 at 10:08 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> >> On Aug 9, 2013, at 5:38 PM, Andy Bierman wrote: >> > IMO, config=false clearly means that no editing is allowed. > > I disagree. (but maybe we mean the same thing anyway). config false > means that the data node is not part of any configuration datastore. > Since NETCONF just has two classes, config and state, and currently > the only standard operations to modify anything are edit-config and > copy-config, which are used to modify the configuration datastores, it > follows that you cannot edit a config false node with these two > operations. But nothing prevents us from defining a new > edit-operational operation, for example. Or special rpcs to modify > say a routing table. So in this sense config false does not mean that > the node is strictly read-only. > I agree this is a better description of config=false. >> > Unfortunately, config=true means "validate and persist as part >> > of the running datastore" in NETCONF. A simple YANG >> > extension to overwrite that property can fix that. >> >> Hmm, how can you override the semantics of an existing YANG statement >> with an extension? Isn't it the kind of extension that Martin warned >> against? > > No, since you do not override the existing semantics. A config false > node with an extension "writable-operational" is still not part of the > configuration datastores. Old clients can still communicate properly > with new servers. > >> A much simpler approach would be to talk just in terms of RW and RO, >> and specify special properties and behaviour of each >> datastore/protocol where needed. > > I strongly disagree. config true is (obviously) very specific to > configuration management, but this is one thing that makes NETCONF / > YANG different compared to other solutions. > +1 > > /martin Andy From bertietf@bwijnen.net Mon Aug 12 13:05:37 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E4821F9F85 for ; Mon, 12 Aug 2013 13:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 4sruQWvU9bSE for ; Mon, 12 Aug 2013 13:05:31 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id E5D3221F9F44 for ; Mon, 12 Aug 2013 13:05:27 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V8yMm-0004e7-P0 for netmod@ietf.org; Mon, 12 Aug 2013 22:05:26 +0200 Received: from kitten.ripe.net ([193.0.1.240] helo=[IPv6:::1]) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1V8yMm-0003sb-J7 for netmod@ietf.org; Mon, 12 Aug 2013 22:05:24 +0200 Message-ID: <52094005.1070209@bwijnen.net> Date: Mon, 12 Aug 2013 22:05:25 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: NETMOD Working Group References: <5204FC4C.8000508@bwijnen.net> In-Reply-To: <5204FC4C.8000508@bwijnen.net> X-Forwarded-Message-Id: <5204FC4C.8000508@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130812 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd466cb61883b7ab779ccfce37282bb38d9 Subject: [netmod] WG LC review of draft-ietf-netmod-iana-if-type-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 20:05:37 -0000 I did read and review document draft-ietf-netmod-iana-if-type-07.txt This document seems ready for publication as a stds track RFC. Bert From bertietf@bwijnen.net Mon Aug 12 14:06:10 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A191811E80D2 for ; Mon, 12 Aug 2013 14:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 JjijuJ51MfFo for ; Mon, 12 Aug 2013 14:05:54 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id C4A5E21F93BA for ; Mon, 12 Aug 2013 14:05:54 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V8zJH-0007Pk-Ja for netmod@ietf.org; Mon, 12 Aug 2013 23:05:53 +0200 Received: from kitten.ripe.net ([193.0.1.240] helo=[IPv6:::1]) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1V8zJH-0004WT-GO for netmod@ietf.org; Mon, 12 Aug 2013 23:05:51 +0200 Message-ID: <52094E30.5060409@bwijnen.net> Date: Mon, 12 Aug 2013 23:05:52 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: NETMOD Working Group References: <52094005.1070209@bwijnen.net> In-Reply-To: <52094005.1070209@bwijnen.net> X-Forwarded-Message-Id: <52094005.1070209@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130812 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd43be7897df9a2c282bdb75997407bdc92 Subject: [netmod] WG LC review of draft-ietf-netmod-interfaces-cfg-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 21:06:11 -0000 I did read and review document draft-ietf-netmod-iana-if-type-07.txt I believe that this document is ready for publication as a stds track RFC. Bert From mbj@tail-f.com Mon Aug 12 23:42:14 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C20211E80D5 for ; Mon, 12 Aug 2013 23:42:14 -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 R4e21dr5TtDS for ; Mon, 12 Aug 2013 23:42:07 -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 355AC11E80C5 for ; Mon, 12 Aug 2013 23:42:03 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6DC2F1200089; Tue, 13 Aug 2013 08:42:01 +0200 (CEST) Date: Tue, 13 Aug 2013 08:42:01 +0200 (CEST) Message-Id: <20130813.084201.1094250650394735040.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <5204FC4C.8000508@bwijnen.net> References: <5204FC4C.8000508@bwijnen.net> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] WG LC review of draft-ietf-netmod-system-mgmt-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 06:42:14 -0000 Hi, "Bert Wijnen (IETF)" wrote: > I did read and review document draft-ietf-netmod-system-mgmt-08.txt > > > - With regard to the use of MD5, I wonder if the security > considerations section should discuss and point to RFC6151 > titled: "Updated Security Considerations for the MD5 > Message-Digest and the HMAC-MD5 Algorithms" I don't know. Should it? > - I see > leaf name { > type string; > description > "An arbitrary name for the DNS server."; > } > choice transport { > mandatory true; > description > "The transport protocol specific parameters for this > server."; > > case udp-and-tcp { > container udp-and-tcp { > description > "Contains UDP and TCP specific configuration > parameters for DNS."; > reference > "RFC 1035: Domain Implementation and Specification > RFC 5966: DNS over TCP"; > > leaf address { > type inet:ip-address; > mandatory true; > description > "The address of the DNS server."; > } > leaf port { > if-feature dns-udp-tcp-port; > type inet:port-number; > default 53; > description > "The UDP and TCP port number of the DNS server."; > } > } > > So it seems we are FORCING the tcp and udp port to be the same. Yes. I had an (off-line) discussion with Lars-Johan Liman and he suggested that a single port would be enough (and even good). Does anyone know any resolver implementations that support configuration of different ports? (It seems that most implementations even hardcode port 53...). > I know that in reality this is often (always?) the case. But if you > make it configurable, does it ALWAYS have to be the same port? > > I can live with it. Just wondering. > > - I see: > container clock { > description > "Monitoring of the system > date and time properties."; > > leaf current-datetime { > type yang:date-and-time; > config false; > description > "The current system date and time."; > } > leaf boot-datetime { > type yang:date-and-time; > config false; > description > "The system date and time when the system last restarted."; > } > } > > } > > why not make the container a "config: false" ??? > I think nothing underneath this container will ever be config: true > will it? Correct. Actually, since the container 'system-state' is config false, we don't need these other config false statements. They are left-overs from previous versions. /martin From ietfdbh@comcast.net Tue Aug 13 00:21:24 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C536821E80DA for ; Tue, 13 Aug 2013 00:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[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 3YCeZGWrWj+k for ; Tue, 13 Aug 2013 00:21:11 -0700 (PDT) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:48]) by ietfa.amsl.com (Postfix) with ESMTP id A34A421E80D8 for ; Tue, 13 Aug 2013 00:21:11 -0700 (PDT) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta05.emeryville.ca.mail.comcast.net with comcast id C7MA1m0010S2fkCA57MANY; Tue, 13 Aug 2013 07:21:10 +0000 Received: from [10.121.18.215] ([195.50.158.227]) by omta09.emeryville.ca.mail.comcast.net with comcast id C7Lr1m00C4ufcbF8V7Lw4D; Tue, 13 Aug 2013 07:21:08 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Tue, 13 Aug 2013 09:20:50 +0200 From: David Harrington To: Martin Bjorklund , Message-ID: Thread-Topic: [netmod] WG LC review of draft-ietf-netmod-system-mgmt-08.txt In-Reply-To: <20130813.084201.1094250650394735040.mbj@tail-f.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=1376378470; bh=SQk26TIY41iOIzRJ+Wg9EMYpYXFcanfAmRB98/JlwQs=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=Mc1ihbGcZcxhVYX+5m5BUdtVA4Q3Tsx09Yhzo3T7f3MK+VCtskjczGbl+u0P3OeM8 xEK7QHwaOM/0CAtN2uB5SBbNZmVeVUCxx7X2feJxpuLQbSt+C9kUcI09+I5aK3iJi0 Ym1bh+9Gem/9xVu1WguRIG36VTnSVqt81Z9//qI38buf9Wi69R1XRJkzgrkrt3PC4G 7tn2xxzIQ8A6rsgzLlDmtWWOmtnioR+rXYozmqej3jjmWFOhFV/e6CbyIKvVytZ0An CaEzDWpXjtJgxkDLI3+R1HFUW0km4/jJJxVTu0/EsTF9WkjXK1hx6PpxQks57l/z1k jmiX7e6d33lsA== Cc: netmod@ietf.org Subject: Re: [netmod] WG LC review of draft-ietf-netmod-system-mgmt-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 07:21:24 -0000 >> >> So it seems we are FORCING the tcp and udp port to be the same. > >Yes. I had an (off-line) discussion with Lars-Johan Liman and he >suggested that a single port would be enough (and even good). Good as an implementer engineering choice, or good as a standards requirement? >Does >anyone know any resolver implementations that support configuration of >different ports? (It seems that most implementations even hardcode >port 53...). > I have a concern that forcing the tcp and udp port to be the same could cause you DISCUSSES when this goes through IESG. I suggest asking for a dnsdir review; I think that falls under INT ADs. You might also ask for tsvdir review; ask Martin and Spencer to initiate this. One hurdle you may have to get over is Joe Touch, the port assignment expert used by IANA during IANA review. He sometimes raises points of contention that are not supported by the ADs, but can really tie up the process. Getting the ADs involved early can help prevent that. > > >-- >David Harrington >Ietfdbh@comcast.net >+1-603-828-1401 > > From bertietf@bwijnen.net Tue Aug 13 00:21:30 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F0121E80D1 for ; Tue, 13 Aug 2013 00:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 qmQc2ilyshlj for ; Tue, 13 Aug 2013 00:21:24 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 4268921F9EE1 for ; Tue, 13 Aug 2013 00:21:16 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V98un-0004EX-3k; Tue, 13 Aug 2013 09:21:15 +0200 Received: from kitten.ripe.net ([193.0.1.240] helo=[IPv6:::1]) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1V98un-00046p-0u; Tue, 13 Aug 2013 09:21:13 +0200 Message-ID: <5209DE68.8040801@bwijnen.net> Date: Tue, 13 Aug 2013 09:21:12 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Martin Bjorklund References: <5204FC4C.8000508@bwijnen.net> <20130813.084201.1094250650394735040.mbj@tail-f.com> In-Reply-To: <20130813.084201.1094250650394735040.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130813 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4a38f652226de99a1e186b1a14a03b304 Cc: netmod@ietf.org Subject: Re: [netmod] WG LC review of draft-ietf-netmod-system-mgmt-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 07:21:30 -0000 Inline On 8/13/13 8:42 AM, Martin Bjorklund wrote: > "Bert Wijnen (IETF)" wrote: >> >I did read and review document draft-ietf-netmod-system-mgmt-08.txt >> > >> > >> >- With regard to the use of MD5, I wonder if the security >> > considerations section should discuss and point to RFC6151 >> > titled: "Updated Security Considerations for the MD5 >> > Message-Digest and the HMAC-MD5 Algorithms" > I don't know. Should it? > Well, that document states that MD5 should not be used anymore, does it not? So a warning (in my view) makes sense. Not that I will loose sleep over it if we do not do that. Could ask Sec ADs as to what they think. Or just see if they bring it up in IESG review. Bert From lhotka@nic.cz Tue Aug 13 00:58:04 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4590621E80C5 for ; Tue, 13 Aug 2013 00:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 41RKOjN5cRHC for ; Tue, 13 Aug 2013 00:58:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2248021E8097 for ; Tue, 13 Aug 2013 00:58:02 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 685E513FB63; Tue, 13 Aug 2013 09:58:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1376380680; bh=cUZeHFAnGMnbkJNYeQMYyHTugy9ZEEIyb7AvPMs/0hk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=K8hkAptEi0/outAZ1ZztmESv+NvGWxkJkPJO1I/RTZ6TuVVib9/8WvV8aJgm6IkBH C+XWwLkFDLq0zzkTCrIzYVUWdqJs1MIjiYW9/JLbbwKGR33lHkvDtFJN9QNIkuY/2Y b3X4sWHfdFpmTLbKipuMf2C7x+X4V6PGq59eC24U= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130813.084201.1094250650394735040.mbj@tail-f.com> Date: Tue, 13 Aug 2013 09:57:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E54E520-C6C6-4153-922B-25E368471FA2@nic.cz> References: <5204FC4C.8000508@bwijnen.net> <20130813.084201.1094250650394735040.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] WG LC review of draft-ietf-netmod-system-mgmt-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 07:58:04 -0000 On Aug 13, 2013, at 8:42 AM, Martin Bjorklund wrote: > Hi, >=20 > "Bert Wijnen (IETF)" wrote: >> I did read and review document draft-ietf-netmod-system-mgmt-08.txt >>=20 >>=20 >> - With regard to the use of MD5, I wonder if the security >> considerations section should discuss and point to RFC6151 >> titled: "Updated Security Considerations for the MD5 >> Message-Digest and the HMAC-MD5 Algorithms" >=20 > I don't know. Should it? >=20 >> - I see >> leaf name { >> type string; >> description >> "An arbitrary name for the DNS server."; >> } >> choice transport { >> mandatory true; >> description >> "The transport protocol specific parameters for this >> server."; >>=20 >> case udp-and-tcp { >> container udp-and-tcp { >> description >> "Contains UDP and TCP specific configuration >> parameters for DNS."; >> reference >> "RFC 1035: Domain Implementation and Specification >> RFC 5966: DNS over TCP"; >>=20 >> leaf address { >> type inet:ip-address; >> mandatory true; >> description >> "The address of the DNS server."; >> } >> leaf port { >> if-feature dns-udp-tcp-port; >> type inet:port-number; >> default 53; >> description >> "The UDP and TCP port number of the DNS server."; >> } >> } >>=20 >> So it seems we are FORCING the tcp and udp port to be the same. >=20 > Yes. I had an (off-line) discussion with Lars-Johan Liman and he > suggested that a single port would be enough (and even good). Does > anyone know any resolver implementations that support configuration of > different ports? (It seems that most implementations even hardcode > port 53=85). RFC 1035: Messages sent using UDP [use] server port 53 (decimal). Messages sent over TCP connections use server port 53 (decimal). As I wrote earlier, the chance that a stub resolver (which is our case = here) will ever uses any other transport protocol is also very slim. So = this part of the module is IMO way too complicated - server address and = optional port should be more than enough. Lada >=20 >> I know that in reality this is often (always?) the case. But if you >> make it configurable, does it ALWAYS have to be the same port? >>=20 >> I can live with it. Just wondering. >>=20 >> - I see: >> container clock { >> description >> "Monitoring of the system >> date and time properties."; >>=20 >> leaf current-datetime { >> type yang:date-and-time; >> config false; >> description >> "The current system date and time."; >> } >> leaf boot-datetime { >> type yang:date-and-time; >> config false; >> description >> "The system date and time when the system last = restarted."; >> } >> } >>=20 >> } >>=20 >> why not make the container a "config: false" ??? >> I think nothing underneath this container will ever be config: true >> will it? >=20 > Correct. Actually, since the container 'system-state' is config > false, we don't need these other config false statements. They are > left-overs from previous versions. >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Aug 13 03:42:51 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB4B21E80E1 for ; Tue, 13 Aug 2013 03:42:49 -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 OZJWbDc9v6rd for ; Tue, 13 Aug 2013 03:42:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A1BD721E8097 for ; Tue, 13 Aug 2013 03:42:44 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E29EE2095C; Tue, 13 Aug 2013 12:42:42 +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 zFkO1yrK4yK5; Tue, 13 Aug 2013 12:42:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E532520746; Tue, 13 Aug 2013 12:42:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E276627DB03A; Tue, 13 Aug 2013 12:42:34 +0200 (CEST) Date: Tue, 13 Aug 2013 12:42:34 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20130813104234.GA85649@elstar.local> Mail-Followup-To: David Harrington , Martin Bjorklund , bertietf@bwijnen.net, netmod@ietf.org References: <20130813.084201.1094250650394735040.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] WG LC review of draft-ietf-netmod-system-mgmt-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 10:42:51 -0000 On Tue, Aug 13, 2013 at 09:20:50AM +0200, David Harrington wrote: > > > > >> > >> So it seems we are FORCING the tcp and udp port to be the same. > > > >Yes. I had an (off-line) discussion with Lars-Johan Liman and he > >suggested that a single port would be enough (and even good). > > Good as an implementer engineering choice, or good as a standards > requirement? > > >Does > >anyone know any resolver implementations that support configuration of > >different ports? (It seems that most implementations even hardcode > >port 53...). > > > > I have a concern that forcing the tcp and udp port to be the same could > cause you DISCUSSES when this goes through IESG. My understanding is that if DNS signals an upgrade to a 'virtual circuit' (yeah those were the times) through a truncated message, it does not carry any further information so the only best guess a client can make is to use the same port number over TCP. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Aug 13 03:45:31 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D9821E8097 for ; Tue, 13 Aug 2013 03:45:31 -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 hZRJ4U6CC-uv for ; Tue, 13 Aug 2013 03:45:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BC02221E80F9 for ; Tue, 13 Aug 2013 03:45:26 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1389020AFE; Tue, 13 Aug 2013 12:45:26 +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 krDMRtBotAT8; Tue, 13 Aug 2013 12:45:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C12020968; Tue, 13 Aug 2013 12:45:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B123027DB091; Tue, 13 Aug 2013 12:45:20 +0200 (CEST) Date: Tue, 13 Aug 2013 12:45:20 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20130813104520.GB85649@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , Martin Bjorklund , netmod@ietf.org References: <5204FC4C.8000508@bwijnen.net> <20130813.084201.1094250650394735040.mbj@tail-f.com> <5209DE68.8040801@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5209DE68.8040801@bwijnen.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] WG LC review of draft-ietf-netmod-system-mgmt-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 10:45:32 -0000 On Tue, Aug 13, 2013 at 09:21:12AM +0200, Bert Wijnen (IETF) wrote: > Inline > > On 8/13/13 8:42 AM, Martin Bjorklund wrote: > >"Bert Wijnen (IETF)" wrote: > >>>I did read and review document draft-ietf-netmod-system-mgmt-08.txt > >>> > >>> > >>>- With regard to the use of MD5, I wonder if the security > >>> considerations section should discuss and point to RFC6151 > >>> titled: "Updated Security Considerations for the MD5 > >>> Message-Digest and the HMAC-MD5 Algorithms" > >I don't know. Should it? > > > > Well, that document states that MD5 should not be used anymore, does it not? > So a warning (in my view) makes sense. > > Not that I will loose sleep over it if we do not do that. > Could ask Sec ADs as to what they think. > Or just see if they bring it up in IESG review. It won't hurt but since we are modeling how a system stores password hashes, the real-world impact will also be small - an implementor of the system management data model is likely having little influence over the policies used to store password hashes. But then, constant repetition is sometimes the key to learning - so it won't hurt. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Tue Aug 13 04:01:41 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3634811E8131 for ; Tue, 13 Aug 2013 04:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 BSPEGq333ujO for ; Tue, 13 Aug 2013 04:01:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 830ED11E8102 for ; Tue, 13 Aug 2013 04:01:39 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7799F13FB63; Tue, 13 Aug 2013 13:01:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1376391695; bh=bss3CG3kN++rDLYgUjIHgpwecbrvXogSKf2Xk+0cWpc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hj9OIvway2jLWv3dF+H/Qfk87lz5kOc+CrUEDjQb7gKJj9rx+Tza1j1Jkg5X5cf/N NzOn/EIoRn8Ki7H9c0JZAw0pUrUmqx65O9q60lPn8TgENn5Ip+q3qhgnLIjfkBy7tt C2udzDpcANP3qoN4Xeob+jEd6W6wm8wdtaOsWF38= 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: Tue, 13 Aug 2013 13:01:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: David Harrington X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] WG LC review of draft-ietf-netmod-system-mgmt-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 11:01:41 -0000 On Aug 13, 2013, at 9:20 AM, David Harrington = wrote: >=20 >=20 >=20 >>>=20 >>> So it seems we are FORCING the tcp and udp port to be the same. >>=20 >> Yes. I had an (off-line) discussion with Lars-Johan Liman and he >> suggested that a single port would be enough (and even good). >=20 > Good as an implementer engineering choice, or good as a standards > requirement? >=20 >> Does >> anyone know any resolver implementations that support configuration = of >> different ports? (It seems that most implementations even hardcode >> port 53...). >>=20 >=20 > I have a concern that forcing the tcp and udp port to be the same = could > cause you DISCUSSES when this goes through IESG. I am pretty sure that a simple list of DNS server addresses (perhaps = with optional port) will not cause any DISCUSSes, because this is = (AFAIK) the maximum of what current implementations of stub resolvers = allow. It is the purportedly sophisticated choice of the transport = protocol for DNS that may raise eyebrows of reviewers. Lada >=20 > I suggest asking for a dnsdir review; I think that falls under INT = ADs. > You might also ask for tsvdir review; ask Martin and Spencer to = initiate > this. >=20 > One hurdle you may have to get over is Joe Touch, the port assignment > expert used by IANA during IANA review. > He sometimes raises points of contention that are not supported by the > ADs, but can really tie up the process. > Getting the ADs involved early can help prevent that. >=20 >>=20 >>=20 >> -- >> David Harrington >> Ietfdbh@comcast.net >> +1-603-828-1401 >>=20 >>=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Tue Aug 13 04:15:20 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A94921F860B for ; Tue, 13 Aug 2013 04:15:20 -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 kq3VpWq5UpZV for ; Tue, 13 Aug 2013 04:15:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 976F421F857A for ; Tue, 13 Aug 2013 04:14:18 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C26BF20BD5; Tue, 13 Aug 2013 13:14:16 +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 2hsr2BzbadpC; Tue, 13 Aug 2013 13:14: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 508E620BCD; Tue, 13 Aug 2013 13:14:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6A35D27DB411; Tue, 13 Aug 2013 13:14:10 +0200 (CEST) Date: Tue, 13 Aug 2013 13:14:09 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20130813111408.GA85867@elstar.local> Mail-Followup-To: Ladislav Lhotka , David Harrington , netmod@ietf.org 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: netmod@ietf.org Subject: Re: [netmod] WG LC review of draft-ietf-netmod-system-mgmt-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 11:15:20 -0000 On Tue, Aug 13, 2013 at 01:01:35PM +0200, Ladislav Lhotka wrote: > > On Aug 13, 2013, at 9:20 AM, David Harrington wrote: > > > > > > > > >>> > >>> So it seems we are FORCING the tcp and udp port to be the same. > >> > >> Yes. I had an (off-line) discussion with Lars-Johan Liman and he > >> suggested that a single port would be enough (and even good). > > > > Good as an implementer engineering choice, or good as a standards > > requirement? > > > >> Does > >> anyone know any resolver implementations that support configuration of > >> different ports? (It seems that most implementations even hardcode > >> port 53...). > >> > > > > I have a concern that forcing the tcp and udp port to be the same could > > cause you DISCUSSES when this goes through IESG. > > I am pretty sure that a simple list of DNS server addresses (perhaps with optional port) will not cause any DISCUSSes, because this is (AFAIK) the maximum of what current implementations of stub resolvers allow. It is the purportedly sophisticated choice of the transport protocol for DNS that may raise eyebrows of reviewers. > Speculating about IESG DISCUSSES is IMHO a mood activity. Yes, there are zero-cost provisions to be able to support other transports and I think this is architecturally the right thing to do. We follow a common architectural pattern for all the transports in this module and I believe this is goodness. Lets face it, people will take these modules as templates and I think we will be better off providing proper templates. And as I said, the cost of the extra XML element is zero. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Tue Aug 13 05:49:04 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D527F21E8141 for ; Tue, 13 Aug 2013 05:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 KmvRVibYDGzV for ; Tue, 13 Aug 2013 05:49: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 D187021E813E for ; Tue, 13 Aug 2013 05:49:03 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id B183713FA0F; Tue, 13 Aug 2013 14:49:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1376398141; bh=o/vQtZEImFrt458f8XpN5RuRUDyEHJBk0UiASGzWR5U=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Y1c7+/a5njQYiCfpHH23Mk5z3YzCFo0zPGhDBeIAMuUz8en2wW2NW9Utvgdrf1Nio NMvea+kkCVbBCyFdzH/IPGhbTElTXRcMSSHItgbwa55r2JBuYddydB+mLuHqQx0K3a hrABddIu8YyQSSbiiCz5U9Pba/vYSJVhGU+ES70E= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130813111408.GA85867@elstar.local> Date: Tue, 13 Aug 2013 14:49:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6AEBF147-461C-420B-82AA-EC0D3122F24D@nic.cz> References: <20130813111408.GA85867@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] WG LC review of draft-ietf-netmod-system-mgmt-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 12:49:04 -0000 On Aug 13, 2013, at 1:14 PM, Juergen Schoenwaelder = wrote: > On Tue, Aug 13, 2013 at 01:01:35PM +0200, Ladislav Lhotka wrote: >>=20 >> On Aug 13, 2013, at 9:20 AM, David Harrington = wrote: >>=20 >>>=20 >>>=20 >>>=20 >>>>>=20 >>>>> So it seems we are FORCING the tcp and udp port to be the same. >>>>=20 >>>> Yes. I had an (off-line) discussion with Lars-Johan Liman and he >>>> suggested that a single port would be enough (and even good). >>>=20 >>> Good as an implementer engineering choice, or good as a standards >>> requirement? >>>=20 >>>> Does >>>> anyone know any resolver implementations that support configuration = of >>>> different ports? (It seems that most implementations even hardcode >>>> port 53...). >>>>=20 >>>=20 >>> I have a concern that forcing the tcp and udp port to be the same = could >>> cause you DISCUSSES when this goes through IESG. >>=20 >> I am pretty sure that a simple list of DNS server addresses (perhaps = with optional port) will not cause any DISCUSSes, because this is = (AFAIK) the maximum of what current implementations of stub resolvers = allow. It is the purportedly sophisticated choice of the transport = protocol for DNS that may raise eyebrows of reviewers. >>=20 >=20 > Speculating about IESG DISCUSSES is IMHO a mood activity. Yes, there > are zero-cost provisions to be able to support other transports and I > think this is architecturally the right thing to do. We follow a > common architectural pattern for all the transports in this module and > I believe this is goodness. I don't agree, it goes against the Occam's Razor principle. A choice of = transport protocols should be available only where the service or = protocol spec supports it, or where there are at least indications that = it may be so in the future. Apart from DNS, I believe NTP is another example where it does NOT make = sense, because anything else than UDP would increase latency. RFC 5905: = "The NTP packet is a UDP datagram". Full stop. >=20 > Lets face it, people will take these modules as templates and I think > we will be better off providing proper templates. And as I said, the > cost of the extra XML element is zero. The significant cost is not in an extra XML element but rather in = decreased readability of the data model, without any apparent gain. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Aug 13 13:09:21 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC0B21F92E7 for ; Tue, 13 Aug 2013 13:09:20 -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 ULdVjGHpyIyh for ; Tue, 13 Aug 2013 13:09:15 -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 1246021F8EFE for ; Tue, 13 Aug 2013 13:09:14 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 21C691200089 for ; Tue, 13 Aug 2013 22:09:13 +0200 (CEST) Date: Tue, 13 Aug 2013 22:09:12 +0200 (CEST) Message-Id: <20130813.220912.447857853.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund 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 Subject: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 20:09:21 -0000 Hi, I noticed that several of the configuraiton nodes are also reflected in as operational state. For example, there is: +--rw routing +--rw router* [name] | +--rw interfaces | | +--rw interface* [name] | | +--rw v6ur:ipv6-router-advertisements | | +--rw v6ur:send-advertisements? boolean and +--ro routing-state +--ro router* [name] | +--ro interfaces | | +--ro interface* [name] | | +--ro v6ur:ipv6-router-advertisements | | +--ro v6ur:send-advertisements? boolean Only the config false node has a reference to "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - AdvSendAdvertisements."; But in 4861, AdvSendAdvertisements is listed as a Configuration Variable. So it seems to me that the reference should be on the config node, not on the state node. But I think that the config false nodes in this case should be removed, since they would always reflect the configured value 1-1. In general, I think the description of the config false nodes should indicate if it just reflects the configured value nor not. Also, in some cases, the description of the config true node is less descriptive than the config false node. For example, list route-filter. /martin From lhotka@nic.cz Wed Aug 14 00:56:21 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA01D21F9F1B for ; Wed, 14 Aug 2013 00:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_00=-2.599, HOST_EQ_CZ=0.904, 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 hDNLcwYJqZZv for ; Wed, 14 Aug 2013 00:56:16 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 697B521F9F08 for ; Wed, 14 Aug 2013 00:56:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 09292540208 for ; Wed, 14 Aug 2013 09:56:04 +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 M7ULIdpSxbHD for ; Wed, 14 Aug 2013 09:55:53 +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 3ACE15401A9 for ; Wed, 14 Aug 2013 09:55:48 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20130813.220912.447857853.mbj@tail-f.com> References: <20130813.220912.447857853.mbj@tail-f.com> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 14 Aug 2013 09:55:47 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 07:56:21 -0000 Martin Bjorklund writes: > Hi, > > I noticed that several of the configuraiton nodes are also reflected > in as operational state. For example, there is: > > +--rw routing > +--rw router* [name] > | +--rw interfaces > | | +--rw interface* [name] > | | +--rw v6ur:ipv6-router-advertisements > | | +--rw v6ur:send-advertisements? boolean > > and > > +--ro routing-state > +--ro router* [name] > | +--ro interfaces > | | +--ro interface* [name] > | | +--ro v6ur:ipv6-router-advertisements > | | +--ro v6ur:send-advertisements? boolean > Yes, this is is a good point, and I spent quite some time thinking about it before submitting -10. > > Only the config false node has a reference to > > "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - > AdvSendAdvertisements."; > > But in 4861, AdvSendAdvertisements is listed as a Configuration > Variable. So it seems to me that the reference should be on the Right, but it doesn't say that it can be configured exclusively via NETCONF. > config node, not on the state node. But I think that the config false > nodes in this case should be removed, since they would always reflect > the configured value 1-1. I am not sure about this. I can imagine, for example, that an I2RS agent might want to stop the advertisements on its own. > > In general, I think the description of the config false nodes should > indicate if it just reflects the configured value nor not. This is another interesting dilemma. In my view, the operational state node is the "real" parameter (or at least closer to it), and the config node is only a "proposal" of a NETCONF client, which the server needn't accept, or which may be overriden by other means. >From this viewpoint, it makes more sense to bundle the descriptions and references with the state node because it is where any constraints really matter. All configuration interfaces (including NETCONF) that attempt to set the parameter have to follow these rules. Lada > > Also, in some cases, the description of the config true node is less > descriptive than the config false node. For example, list > route-filter. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Aug 14 03:03:09 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E999C11E8142 for ; Wed, 14 Aug 2013 03:03: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 9imty0BUnjJb for ; Wed, 14 Aug 2013 03:03:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 757F711E811E for ; Wed, 14 Aug 2013 03:03:05 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98F2A20C01; Wed, 14 Aug 2013 12:03:04 +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 Au3RSeOgJrX7; Wed, 14 Aug 2013 12:03:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E52C120C1F; Wed, 14 Aug 2013 12:03:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0D2AB27DE65E; Wed, 14 Aug 2013 12:02:56 +0200 (CEST) Date: Wed, 14 Aug 2013 12:02:56 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20130814100256.GA5185@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] berlin meeting minutes - please review X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 10:03:10 -0000 Hi, I have uploaded the minutes: http://www.ietf.org/proceedings/87/minutes/minutes-87-netmod Please review and let me know about any inaccuracies that need fixing. /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 Wed Aug 14 07:42:58 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F99111E81EB for ; Wed, 14 Aug 2013 07:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[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 P94bW0pmaS7b for ; Wed, 14 Aug 2013 07:42:52 -0700 (PDT) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by ietfa.amsl.com (Postfix) with ESMTP id B8EAE11E8169 for ; Wed, 14 Aug 2013 07:42:52 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id y10so6438273pdj.11 for ; Wed, 14 Aug 2013 07:42:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=0+L7iSaUhuVlOsZq7oi6PebkLe0ZHXZBZymzsIcjPGo=; b=gjAK6ZDhpeAZiQkHYOWKdmff7jph+aIO2vO2I1yVeDLpSv6/c6FUOuWCFmisZ7eG6f V040YY24X7PCNr+o28yzkQ5RCe1XXUlMGIv2GpLFTZKadsjZO7RnaC8c80I2mkxwetIA ms2JtZI9UwnfGCQnZpPtkdVd5r8zN7qlcRRzWSiXSMtNsa5DxesPeQXrd027SHyuI+pY +9TUsEutb0wTkCRIkLZDbB5R8LbC389VFdXfWT0MOpIWRxaea1xw63QedmrDaE1Dtj+E sgmlK/sdF6djLr2B+YZVCKR2KBbEort8F6srgWSFhWktvj+X0ccs6eUc8qm3ckSnDAPb /Gtw== X-Gm-Message-State: ALoCoQnDP7zIwTDLKiWYuIHhAydwr2moGeN/VNY0SxvViTnjJ+TIO0GJR3Bto0FYtSFhJSzdxnU8 MIME-Version: 1.0 X-Received: by 10.68.135.138 with SMTP id ps10mr10357293pbb.42.1376491371367; Wed, 14 Aug 2013 07:42:51 -0700 (PDT) Received: by 10.70.41.162 with HTTP; Wed, 14 Aug 2013 07:42:51 -0700 (PDT) In-Reply-To: References: <20130813.220912.447857853.mbj@tail-f.com> Date: Wed, 14 Aug 2013 07:42:51 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 14:42:58 -0000 On Wed, Aug 14, 2013 at 12:55 AM, Ladislav Lhotka wrote: > Martin Bjorklund writes: > >> Hi, >> >> I noticed that several of the configuraiton nodes are also reflected >> in as operational state. For example, there is: >> >> +--rw routing >> +--rw router* [name] >> | +--rw interfaces >> | | +--rw interface* [name] >> | | +--rw v6ur:ipv6-router-advertisements >> | | +--rw v6ur:send-advertisements? boolean >> >> and >> >> +--ro routing-state >> +--ro router* [name] >> | +--ro interfaces >> | | +--ro interface* [name] >> | | +--ro v6ur:ipv6-router-advertisements >> | | +--ro v6ur:send-advertisements? boolean >> > > Yes, this is is a good point, and I spent quite some time thinking about = it before submitting -10. > >> >> Only the config false node has a reference to >> >> "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - >> AdvSendAdvertisements."; >> >> But in 4861, AdvSendAdvertisements is listed as a Configuration >> Variable. So it seems to me that the reference should be on the > > Right, but it doesn't say that it can be configured exclusively via NETCO= NF. > I don't think we should create data models for protocols that don't exist, or unspecified proprietary mechanisms. We should avoid duplicate objects. If there is little or no chance the operational values will be different, then the operational duplicates should be removed. >> config node, not on the state node. But I think that the config false >> nodes in this case should be removed, since they would always reflect >> the configured value 1-1. > > I am not sure about this. I can imagine, for example, that an I2RS agent = might want to stop the advertisements on its own. We should not speculate what I2RS will want. Only NETCONF should be considered at this time. > >> >> In general, I think the description of the config false nodes should >> indicate if it just reflects the configured value nor not. > > This is another interesting dilemma. In my view, the operational state no= de is the "real" parameter (or at least closer to it), and the config node = is only a "proposal" of a NETCONF client, which the server needn't accept, = or which may be overriden by other means. > > From this viewpoint, it makes more sense to bundle the descriptions and r= eferences with the state node because it is where any constraints really ma= tter. All configuration interfaces (including NETCONF) that attempt to set = the parameter have to follow these rules. > IMO we have designed NETCONF/YANG so the constraints are placed on config=3Dtrue objects, because this is what clients can control. > Lada > >> >> Also, in some cases, the description of the config true node is less >> descriptive than the config false node. For example, list >> route-filter. >> >> >> /martin Andy From mbj@tail-f.com Wed Aug 14 07:52:48 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34E111E814C for ; Wed, 14 Aug 2013 07:52:47 -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 fkne16V1ZTt3 for ; Wed, 14 Aug 2013 07:52:42 -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 6DC7111E81ED for ; Wed, 14 Aug 2013 07:52:37 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 785C51200089; Wed, 14 Aug 2013 16:52:35 +0200 (CEST) Date: Wed, 14 Aug 2013 16:52:35 +0200 (CEST) Message-Id: <20130814.165235.319391216.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20130813.220912.447857853.mbj@tail-f.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: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 14:52:48 -0000 Andy Bierman wrote: > On Wed, Aug 14, 2013 at 12:55 AM, Ladislav Lhotka wrote: > > Martin Bjorklund writes: > > > >> Hi, > >> > >> I noticed that several of the configuraiton nodes are also reflected > >> in as operational state. For example, there is: > >> > >> +--rw routing > >> +--rw router* [name] > >> | +--rw interfaces > >> | | +--rw interface* [name] > >> | | +--rw v6ur:ipv6-router-advertisements > >> | | +--rw v6ur:send-advertisements? boolean > >> > >> and > >> > >> +--ro routing-state > >> +--ro router* [name] > >> | +--ro interfaces > >> | | +--ro interface* [name] > >> | | +--ro v6ur:ipv6-router-advertisements > >> | | +--ro v6ur:send-advertisements? boolean > >> > > > > Yes, this is is a good point, and I spent quite some time thinking about it > > before submitting -10. > > > >> > >> Only the config false node has a reference to > >> > >> "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - > >> AdvSendAdvertisements."; > >> > >> But in 4861, AdvSendAdvertisements is listed as a Configuration > >> Variable. So it seems to me that the reference should be on the > > > > Right, but it doesn't say that it can be configured exclusively via NETCONF. > > > > > I don't think we should create data models for protocols that don't exist, > or unspecified proprietary mechanisms. We should avoid duplicate objects. > If there is little or no chance the operational values will be different, > then the operational duplicates should be removed. +1 Further, I think it is not correct to think that the configuration datastore that is manipulated via NETCONF is unique to NETCONF. NETCONF is designed to be an interface to the device's configuration datastore, and there may be other interfaces (CLI, SNMP, WebUI, REST, ...) to the same datastore. The YANG model is a concrete data model of this datastore, that works for NETCONF. > >> config node, not on the state node. But I think that the config false > >> nodes in this case should be removed, since they would always reflect > >> the configured value 1-1. > > > > I am not sure about this. I can imagine, for example, that an I2RS agent > > might want to stop the advertisements on its own. > > We should not speculate what I2RS will want. > Only NETCONF should be considered at this time. Right, and it is easier to add these objects in the future, if necessary, than to remove them if they turned out to be unnecessary. /martin From andy@yumaworks.com Wed Aug 14 08:08:36 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAAB21E80BB for ; Wed, 14 Aug 2013 08:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.800, 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 8CRJ-gnDl0jv for ; Wed, 14 Aug 2013 08:08:15 -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 099CC21E8097 for ; Wed, 14 Aug 2013 08:08:13 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un15so9516479pbc.1 for ; Wed, 14 Aug 2013 08:08:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=O0fdBv22+wovKNEJpFMAGtGOQ6jNGXUYMRzt6GyQfIQ=; b=LJV7KsJN3zXA7ssFmwU68obi0WKQTQo9UnrKRr9w1s3fZ4EqVmm+5e1u2HnoigGHoM qkMoWnvWUWIecwCuWOZmrrkkBF28BZwzI/PE7NlhtpDHE/YGwKU296g37/F9al3XPG4C +NpP2PYKnSbaut/fSNaRwhgEl4SPCjz86afOTv1cF361GDb0cnUsvqoOAWp3F+9dyEwG D+fLQTblu0LFHAr1utbSTDi5nBfJ+zx+2wV32w9PNshEo9azY8WAHRgrO+rcVVrslhQ+ I2VDEjsl0o1sSr297RrRNww8ueJg+//clt/KD9EHiqewqiGnbfy9YNBLBBhzZs6ubImT VAQg== X-Gm-Message-State: ALoCoQlqY+X6OM6lPAySQnPgMiIVnaJxxZAF+owDrWbsAeL5oV90kuYPd7cT+OBiH7QoiSY0XeUp MIME-Version: 1.0 X-Received: by 10.68.19.162 with SMTP id g2mr10388556pbe.140.1376492880216; Wed, 14 Aug 2013 08:08:00 -0700 (PDT) Received: by 10.70.41.162 with HTTP; Wed, 14 Aug 2013 08:08:00 -0700 (PDT) In-Reply-To: <20130814.165235.319391216.mbj@tail-f.com> References: <20130813.220912.447857853.mbj@tail-f.com> <20130814.165235.319391216.mbj@tail-f.com> Date: Wed, 14 Aug 2013 08:08:00 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 15:08:36 -0000 .... > > Further, I think it is not correct to think that the configuration > datastore that is manipulated via NETCONF is unique to NETCONF. > NETCONF is designed to be an interface to the device's configuration > datastore, and there may be other interfaces (CLI, SNMP, WebUI, > REST, ...) to the same datastore. The YANG model is a concrete data > model of this datastore, that works for NETCONF. >... This is really important because we are not following this design in our standards, just in our code. For example, NACM is written to only provide access control for NETCONF, but of course we use it for all protocol access to YANG content because that is what customers expect. The netconf monitoring module says session ID 0 is for external sessions. In implementation, it makes more sense to assign every session a real ID and keep track of the protocol. > /martin Andy From lhotka@nic.cz Wed Aug 14 08:44:41 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F8121F99EC for ; Wed, 14 Aug 2013 08:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.113, 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 h6rx96K9kLk1 for ; Wed, 14 Aug 2013 08:44:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2129621F8F4F for ; Wed, 14 Aug 2013 08:44:40 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 37C3113F980; Wed, 14 Aug 2013 17:44:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1376495079; bh=tx/ia6Cfoi6oi+IxQMS1ZB2UE/KpiPwZMN3FNIGlNWU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lfUUSbd1h/z4ZY/gwJWyfMVjFAPzSgMhJ14dh7HmuIB8jyczZyEPvCyVl8kKd2miO wYbY36hfdZTA2LR0LG/Kof1v1ATSFCHI5kDOWceYlwt+mN2Pw40sxUW/4pC3bShgfb k4/X/T2VDw3hrkQa9r+mouOclxiIsQgBhmeNJZFE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130814.165235.319391216.mbj@tail-f.com> Date: Wed, 14 Aug 2013 17:44:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <56010AF8-450D-4645-AF32-C33F74865C24@nic.cz> References: <20130813.220912.447857853.mbj@tail-f.com> <20130814.165235.319391216.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 15:44:41 -0000 On Aug 14, 2013, at 4:52 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Wed, Aug 14, 2013 at 12:55 AM, Ladislav Lhotka = wrote: >>> Martin Bjorklund writes: >>>=20 >>>> Hi, >>>>=20 >>>> I noticed that several of the configuraiton nodes are also = reflected >>>> in as operational state. For example, there is: >>>>=20 >>>> +--rw routing >>>> +--rw router* [name] >>>> | +--rw interfaces >>>> | | +--rw interface* [name] >>>> | | +--rw v6ur:ipv6-router-advertisements >>>> | | +--rw v6ur:send-advertisements? boolean >>>>=20 >>>> and >>>>=20 >>>> +--ro routing-state >>>> +--ro router* [name] >>>> | +--ro interfaces >>>> | | +--ro interface* [name] >>>> | | +--ro v6ur:ipv6-router-advertisements >>>> | | +--ro v6ur:send-advertisements? boolean >>>>=20 >>>=20 >>> Yes, this is is a good point, and I spent quite some time thinking = about it >>> before submitting -10. >>>=20 >>>>=20 >>>> Only the config false node has a reference to >>>>=20 >>>> "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - >>>> AdvSendAdvertisements."; >>>>=20 >>>> But in 4861, AdvSendAdvertisements is listed as a Configuration >>>> Variable. So it seems to me that the reference should be on the >>>=20 >>> Right, but it doesn't say that it can be configured exclusively via = NETCONF. >>>=20 >>=20 >>=20 >> I don't think we should create data models for protocols that don't = exist, >> or unspecified proprietary mechanisms. We should avoid duplicate = objects. >> If there is little or no chance the operational values will be = different, >> then the operational duplicates should be removed. >=20 > +1 How can you tell that there is little or no chance? Let's take the "forwarding" flags in the "ietf-ip" module. I am now = inclined to assume that your plan is to have them only as configuration = nodes. However, on a Linux system that gives access to a standard shell, = the user can always do, for example, $ echo 1 > /proc/sys/net/ipv4/ip_forward and make the operational value different from what's in "running". So, = if the node is not in the -state tree, the NETCONF client has no chance = to learn the value that the device is really using. =20 >=20 > Further, I think it is not correct to think that the configuration > datastore that is manipulated via NETCONF is unique to NETCONF. > NETCONF is designed to be an interface to the device's configuration > datastore, and there may be other interfaces (CLI, SNMP, WebUI, > REST, ...) to the same datastore. The YANG model is a concrete data > model of this datastore, that works for NETCONF. Interfaces that bypass NETCONF do exist, and I2RS is going to be one of = them. IMO we would be better off if we come up with a model allowing = peaceful coexistence of NETCONF with other independent configuration = interfaces. There is also a big difference between closed devices where the vendor = has full control of all the gates to the silo, and open systems where = the power is on the user's side. =20 >=20 >>>> config node, not on the state node. But I think that the config = false >>>> nodes in this case should be removed, since they would always = reflect >>>> the configured value 1-1. >>>=20 >>> I am not sure about this. I can imagine, for example, that an I2RS = agent >>> might want to stop the advertisements on its own. >>=20 >> We should not speculate what I2RS will want. >> Only NETCONF should be considered at this time. >=20 > Right, and it is easier to add these objects in the future, if > necessary, than to remove them if they turned out to be unnecessary. Following the action point from Berlin, the routing module should be = aligned, as much as possible, with the needs of the I2RS WG. Lada =20 >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Aug 14 14:34:26 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B4121F8F32 for ; Wed, 14 Aug 2013 14:34:26 -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 CPNUCUfm+BX0 for ; Wed, 14 Aug 2013 14:34:21 -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 93F7B11E81B4 for ; Wed, 14 Aug 2013 14:34:20 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 4B8F71200444; Wed, 14 Aug 2013 23:34:17 +0200 (CEST) Date: Wed, 14 Aug 2013 23:34:16 +0200 (CEST) Message-Id: <20130814.233416.419497935.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <56010AF8-450D-4645-AF32-C33F74865C24@nic.cz> References: <20130814.165235.319391216.mbj@tail-f.com> <56010AF8-450D-4645-AF32-C33F74865C24@nic.cz> 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: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 21:34:26 -0000 Ladislav Lhotka wrote: > > On Aug 14, 2013, at 4:52 PM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > >> On Wed, Aug 14, 2013 at 12:55 AM, Ladislav Lhotka wrote: > >>> Martin Bjorklund writes: > >>> > >>>> Hi, > >>>> > >>>> I noticed that several of the configuraiton nodes are also reflected > >>>> in as operational state. For example, there is: > >>>> > >>>> +--rw routing > >>>> +--rw router* [name] > >>>> | +--rw interfaces > >>>> | | +--rw interface* [name] > >>>> | | +--rw v6ur:ipv6-router-advertisements > >>>> | | +--rw v6ur:send-advertisements? boolean > >>>> > >>>> and > >>>> > >>>> +--ro routing-state > >>>> +--ro router* [name] > >>>> | +--ro interfaces > >>>> | | +--ro interface* [name] > >>>> | | +--ro v6ur:ipv6-router-advertisements > >>>> | | +--ro v6ur:send-advertisements? boolean > >>>> > >>> > >>> Yes, this is is a good point, and I spent quite some time thinking about it > >>> before submitting -10. > >>> > >>>> > >>>> Only the config false node has a reference to > >>>> > >>>> "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - > >>>> AdvSendAdvertisements."; > >>>> > >>>> But in 4861, AdvSendAdvertisements is listed as a Configuration > >>>> Variable. So it seems to me that the reference should be on the > >>> > >>> Right, but it doesn't say that it can be configured exclusively via > >>> NETCONF. > >>> > >> > >> > >> I don't think we should create data models for protocols that don't exist, > >> or unspecified proprietary mechanisms. We should avoid duplicate objects. > >> If there is little or no chance the operational values will be different, > >> then the operational duplicates should be removed. > > > > +1 > > How can you tell that there is little or no chance? This will have to be done on a case-by-case basis. > Let's take the "forwarding" flags in the "ietf-ip" module. I am now inclined to > assume that your plan is to have them only as configuration nodes. However, on > a Linux system that gives access to a standard shell, the user can always do, > for example, > > $ echo 1 > /proc/sys/net/ipv4/ip_forward > > and make the operational value different from what's in "running". In this particular case I think it makes sense to also reflect this in the operational state. > So, if the > node is not in the -state tree, the NETCONF client has no chance to learn the > value that the device is really using. Right, but taking this to the extreme, we'd have to duplicate almost everything in all configuration models. As one example, it seems unlikely that the NACM data should be modified by anything but through the configuration. > > Further, I think it is not correct to think that the configuration > > datastore that is manipulated via NETCONF is unique to NETCONF. > > NETCONF is designed to be an interface to the device's configuration > > datastore, and there may be other interfaces (CLI, SNMP, WebUI, > > REST, ...) to the same datastore. The YANG model is a concrete data > > model of this datastore, that works for NETCONF. > > Interfaces that bypass NETCONF do exist, and I2RS is going to be one of > them. Well, I2RS is not a configuration interface. > IMO we would be better off if we come up with a model allowing peaceful > coexistence of NETCONF with other independent configuration interfaces. Yes... that's what I wrote above. There are other interfaces to the configuration datastores than just NETCONF. > There is also a big difference between closed devices where the vendor has full > control of all the gates to the silo, and open systems where the power is on > the user's side. If you add NETCONF to an (open) linux host, your implementation will have to interact with whatever ways there are to configure the different subsystems, often plain config files with varying syntax. It won't work if your implementation had its own 'running' datastore separate from the config files of the system. > >>>> config node, not on the state node. But I think that the config false > >>>> nodes in this case should be removed, since they would always reflect > >>>> the configured value 1-1. > >>> > >>> I am not sure about this. I can imagine, for example, that an I2RS agent > >>> might want to stop the advertisements on its own. > >> > >> We should not speculate what I2RS will want. > >> Only NETCONF should be considered at this time. > > > > Right, and it is easier to add these objects in the future, if > > necessary, than to remove them if they turned out to be unnecessary. > > Following the action point from Berlin, the routing module should be aligned, > as much as possible, with the needs of the I2RS WG. I support this, of course. But do we know at this stage if I2RS has requirements to modify these particular objects? I.e., send-advertisements etc. /martin From j.schoenwaelder@jacobs-university.de Wed Aug 14 23:44:27 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F9621F8FF8 for ; Wed, 14 Aug 2013 23:44:27 -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 5Cfz2xhoA024 for ; Wed, 14 Aug 2013 23:44:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E6A8D11E80F0 for ; Wed, 14 Aug 2013 23:44:21 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C90AC20BDA; Thu, 15 Aug 2013 08:44:20 +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 E2tcLDj4Olbr; Thu, 15 Aug 2013 08:44:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D68E20733; Thu, 15 Aug 2013 08:44:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9BCBD27DFEEC; Thu, 15 Aug 2013 08:44:13 +0200 (CEST) Date: Thu, 15 Aug 2013 08:44:13 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20130815064413.GA8087@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org, i2rs-chairs@tools.ietf.org References: <20130813.220912.447857853.mbj@tail-f.com> <20130814.165235.319391216.mbj@tail-f.com> <56010AF8-450D-4645-AF32-C33F74865C24@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56010AF8-450D-4645-AF32-C33F74865C24@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: i2rs-chairs@tools.ietf.org, netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 06:44:27 -0000 On Wed, Aug 14, 2013 at 05:44:38PM +0200, Ladislav Lhotka wrote: > > Following the action point from Berlin, the routing module should be > aligned, as much as possible, with the needs of the I2RS WG. My understanding is that there is an action item to figure out what the differences are (if any) between "our" routing data model and the proposed I2RS information model. Part of the exercise is to make sure that players in both WGs take a detailed look at the other WGs work so we can take informed decisions. I do not think we decided that "the routing module should be aligned, as much as possible, with the needs of the I2RS WG" because this essentially means to wait until I2RS is finished. Instead, we give this activity a timeout that will expire at the Vancouver meeting. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Thu Aug 15 00:10:06 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F56811E80E1 for ; Thu, 15 Aug 2013 00:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, HOST_EQ_CZ=0.904, 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 d-L62aOXzFYj for ; Thu, 15 Aug 2013 00:10:00 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0330C21F99A1 for ; Thu, 15 Aug 2013 00:09:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id AB49954030F; Thu, 15 Aug 2013 09:09:52 +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 sr8Mx82-zrKf; Thu, 15 Aug 2013 09:09:45 +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 39E185401FC; Thu, 15 Aug 2013 09:09:40 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20130814.233416.419497935.mbj@tail-f.com> References: <20130814.165235.319391216.mbj@tail-f.com> <56010AF8-450D-4645-AF32-C33F74865C24@nic.cz> <20130814.233416.419497935.mbj@tail-f.com> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org Date: Thu, 15 Aug 2013 09:09:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 07:10:06 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >> >> On Aug 14, 2013, at 4:52 PM, Martin Bjorklund wrote: >> >> > Andy Bierman wrote: >> >> On Wed, Aug 14, 2013 at 12:55 AM, Ladislav Lhotka wrote: >> >>> Martin Bjorklund writes: >> >>> >> >>>> Hi, >> >>>> >> >>>> I noticed that several of the configuraiton nodes are also reflected >> >>>> in as operational state. For example, there is: >> >>>> >> >>>> +--rw routing >> >>>> +--rw router* [name] >> >>>> | +--rw interfaces >> >>>> | | +--rw interface* [name] >> >>>> | | +--rw v6ur:ipv6-router-advertisements >> >>>> | | +--rw v6ur:send-advertisements? boolean >> >>>> >> >>>> and >> >>>> >> >>>> +--ro routing-state >> >>>> +--ro router* [name] >> >>>> | +--ro interfaces >> >>>> | | +--ro interface* [name] >> >>>> | | +--ro v6ur:ipv6-router-advertisements >> >>>> | | +--ro v6ur:send-advertisements? boolean >> >>>> >> >>> >> >>> Yes, this is is a good point, and I spent quite some time thinking about it >> >>> before submitting -10. >> >>> >> >>>> >> >>>> Only the config false node has a reference to >> >>>> >> >>>> "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - >> >>>> AdvSendAdvertisements."; >> >>>> >> >>>> But in 4861, AdvSendAdvertisements is listed as a Configuration >> >>>> Variable. So it seems to me that the reference should be on the >> >>> >> >>> Right, but it doesn't say that it can be configured exclusively via >> >>> NETCONF. >> >>> >> >> >> >> >> >> I don't think we should create data models for protocols that don't exist, >> >> or unspecified proprietary mechanisms. We should avoid duplicate objects. >> >> If there is little or no chance the operational values will be different, >> >> then the operational duplicates should be removed. >> > >> > +1 >> >> How can you tell that there is little or no chance? > > This will have to be done on a case-by-case basis. The result may differ from one implementation to another. > >> Let's take the "forwarding" flags in the "ietf-ip" module. I am now inclined to >> assume that your plan is to have them only as configuration nodes. However, on >> a Linux system that gives access to a standard shell, the user can always do, >> for example, >> >> $ echo 1 > /proc/sys/net/ipv4/ip_forward >> >> and make the operational value different from what's in "running". > > In this particular case I think it makes sense to also reflect this in > the operational state. Yes, and an additional benefit is that you get all info about interface state from one place. > >> So, if the >> node is not in the -state tree, the NETCONF client has no chance to learn the >> value that the device is really using. > > Right, but taking this to the extreme, we'd have to duplicate almost > everything in all configuration models. As one example, it seems I agree it is not particularly elegant, but so far no solid shortcut has been proposed. > unlikely that the NACM data should be modified by anything but through > the configuration. Yes, but NACM is quite special in that it is related only to NETCONF stuff. > >> > Further, I think it is not correct to think that the configuration >> > datastore that is manipulated via NETCONF is unique to NETCONF. >> > NETCONF is designed to be an interface to the device's configuration >> > datastore, and there may be other interfaces (CLI, SNMP, WebUI, >> > REST, ...) to the same datastore. The YANG model is a concrete data >> > model of this datastore, that works for NETCONF. >> >> Interfaces that bypass NETCONF do exist, and I2RS is going to be one of >> them. > > Well, I2RS is not a configuration interface. The point is that is can change the state so that it doesn't reflect what has been configured. For instance, a configured static route may not be present in the routing table. > >> IMO we would be better off if we come up with a model allowing peaceful >> coexistence of NETCONF with other independent configuration interfaces. > > Yes... that's what I wrote above. There are other interfaces to the > configuration datastores than just NETCONF. But you assume that they all operate on a datastore that essentially is NETCONF's running. The problem with this is that running can be locked. IMO, the common playground should be "writable operational state", i.e. a conceptual datastore that cannot be locked and always reflects operational state 1:1 - like the /proc filesystem. > >> There is also a big difference between closed devices where the vendor has full >> control of all the gates to the silo, and open systems where the power is on >> the user's side. > > If you add NETCONF to an (open) linux host, your implementation will > have to interact with whatever ways there are to configure the > different subsystems, often plain config files with varying syntax. > It won't work if your implementation had its own 'running' datastore > separate from the config files of the system. True, that's why it is rather difficult - you have to rewrite all the daemons. > >> >>>> config node, not on the state node. But I think that the config false >> >>>> nodes in this case should be removed, since they would always reflect >> >>>> the configured value 1-1. >> >>> >> >>> I am not sure about this. I can imagine, for example, that an I2RS agent >> >>> might want to stop the advertisements on its own. >> >> >> >> We should not speculate what I2RS will want. >> >> Only NETCONF should be considered at this time. >> > >> > Right, and it is easier to add these objects in the future, if >> > necessary, than to remove them if they turned out to be unnecessary. >> >> Following the action point from Berlin, the routing module should be aligned, >> as much as possible, with the needs of the I2RS WG. > > I support this, of course. But do we know at this stage if I2RS has > requirements to modify these particular objects? I.e., > send-advertisements etc. Jan promised they would review the routing model and say where it doesn't match I2RS requirements. One case that I've already heard about is the "recursive next hop" - I understand it runs into the limitation that YANG cannot model recursive structures. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Thu Aug 15 04:31:03 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4657021F91B7 for ; Thu, 15 Aug 2013 04:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HOST_EQ_CZ=0.904, 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 Xg8F1bNzjhrd for ; Thu, 15 Aug 2013 04:30:59 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id BC0A121F9FE5 for ; Thu, 15 Aug 2013 04:30:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id CF25554030F; Thu, 15 Aug 2013 13:30:50 +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 w3TWRCjJWx5z; Thu, 15 Aug 2013 13:30:43 +0200 (CEST) Received: from [172.29.2.201] (unknown [172.29.2.201]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 611F55401FC; Thu, 15 Aug 2013 13:30:39 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130815064413.GA8087@elstar.local> Date: Thu, 15 Aug 2013 13:30:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5F1B12E3-5A49-4DA4-8233-B271F978B75B@nic.cz> References: <20130813.220912.447857853.mbj@tail-f.com> <20130814.165235.319391216.mbj@tail-f.com> <56010AF8-450D-4645-AF32-C33F74865C24@nic.cz> <20130815064413.GA8087@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1508) Cc: i2rs-chairs@tools.ietf.org, netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 11:31:03 -0000 On Aug 15, 2013, at 8:44 AM, Juergen Schoenwaelder = wrote: > On Wed, Aug 14, 2013 at 05:44:38PM +0200, Ladislav Lhotka wrote: >>=20 >> Following the action point from Berlin, the routing module should be >> aligned, as much as possible, with the needs of the I2RS WG. >=20 > My understanding is that there is an action item to figure out what > the differences are (if any) between "our" routing data model and the > proposed I2RS information model. Part of the exercise is to make sure > that players in both WGs take a detailed look at the other WGs work so > we can take informed decisions. >=20 > I do not think we decided that "the routing module should be aligned, > as much as possible, with the needs of the I2RS WG" because this > essentially means to wait until I2RS is finished. Instead, we give > this activity a timeout that will expire at the Vancouver meeting. Of course. We need to identify places where our routing model cannot be = augmented to suit I2RS needs, due to either its current design or = limitations in YANG. I hope the *needs* can be formulated soon. Lada =20 >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From akatlas@juniper.net Thu Aug 15 09:12:45 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6173911E81E9 for ; Thu, 15 Aug 2013 09:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=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 DNtvLO2h2tQn for ; Thu, 15 Aug 2013 09:12:39 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9F76411E81E8 for ; Thu, 15 Aug 2013 09:12:37 -0700 (PDT) Received: from mail174-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.22; Thu, 15 Aug 2013 16:12:36 +0000 Received: from mail174-ch1 (localhost [127.0.0.1]) by mail174-ch1-R.bigfish.com (Postfix) with ESMTP id E2D0E140120; Thu, 15 Aug 2013 16:12:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097hz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail174-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=akatlas@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(199002)(189002)(377454003)(13464003)(24454002)(56816003)(81342001)(63696002)(46102001)(76786001)(81542001)(77096001)(69226001)(76796001)(76576001)(74876001)(51856001)(49866001)(81816001)(74366001)(47736001)(16406001)(81686001)(53806001)(47976001)(66066001)(4396001)(74706001)(80022001)(74316001)(59766001)(47446002)(31966008)(83322001)(19580395003)(83072001)(79102001)(19580405001)(80976001)(54356001)(54316002)(56776001)(33646001)(76482001)(74662001)(77982001)(74502001)(50986001)(65816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB052; H:BL2PR05MB193.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail174-ch1 (localhost.localdomain [127.0.0.1]) by mail174-ch1 (MessageSwitch) id 1376583153946444_4505; Thu, 15 Aug 2013 16:12:33 +0000 (UTC) Received: from CH1EHSMHS010.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail174-ch1.bigfish.com (Postfix) with ESMTP id E228F460059; Thu, 15 Aug 2013 16:12:33 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 15 Aug 2013 16:12:33 +0000 Received: from BL2PR05MB052.namprd05.prod.outlook.com (10.255.228.156) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.347.3; Thu, 15 Aug 2013 16:12:31 +0000 Received: from BL2PR05MB193.namprd05.prod.outlook.com (10.242.198.143) by BL2PR05MB052.namprd05.prod.outlook.com (10.255.228.156) with Microsoft SMTP Server (TLS) id 15.0.731.16; Thu, 15 Aug 2013 16:12:29 +0000 Received: from BL2PR05MB193.namprd05.prod.outlook.com ([169.254.9.140]) by BL2PR05MB193.namprd05.prod.outlook.com ([169.254.9.140]) with mapi id 15.00.0731.000; Thu, 15 Aug 2013 16:12:29 +0000 From: Alia Atlas To: Ladislav Lhotka , Juergen Schoenwaelder Thread-Topic: [netmod] comments on draft-ietf-netmod-routing-cfg-10 Thread-Index: AQHOmYLsxdioWaW9n0Wv47pDiFrA7pmWIrUAgABJQvA= Date: Thu, 15 Aug 2013 16:12:28 +0000 Message-ID: References: <20130813.220912.447857853.mbj@tail-f.com> <20130814.165235.319391216.mbj@tail-f.com> <56010AF8-450D-4645-AF32-C33F74865C24@nic.cz> <20130815064413.GA8087@elstar.local> <5F1B12E3-5A49-4DA4-8233-B271F978B75B@nic.cz> In-Reply-To: <5F1B12E3-5A49-4DA4-8233-B271F978B75B@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0939529DE2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Mailman-Approved-At: Fri, 16 Aug 2013 00:19:12 -0700 Cc: "i2rs-chairs@tools.ietf.org" , Nitin Bahadur , "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 16:12:45 -0000 Inline as [Alia] -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 Sent: Thursday, August 15, 2013 7:31 AM To: Juergen Schoenwaelder Cc: netmod@ietf.org; i2rs-chairs@tools.ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 On Aug 15, 2013, at 8:44 AM, Juergen Schoenwaelder wrote: > On Wed, Aug 14, 2013 at 05:44:38PM +0200, Ladislav Lhotka wrote: >>=20 >> Following the action point from Berlin, the routing module should be=20 >> aligned, as much as possible, with the needs of the I2RS WG. >=20 > My understanding is that there is an action item to figure out what=20 > the differences are (if any) between "our" routing data model and the=20 > proposed I2RS information model. Part of the exercise is to make sure=20 > that players in both WGs take a detailed look at the other WGs work so=20 > we can take informed decisions. >=20 > I do not think we decided that "the routing module should be aligned,=20 > as much as possible, with the needs of the I2RS WG" because this=20 > essentially means to wait until I2RS is finished. Instead, we give=20 > this activity a timeout that will expire at the Vancouver meeting. Of course. We need to identify places where our routing model cannot be aug= mented to suit I2RS needs, due to either its current design or limitations = in YANG. I hope the *needs* can be formulated soon. [Alia] First, I certainly agree that NetMod shouldn't wait until I2RS is fi= nished. I do think that the routing model and the RIB info-model are tryin= g to support different things. It may make sense that the routing model ha= s higher abstractions, does different or additional configuration, and so o= n. That said, I do think the RIB info-model draft is fairly accurate in de= scribing what is needed for the RIB - and that can support a wide range of = static routes. However, in routing, usually there are higher level abstrac= tions that are applied for accuracy and ease; one can put an MPLS label on = an outgoing packet - but this is frequently modeled as going into an LSP or= a tunnel or connected to LDP's FECs or an L3VPN or so on. [Alia] What would be very interesting is the work that it sounds like Lada = is already doing - investigating if there are missing features in YANG to s= upport the types of info-models that I2RS is working on producing. At some point soon, I2RS will need to look at the= requirements on data-modeling languages and understanding what is easy and= hard to do in YANG and others. Alia From lhotka@nic.cz Fri Aug 16 04:44:25 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D70711E8136 for ; Fri, 16 Aug 2013 04:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.053 X-Spam-Level: X-Spam-Status: No, score=-1.053 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=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 5pEgMsmUPDbZ for ; Fri, 16 Aug 2013 04:44:20 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id D26EF11E8142 for ; Fri, 16 Aug 2013 04:44:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 2CEFC5403C7; Fri, 16 Aug 2013 13:44:13 +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 IGIsJC+gYsa6; Fri, 16 Aug 2013 13:44:07 +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 48FB45401FC; Fri, 16 Aug 2013 13:44:02 +0200 (CEST) From: Ladislav Lhotka To: Alia Atlas , Juergen Schoenwaelder In-Reply-To: References: <20130813.220912.447857853.mbj@tail-f.com> <20130814.165235.319391216.mbj@tail-f.com> <56010AF8-450D-4645-AF32-C33F74865C24@nic.cz> <20130815064413.GA8087@elstar.local> <5F1B12E3-5A49-4DA4-8233-B271F978B75B@nic.cz> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: Alia Atlas , Juergen Schoenwaelder , "netmod\@ietf.org" , "i2rs-chairs\@tools.ietf.org" , Nitin Bahadur Date: Fri, 16 Aug 2013 13:44:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "i2rs-chairs@tools.ietf.org" , Nitin Bahadur , "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 11:44:25 -0000 Hi Alia, Alia Atlas writes: > [Alia] First, I certainly agree that NetMod shouldn't wait until I2RS is finished. I do think that the routing model and the RIB info-model are trying to support different things. It may make sense that the routing model has higher abstractions, does different or additional configuration, and so on. That said, I Yes, NETCONF has configuration data that are not of direct interest to I2RS. On the other hand, the I2RS data store could IMO be pretty much the same as the operational state data in NETCONF (config false in YANG terms) - except that (parts of) it will be read-write for I2RS, whereas for NETCONF it will be by definition read-only. This could include routing tables, protocol databases etc. > do think the RIB info-model draft is fairly accurate in describing what is needed for the RIB - and that can support a wide range of static routes. However, in routing, usually there are higher level abstractions that are applied for accuracy and ease; one can put an MPLS label on an outgoing packet - but this is frequently modeled as going into an LSP or a tunnel or connected to LDP's FECs or an L3VPN or so on. > > [Alia] What would be very interesting is the work that it sounds like Lada is already doing - investigating if there are missing features in YANG to support the types of info-models that I2RS > is working on producing. At some point soon, I2RS will need to look at the requirements on data-modeling languages and understanding what is easy and hard to do in YANG and others. I haven't started such an investigation yet but I am prepared to do so. Lada > > Alia > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Aug 19 01:23:53 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1157E11E8217 for ; Mon, 19 Aug 2013 01:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=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 4wmPdoLVo-pe for ; Mon, 19 Aug 2013 01:23: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 44B5E21F9433 for ; Mon, 19 Aug 2013 01:23:28 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8852B20C43; Mon, 19 Aug 2013 10:23:26 +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 u1uwrXL1HVKL; Mon, 19 Aug 2013 10:23:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0FC1D20C01; Mon, 19 Aug 2013 10:23:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6297327EFE2E; Mon, 19 Aug 2013 10:23:20 +0200 (CEST) Date: Mon, 19 Aug 2013 10:23:20 +0200 From: Juergen Schoenwaelder To: Alia Atlas Message-ID: <20130819082320.GA62925@elstar.local> Mail-Followup-To: Alia Atlas , Ladislav Lhotka , "netmod@ietf.org" , "i2rs-chairs@tools.ietf.org" , Nitin Bahadur References: <20130813.220912.447857853.mbj@tail-f.com> <20130814.165235.319391216.mbj@tail-f.com> <56010AF8-450D-4645-AF32-C33F74865C24@nic.cz> <20130815064413.GA8087@elstar.local> <5F1B12E3-5A49-4DA4-8233-B271F978B75B@nic.cz> 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: Nitin Bahadur , "i2rs-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 08:23:53 -0000 On Thu, Aug 15, 2013 at 04:12:28PM +0000, Alia Atlas wrote: > > Of course. We need to identify places where our routing model cannot be augmented to suit I2RS needs, due to either its current design or limitations in YANG. I hope the *needs* can be formulated soon. > > [Alia] First, I certainly agree that NetMod shouldn't wait until I2RS is finished. I do think that the routing model and the RIB info-model are trying to support different things. It may make sense that the routing model has higher abstractions, does different or additional configuration, and so on. That said, I do think the RIB info-model draft is fairly accurate in describing what is needed for the RIB - and that can support a wide range of static routes. However, in routing, usually there are higher level abstractions that are applied for accuracy and ease; one can put an MPLS label on an outgoing packet - but this is frequently modeled as going into an LSP or a tunnel or connected to LDP's FECs or an L3VPN or so on. > Alia, I think basic concepts and terminology should be aligned between a standard routing configuration interface and a standard routing state manipulation interface. I surely expect that the I2RS info model goes beyond what we have in NETMOD but for the core bits and pieces (basic concepts and in particular also terminology), I think the industry will benefit if things turn out to be reasonably consistent. I hope by Vancouver we are in a situation where basic concepts and terminology have already started to converge. This would be great. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Mon Aug 19 01:37:28 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B07121F9A35 for ; Mon, 19 Aug 2013 01:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, J_CHICKENPOX_13=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 b5T-RDAaO5n0 for ; Mon, 19 Aug 2013 01:37: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 6226011E81C3 for ; Mon, 19 Aug 2013 01:37:15 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 13F9113FCBF; Mon, 19 Aug 2013 10:37:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1376901432; bh=3k7+sAcpGah2SSTmOAV5ZWhyJLJ8Bf9uZ+1ND+Vu0+U=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=H2oTTdKdV+ITlwBDqk5n5UZLd8GvwP9xltTp14MjFKxszvVyvICnNxMT9c/FXQKgI vLyhfhGeCdwdjCjHxkUQLk+BvJXttBqZw/ec8vHgaEQC++6qu1nkFwXMxEYL25hZJm jBwbKzZBm1xMh8V4EOKkwkZrwcq7m1ndHk4gnghs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130819082320.GA62925@elstar.local> Date: Mon, 19 Aug 2013 10:37:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130813.220912.447857853.mbj@tail-f.com> <20130814.165235.319391216.mbj@tail-f.com> <56010AF8-450D-4645-AF32-C33F74865C24@nic.cz> <20130815064413.GA8087@elstar.local> <5F1B12E3-5A49-4DA4-8233-B271F978B75B@nic.cz> <20130819082320.GA62925@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "i2rs-chairs@tools.ietf.org" , Alia Atlas , Nitin Bahadur , "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 08:37:31 -0000 On Aug 19, 2013, at 10:23 AM, Juergen Schoenwaelder = wrote: > On Thu, Aug 15, 2013 at 04:12:28PM +0000, Alia Atlas wrote: >>=20 >> Of course. We need to identify places where our routing model cannot = be augmented to suit I2RS needs, due to either its current design or = limitations in YANG. I hope the *needs* can be formulated soon. >>=20 >> [Alia] First, I certainly agree that NetMod shouldn't wait until I2RS = is finished. I do think that the routing model and the RIB info-model = are trying to support different things. It may make sense that the = routing model has higher abstractions, does different or additional = configuration, and so on. That said, I do think the RIB info-model = draft is fairly accurate in describing what is needed for the RIB - and = that can support a wide range of static routes. However, in routing, = usually there are higher level abstractions that are applied for = accuracy and ease; one can put an MPLS label on an outgoing packet - but = this is frequently modeled as going into an LSP or a tunnel or connected = to LDP's FECs or an L3VPN or so on. >>=20 >=20 > Alia, I think basic concepts and terminology should be aligned between > a standard routing configuration interface and a standard routing > state manipulation interface. I surely expect that the I2RS info model > goes beyond what we have in NETMOD but for the core bits and pieces > (basic concepts and in particular also terminology), I think the > industry will benefit if things turn out to be reasonably consistent. > I hope by Vancouver we are in a situation where basic concepts and > terminology have already started to converge. This would be great. +1 Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jmedved@cisco.com Mon Aug 19 17:41:40 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A063F11E8303 for ; Mon, 19 Aug 2013 17:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, 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 6XGQxjauwZfI for ; Mon, 19 Aug 2013 17:41:29 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id BA3E011E82CB for ; Mon, 19 Aug 2013 17:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2527; q=dns/txt; s=iport; t=1376959289; x=1378168889; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=am7o6DeJtJ6iyLz02FxlV/+VbQPQHcOF/eh4tH4nIbM=; b=CQIdfJudzdAJm+pNcm7Ja2o40WJXr9EKjRwqxHjXUDLCHVlE/mp3yb5C ckrMoxymdazHc/nA2Z1hdL2P2Wm7qvokIlgJGZF1J7xLoLz7KxMzJCfRR 4oGIPC+CMo0gyLGoMrxkPEmCH/40SecHO6eI3jFJ+jeSCskSKFGneGXek 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAP25ElKtJV2a/2dsb2JhbABagwU1Ub80gSQWdIIkAQEBAwEBAQE3NAsSAQgiFDcLJQIEAQ0FCIgCBgyqdZArMQeDG3cDmRGQKIMcgio X-IronPort-AV: E=Sophos;i="4.89,915,1367971200"; d="scan'208";a="249202388" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 20 Aug 2013 00:41:28 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7K0fSts018123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Aug 2013 00:41:28 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.56]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Mon, 19 Aug 2013 19:41:28 -0500 From: "Jan Medved (jmedved)" To: Ladislav Lhotka , Alia Atlas , "Juergen Schoenwaelder" Thread-Topic: [netmod] comments on draft-ietf-netmod-routing-cfg-10 Thread-Index: AQHOmGEBhwZpkivAEUeFZ750nA6W0JmUqm6AgABxvICAAAK4gIAADosAgAD7V4CAAFAGAIAATr4AgAFHWYCABRrVgA== Date: Tue, 20 Aug 2013 00:41:27 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.27.7.167] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "i2rs-chairs@tools.ietf.org" , Nitin Bahadur , "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 00:41:40 -0000 On 8/16/13 4:44 AM, "Ladislav Lhotka" wrote: >Hi Alia, > >Alia Atlas writes: > >> [Alia] First, I certainly agree that NetMod shouldn't wait until I2RS >>is finished. I do think that the routing model and the RIB info-model >>are trying to support different things. It may make sense that the >>routing model has higher abstractions, does different or additional >>configuration, and so on. That said, I > >Yes, NETCONF has configuration data that are not of direct interest to >I2RS. On the other hand, the I2RS data store could IMO be pretty much the >same as the operational state data in NETCONF (config false in YANG >terms) - except that (parts of) it will be read-write for I2RS, whereas >for NETCONF it will be by definition read-only. This could include >routing tables, protocol databases etc. I like the idea. Maybe we could define an 'access-rights' statement that would determine whether a data node (or a subtree) is read-only or read-write.=20 A similar approach has been proposed by Rex Fernando et. al in http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00#section-3.4, where they defined an 'ephemeral statement to address the same problem. > >> do think the RIB info-model draft is fairly accurate in describing what >>is needed for the RIB - and that can support a wide range of static >>routes. However, in routing, usually there are higher level >>abstractions that are applied for accuracy and ease; one can put an MPLS >>label on an outgoing packet - but this is frequently modeled as going >>into an LSP or a tunnel or connected to LDP's FECs or an L3VPN or so on. >> >> [Alia] What would be very interesting is the work that it sounds like >>Lada is already doing - investigating if there are missing features in >>YANG to support the types of info-models that I2RS >> is working on producing. At some point soon, I2RS will need to look at >>the requirements on data-modeling languages and understanding what is >>easy and hard to do in YANG and others. > >I haven't started such an investigation yet but I am prepared to do so. Some of this work has been done - please see http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00. Thanks, Jan > >Lada > >> >> Alia >> >> > >--=20 >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Tue Aug 20 01:34:52 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0E011E81F6 for ; Tue, 20 Aug 2013 01:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=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 BUsZs0LY853N for ; Tue, 20 Aug 2013 01:34:48 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 73FE111E80F7 for ; Tue, 20 Aug 2013 01:34:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 268B05403BF; Tue, 20 Aug 2013 10:34:32 +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 RAUGRlMEyCXY; Tue, 20 Aug 2013 10:34:23 +0200 (CEST) Received: from localhost (fw.nic.cz [217.31.207.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 97F315401BA; Tue, 20 Aug 2013 10:34:14 +0200 (CEST) From: Ladislav Lhotka To: "Jan Medved \(jmedved\)" , Alia Atlas , Juergen Schoenwaelder In-Reply-To: References: User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: "Jan Medved \(jmedved\)" , Alia Atlas , Juergen Schoenwaelder , "i2rs-chairs\@tools.ietf.org" , Nitin Bahadur , "netmod\@ietf.org" Date: Tue, 20 Aug 2013 10:34:08 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "i2rs-chairs@tools.ietf.org" , Nitin Bahadur , "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 08:34:52 -0000 "Jan Medved (jmedved)" writes: > On 8/16/13 4:44 AM, "Ladislav Lhotka" wrote: > >>Hi Alia, >> >>Alia Atlas writes: >> >>> [Alia] First, I certainly agree that NetMod shouldn't wait until I2RS >>>is finished. I do think that the routing model and the RIB info-model >>>are trying to support different things. It may make sense that the >>>routing model has higher abstractions, does different or additional >>>configuration, and so on. That said, I >> >>Yes, NETCONF has configuration data that are not of direct interest to >>I2RS. On the other hand, the I2RS data store could IMO be pretty much the >>same as the operational state data in NETCONF (config false in YANG >>terms) - except that (parts of) it will be read-write for I2RS, whereas >>for NETCONF it will be by definition read-only. This could include >>routing tables, protocol databases etc. > > I like the idea. Maybe we could define an 'access-rights' statement that > would determine whether a data node (or a subtree) is read-only or > read-write. Yes, a simple YANG extension would do. > > A similar approach has been proposed by Rex Fernando et. al in > http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00#section-3.4, > where they defined an 'ephemeral statement to address the same problem. Right, writable operational state data should probably be ephemeral by definition. > >> >>> do think the RIB info-model draft is fairly accurate in describing what >>>is needed for the RIB - and that can support a wide range of static >>>routes. However, in routing, usually there are higher level >>>abstractions that are applied for accuracy and ease; one can put an MPLS >>>label on an outgoing packet - but this is frequently modeled as going >>>into an LSP or a tunnel or connected to LDP's FECs or an L3VPN or so on. >>> >>> [Alia] What would be very interesting is the work that it sounds like >>>Lada is already doing - investigating if there are missing features in >>>YANG to support the types of info-models that I2RS >>> is working on producing. At some point soon, I2RS will need to look at >>>the requirements on data-modeling languages and understanding what is >>>easy and hard to do in YANG and others. >> >>I haven't started such an investigation yet but I am prepared to do so. > > Some of this work has been done - please see > http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00. We had a short meeting with the authors in Orlando, but a broader discussion (perhaps in the NETMOD mailing list) might be useful. Ahoj, Lada > > > > Thanks, > Jan > >> >>Lada >> >>> >>> Alia >>> >>> >> >>-- >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C >>_______________________________________________ >>netmod mailing list >>netmod@ietf.org >>https://www.ietf.org/mailman/listinfo/netmod > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From muthu@cisco.com Tue Aug 20 15:55:16 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E0C11E830A for ; Tue, 20 Aug 2013 15:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, 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 xZJTxmWZSysf for ; Tue, 20 Aug 2013 15:55:09 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id CB46F11E8301 for ; Tue, 20 Aug 2013 15:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3727; q=dns/txt; s=iport; t=1377039309; x=1378248909; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8Vrh4TYEvWKSVsWCAwe39V7f6VcdrntWqMkZn6RWCVg=; b=OGfNS11UvIrx2aJIWV9wO+3kXVMC5Xjfs9xASuPAMJZH1dw2CiSAlrXJ M4O+EV7Mcdhz8H/is41DCUKqAgnFV6fWqWTkxZT32V4pcGtG9p8sZP+Wc v/BZG2WM7C2E9D7zaUnQHR41j4tPFEKlFNhdJTIC1uKFjGx/4zK5+Hb6E k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAKLyE1KtJXHB/2dsb2JhbABagwU1Ub9agSYWdIIkAQEBBAEBATc0CxIBCBgKFDcLJQIEAQ0FCIgIDK1ckCQxB4MbeQOZEpApgxyCKg X-IronPort-AV: E=Sophos;i="4.89,923,1367971200"; d="scan'208";a="249717830" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 20 Aug 2013 22:55:08 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7KMt8TO027434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Aug 2013 22:55:08 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.77]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 20 Aug 2013 17:55:07 -0500 From: "Muthumayan Madhayyan (muthu)" To: Ladislav Lhotka , "Jan Medved (jmedved)" , Alia Atlas , Juergen Schoenwaelder Thread-Topic: [netmod] comments on draft-ietf-netmod-routing-cfg-10 Thread-Index: AQHOmGEBI8PXbbfFTkmYweHRl90ooJmUqm6AgABxvICAAAK4gIAADosAgAD7V4CAAFAGAIAATr4AgAFHWYCABZAwgIAAhBEAgAB7MAA= Date: Tue, 20 Aug 2013 22:55:06 +0000 Message-ID: <5A949C32AF740C4798AEECF2568F0D840C156729@xmb-rcd-x13.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.154.205.175] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "i2rs-chairs@tools.ietf.org" , Nitin Bahadur , "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 22:55:16 -0000 Hello Lada, Apart from the ability to write ephemeral data, I2RS also has a requirement to associate client ownership to data injected by an external client. In NETCONF, the stores are global. I don't want to divert this discussion. Perhaps we should start another thread on the draft: http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00 ? +Alex Clemm as well. Thanks - muthuu On 8/20/13 1:34 AM, "Ladislav Lhotka" wrote: >"Jan Medved (jmedved)" writes: > >> On 8/16/13 4:44 AM, "Ladislav Lhotka" wrote: >> >>>Hi Alia, >>> >>>Alia Atlas writes: >>> >>>> [Alia] First, I certainly agree that NetMod shouldn't wait until I2RS >>>>is finished. I do think that the routing model and the RIB info-model >>>>are trying to support different things. It may make sense that the >>>>routing model has higher abstractions, does different or additional >>>>configuration, and so on. That said, I >>> >>>Yes, NETCONF has configuration data that are not of direct interest to >>>I2RS. On the other hand, the I2RS data store could IMO be pretty much >>>the >>>same as the operational state data in NETCONF (config false in YANG >>>terms) - except that (parts of) it will be read-write for I2RS, whereas >>>for NETCONF it will be by definition read-only. This could include >>>routing tables, protocol databases etc. >> >> I like the idea. Maybe we could define an 'access-rights' statement that >> would determine whether a data node (or a subtree) is read-only or >> read-write. > >Yes, a simple YANG extension would do. >=20 >> >> A similar approach has been proposed by Rex Fernando et. al in >>=20 >>http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00#section-3.4, >> where they defined an 'ephemeral statement to address the same problem. > >Right, writable operational state data should probably be ephemeral by >definition. > >> >>> >>>> do think the RIB info-model draft is fairly accurate in describing >>>>what >>>>is needed for the RIB - and that can support a wide range of static >>>>routes. However, in routing, usually there are higher level >>>>abstractions that are applied for accuracy and ease; one can put an >>>>MPLS >>>>label on an outgoing packet - but this is frequently modeled as going >>>>into an LSP or a tunnel or connected to LDP's FECs or an L3VPN or so >>>>on. >>>> >>>> [Alia] What would be very interesting is the work that it sounds like >>>>Lada is already doing - investigating if there are missing features in >>>>YANG to support the types of info-models that I2RS >>>> is working on producing. At some point soon, I2RS will need to look >>>>at >>>>the requirements on data-modeling languages and understanding what is >>>>easy and hard to do in YANG and others. >>> >>>I haven't started such an investigation yet but I am prepared to do so. >> >> Some of this work has been done - please see >> http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00. > >We had a short meeting with the authors in Orlando, but a broader >discussion (perhaps in the NETMOD mailing list) might be useful. > >Ahoj, Lada > >> >> >> >> Thanks, >> Jan >> >>> >>>Lada >>> >>>> >>>> Alia >>>> >>>> >>> >>>--=20 >>>Ladislav Lhotka, CZ.NIC Labs >>>PGP Key ID: E74E8C0C >>>_______________________________________________ >>>netmod mailing list >>>netmod@ietf.org >>>https://www.ietf.org/mailman/listinfo/netmod >> > >--=20 >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Tue Aug 20 21:50:19 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB42F11E835F for ; Tue, 20 Aug 2013 21:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.224 X-Spam-Level: X-Spam-Status: No, score=-103.224 tagged_above=-999 required=5 tests=[AWL=0.025, 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 PPVoFEe8L03k for ; Tue, 20 Aug 2013 21:50:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BBC7711E815C for ; Tue, 20 Aug 2013 21:50:05 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 027F120C94; Wed, 21 Aug 2013 06:50:04 +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 18eT1vWZZsAr; Wed, 21 Aug 2013 06:50:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6EF8E20C93; Wed, 21 Aug 2013 06:50:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C470E27F5FBA; Wed, 21 Aug 2013 06:49:57 +0200 (CEST) Date: Wed, 21 Aug 2013 06:49:57 +0200 From: Juergen Schoenwaelder To: "Muthumayan Madhayyan (muthu)" Message-ID: <20130821044957.GA4650@elstar.local> Mail-Followup-To: "Muthumayan Madhayyan (muthu)" , Ladislav Lhotka , "Jan Medved (jmedved)" , Alia Atlas , "i2rs-chairs@tools.ietf.org" , Nitin Bahadur , "netmod@ietf.org" , "Alexander Clemm (alex)" References: <5A949C32AF740C4798AEECF2568F0D840C156729@xmb-rcd-x13.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A949C32AF740C4798AEECF2568F0D840C156729@xmb-rcd-x13.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" , Nitin Bahadur , Alia Atlas , "i2rs-chairs@tools.ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 04:50:24 -0000 On Tue, Aug 20, 2013 at 10:55:06PM +0000, Muthumayan Madhayyan (muthu) wrote: > Hello Lada, > > Apart from the ability to write ephemeral data, I2RS also has a > requirement to associate client ownership to data injected by an external > client. In NETCONF, the stores are global. > Well, this sounds like a NETCONF requirement, not a YANG requirement. /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 Wed Aug 21 08:50:47 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9B311E824F for ; Wed, 21 Aug 2013 08:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[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 alciwQvhsgzN for ; Wed, 21 Aug 2013 08:50:42 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 75DA811E8227 for ; Wed, 21 Aug 2013 08:50:42 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta04.westchester.pa.mail.comcast.net with comcast id FQHP1m0040cZkys54Tqhuw; Wed, 21 Aug 2013 15:50:41 +0000 Received: from [10.59.1.23] ([67.189.237.137]) by omta10.westchester.pa.mail.comcast.net with comcast id FTqf1m00V2yZEBF3WTqgEc; Wed, 21 Aug 2013 15:50:41 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Wed, 21 Aug 2013 11:50:32 -0400 From: David Harrington To: Juergen Schoenwaelder , "Muthumayan Madhayyan (muthu)" Message-ID: Thread-Topic: i2rs client ownership In-Reply-To: <20130821044957.GA4650@elstar.local> 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=1377100241; bh=15zs07fcXpbl3M2GheaMNYoYyFR0vX0lwwpcMTsczjk=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=sUlm0PclH/PYhXI+S9hsh4w5MiW/K3/k0Qi/D++Cmn00XPgfE/2pssFQF5ojBN+lw DtgvKuT6sSFJahubsadvDhIBJGGc8mGGHxk0XR1NhcpZXNrSmUz74QeRIEIw7Ro6Vg xmJf/BT2b9qPn+khFshV/fTthTYSKtBaDx1UFc8RtvUZ7WmljKCImivEwMWmDez3G9 Pw4+6wthifVlDylrS+/Mafw9ebRNLItxzeDpMqLY5U+QZjDhmASbavGxJM0xYwWH91 1quMm72itJ6FBxclCcWI3jfcGcLmqVVXCuV+DpDoobHayB7+0qkDUmA+28iOEbbZOr 9VCiAzsrNYdzw== Cc: Nitin Bahadur , Alia Atlas , "i2rs-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 15:50:47 -0000 Hi, I have some questions about this requirement to associate client ownership to injected data. 1) at what level of detail is the data ownership? Are we talking about specific subtrees in the datastore, or a complete datastore (e.g., a variation on candidate)? If we are talking ownership of a datastore, then this would seem to be a netconf requirement. If we are talking ownership of a row in a routing table, or something similar, then the ownership probably needs to be part of the data model, comparable to OwnerStrings in the MIB. 2) Can a client only assert their own ownership of a data subset, or can they assert that somebody else is the owner? For example, if an operator determines that a static route should be added to a routing table, based on looking at the hosts file of another node, can the operator set the ownership to be a URL to that file, or MUST the ownership be the ID for the user/operator who is setting the information? 3) If #2 requires the client-as-owner, must the client ID be authenticated? If the proposal uses NACM to perform the authentication, then you would presumably create a binding between the ACM mechanism (e.g., NACM) and the specific data model. 4) There has been discussion of trying to make YANG protocol independent. To maintain such independence, would the data model need to be written such that the user/client ID is protocol-independent? Could any ACM model be used to provide the user identity and authentication, not just NACM (and not just Netconf)? Compare for example, the ability for SNMPv3 to use multiple co-existing security models. Is this the direction this proposal would require? -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 8/21/13 12:49 AM, "Juergen Schoenwaelder" wrote: >On Tue, Aug 20, 2013 at 10:55:06PM +0000, Muthumayan Madhayyan (muthu) >wrote: >> Hello Lada, >> >> Apart from the ability to write ephemeral data, I2RS also has a >> requirement to associate client ownership to data injected by an >>external >> client. In NETCONF, the stores are global. >> > >Well, this sounds like a NETCONF requirement, not a YANG requirement. > >/js > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Wed Aug 21 09:28:34 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD1A21F9C40 for ; Wed, 21 Aug 2013 09:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HOST_EQ_CZ=0.904, 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 GhxqS7uGQ-qZ for ; Wed, 21 Aug 2013 09:28:29 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id D003011E8112 for ; Wed, 21 Aug 2013 09:28:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id BA1F154042C for ; Wed, 21 Aug 2013 18:28:21 +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 mE0RzODsR1hN for ; Wed, 21 Aug 2013 18:28:07 +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 C675F5400C8 for ; Wed, 21 Aug 2013 18:27:57 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 21 Aug 2013 18:27:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [netmod] comments to draft-clemm-netmod-yang-network-topo-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 16:28:34 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, here are my comments to the draft, oriented mainly on YANG aspects. It is a remarkable and promising work that might be generally useful, i.e. not only for I2RS. An interesting exercise would be to use an instance topology description and generate configurations of individual network nodes from it. The data model doesn't fit to the standard context of NETCONF client-server interaction. This shows that YANG can indeed be useful outside its original domain, and, at the same time, that certain YANG idiosyncrasies and CLRs mean complications for non-NETCONF data modelling (details follow). Specific comments: *** topology-type The use of XML element hierarchies is a clever alternative to YANG identities. Unlike identities, this works perfectly in standard XPath expressions, and also supports multiple inheritance. The only potential drawback is that the complete hierarchy of types has to be specified with each instance =E2=80=93 in this particular case it is not an issue though. *** config true/false It is difficult to decide a priori which nodes should be defined as configuration and which should be operational state. For example, one could imagine that the basic topology is given by the physical network (hence operational state) while the IGP topology and above can be configured. However, other possibilities are plausible, too. I'd suggest to ignore this disctinction for the time being, and define everything as configuration, which means there are almost no restrictions with respect to XPath context, leafrefs etc. *** augments The "augment" statement was originally intended for ad hoc and optional stuff, so augmenting mandatory nodes is not allowed. However, "augment" became an essential tool for building data models in a top-down way (not only in this case), and the "no-mandatory-nodes" rule is an annoying limitation. *** semantic constraints Many of the XPath expressions in "must" or "when" are incorrect. Attached is a diff file that shows improved versions (at least they work for my simple examples). In general, if a semantic constraint is to be applied to all list entries, it should be specified under the "list" node. Specifying it under the parent container usually means that it is sufficient to satisfy the constraint for a single entry. The "when" condition inside the grouping "ospf-prefix-attributes" (module "ospf-topology") seems completely broken. The explanations of the constraints should be moved from comments to "description" statements, and "error-message" should be specified, too. *** regex patterns The pattern for "iso-net-id" is invalid (the asterisk at the end): OLD pattern '[0-9a-fA-F]{2}((.[0-9a-fA-F]{4}){6}*)'; NEW pattern '[0-9a-fA-F]{2}((\.[0-9a-fA-F]{4}){6})'; Maybe it is legal to use "." (dot) unescaped in this case, but I'd suggest to escape it, just to be sure (also in "iso-system-id"). *** prefix of an imported module The module l3-unicast-igp-topology declares its prefix as "l3t" but the {ospf|isis}-topology modules import it with the prefix "igp". This should be avoided, also because it breaks some tools (I know, it shouldn't, but ...). *** additional containers I understand the lists "node" and "link" were not put into containers in order to keep the paths short. This could get quite messy though, because it means the lists can be interleaved with each other (and with other sibling elements, too). For example, this order is possible: link, node, link, topology-id, node, ... *** IGP metric The "metric" parameter could be defined separately in "ospf-topology" and "isis-topology", and specify the size (3 bytes) there, perhaps by means of refining a grouping defined in l3-unicast-igp-topology - see the comment inside the "igp-link-attributes" grouping. *** Minor nits - The module namespace URIs are inconsistent, some use the "TBD" component, some don't. - For link source and destination, shouldn't the source-tp/dest-tp leafs be mandatory? - Do the "supporting-*" nodes have to be containers with a "*-ref" leaf inside? - Using the "prefix" key for the "prefix" list is legal but maybe a little confusing. I'd suggest to rename the list to "prefix-spec" or similar. - Another "must" may be needed to ensure that router-ids are unique. - "underlay-topology" could be renamed to "supporting-topology" because it represents the same relationship as "supporting-{node|link= }". Lada --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=topology.diff Content-Description: diffs for topology modules diff --git a/isis-topology.yang b/isis-topology.yang index a633e39..57a44ee 100644 --- a/isis-topology.yang +++ b/isis-topology.yang @@ -7,7 +7,7 @@ module isis-topology { prefix nt; } import l3-unicast-igp-topology { - prefix igp; + prefix l3t; } import ted { prefix ted; @@ -47,26 +47,26 @@ module isis-topology { } } - augment "/nt:network-topology/nt:topology/nt:topology-types/igp:l3-unicast-igp-topology" { + augment "/nt:network-topology/nt:topology/nt:topology-types/l3t:l3-unicast-igp-topology" { uses isis-topology-type; } - augment "/nt:network-topology/nt:topology/igp:igp-topology-attributes" { - when "../../topology-types/isis"; - container isis-topogloy-attributes { + augment "/nt:network-topology/nt:topology/l3t:igp-topology-attributes" { + when "../nt:topology-types/l3t:l3-unicast-igp-topology/isis"; + container isis-topology-attributes { leaf net { type iso-net-id; } } } - augment "/nt:network-topology/nt:topology/nt:node/igp:igp-node-attributes" { - when "../../../topology-types/isis"; + augment "/nt:network-topology/nt:topology/nt:node/l3t:igp-node-attributes" { + when "../../nt:topology-types/l3t:l3-unicast-igp-topology/isis"; uses isis-node-attributes; } - augment "/nt:network-topology/nt:topology/nt:link/igp:igp-link-attributes" { - when "../../../../topology-types/isis"; + augment "/nt:network-topology/nt:topology/nt:link/l3t:igp-link-attributes" { + when "../../nt:topology-types/l3t:l3-unicast-igp-topology/isis"; uses isis-link-attributes; } @@ -128,12 +128,12 @@ module isis-topology { } } - augment "/igp:igp-node-event" { + augment "/l3t:igp-node-event" { uses isis-topology-type; uses isis-node-attributes; } - augment "/igp:igp-link-event" { + augment "/l3t:igp-link-event" { uses isis-topology-type; uses isis-link-attributes; } diff --git a/l3-unicast-igp-topology.yang b/l3-unicast-igp-topology.yang index 7f56a00..39b1699 100644 --- a/l3-unicast-igp-topology.yang +++ b/l3-unicast-igp-topology.yang @@ -153,20 +153,20 @@ module l3-unicast-igp-topology { } augment "/nt:network-topology/nt:topology" { - when "topology-types/l3-unicast-igp-topology"; + when "nt:topology-types/l3-unicast-igp-topology"; uses igp-topology-attributes; } augment "/nt:network-topology/nt:topology/nt:node" { - when "../../topology-types/l3-unicast-igp-topology"; + when "../nt:topology-types/l3-unicast-igp-topology"; uses igp-node-attributes; } augment "/nt:network-topology/nt:topology/nt:link" { - when "../../topology-types/l3-unicast-igp-topology"; + when "../nt:topology-types/l3-unicast-igp-topology"; uses igp-link-attributes; } augment "/nt:network-topology/nt:topology/nt:node/nt:termination-point" { - when "../../topology-types/l3-unicast-igp-topology"; + when "../../nt:topology-types/l3-unicast-igp-topology"; uses igp-termination-point-attributes; } diff --git a/network-topology.yang b/network-topology.yang index bc39aea..e42cd57 100644 --- a/network-topology.yang +++ b/network-topology.yang @@ -149,6 +149,9 @@ module network-topology { A node is specific to a topology to which it belongs."; } list supporting-node { + must "/network-topology/topology[topology-id = + current()/../../underlay-topology/topology-ref]/ + node[node-id = current()]"; description "This list defines vertical layering information for nodes. It allows to capture for any given node, which node (or nodes) @@ -206,6 +209,9 @@ module network-topology { } } list supporting-link { + must "/network-topology/topology[topology-id = + current()/../../underlay-topology/topology-ref]/ + link[link-id = current()]"; key "link-ref"; leaf link-ref { type link-ref; @@ -269,9 +275,6 @@ module network-topology { description "The list of network nodes defined for the topology."; key "node-id"; uses node-attributes; - must "boolean(../underlay-topology[*]/node[./supporting-nodes/node-ref])"; - // This constraint is meant to ensure that a referenced node is in fact - // a node in an underlay topology. list termination-point { description "A termination point can terminate a link. @@ -300,17 +303,20 @@ module network-topology { "; key "link-id"; uses link-attributes; - must "boolean(../underlay-topology/link[./supporting-link]"; - // Constraint: any supporting link must be part of an underlay topology - must "boolean(../node[./source/source-node])"; - // Constraint: A link must have as source a node of the same topology - must "boolean(../node[./destination/dest-node])"; - // Constraint: A link must have as source a destination of the same topology - must "boolean(../node/termination-point[./source/source-tp])"; - // Constraint: The source termination point must be contained in the source node - must "boolean(../node/termination-point[./destination/dest-tp])"; - // Constraint: The destination termination point must be contained - // in the destination node + must "../node[node-id = current()/source/source-node and + termination-point/tp-id = current()/source/source-tp]" { + description + "The source of a link must be a node in the same topology, + and the source termination point must be one of + termination points of that node."; + } + must "../node[node-id = current()/destination/dest-node and + termination-point/tp-id = current()/destination/dest-tp]" { + description + "The source of a link must be a node in the same topology, + and the source termination point must be one of + termination points of that node."; + } } } } diff --git a/ospf-topology.yang b/ospf-topology.yang index 7f3471f..0ab494b 100644 --- a/ospf-topology.yang +++ b/ospf-topology.yang @@ -9,7 +9,7 @@ module ospf-topology { } import l3-unicast-igp-topology { - prefix "igp"; + prefix "l3t"; } import ietf-inet-types { prefix "inet"; @@ -38,12 +38,12 @@ module ospf-topology { } } - augment "/nt:network-topology/nt:topology/nt:topology-types/igp:l3-unicast-igp-topology" { + augment "/nt:network-topology/nt:topology/nt:topology-types/l3t:l3-unicast-igp-topology" { uses ospf-topology-type; } - augment "/nt:network-topology/nt:topology/igp:igp-topology-attributes" { - when "../topology-types/ospf"; + augment "/nt:network-topology/nt:topology/l3t:igp-topology-attributes" { + when "../nt:topology-types/l3t:l3-unicast-igp-topology/ospf"; container ospf-topology-attributes { leaf area-id { type area-id; @@ -51,18 +51,18 @@ module ospf-topology { } } - augment "/nt:network-topology/nt:topology/nt:node/igp:igp-node-attributes" { - when "../../../topology-types/ospf"; + augment "/nt:network-topology/nt:topology/nt:node/l3t:igp-node-attributes" { + when "../../nt:topology-types/l3t:l3-unicast-igp-topology/ospf"; uses ospf-node-attributes; } - augment "/nt:network-topology/nt:topology/nt:link/igp:igp-link-attributes" { - when "../../../topology-types/ospf"; + augment "/nt:network-topology/nt:topology/nt:link/l3t:igp-link-attributes" { + when "../../nt:topology-types/l3t:l3-unicast-igp-topology/ospf"; uses ospf-link-attributes; } - augment "/nt:network-topology/nt:topology/nt:node/igp:igp-node-attributes/igp:prefix" { - when "../../../../topology-types/ospf"; + augment "/nt:network-topology/nt:topology/nt:node/l3t:igp-node-attributes/l3t:prefix" { + when "../../../nt:topology-types/l3t:l3-unicast-igp-topology/ospf"; uses ospf-prefix-attributes; } @@ -148,23 +148,23 @@ module ospf-topology { grouping ospf-prefix-attributes { container ospf-prefix-attributes { leaf forwarding-address { - when "../../igp:l3-unicast-igp-topology/igp:ospf/igp:router-type/igp:asbr"; + when "../../l3t:l3-unicast-igp-topology/l3t:ospf/l3t:router-type/l3t:asbr"; type inet:ipv4-address; } } } - augment "/igp:igp-node-event" { + augment "/l3t:igp-node-event" { uses ospf-topology-type; uses ospf:ospf-node-attributes; } - augment "/igp:igp-link-event" { + augment "/l3t:igp-link-event" { uses ospf-topology-type; uses ospf:ospf-link-attributes; } - augment "/igp:igp-prefix-event" { + augment "/l3t:igp-prefix-event" { uses ospf-topology-type; uses ospf:ospf-prefix-attributes; } diff --git a/ted.yang b/ted.yang index d39379b..7c4eba0 100644 --- a/ted.yang +++ b/ted.yang @@ -248,7 +248,7 @@ module ted { } } container packet-switch-capable { - when "../switching-capability = PSC-1 or ../switching-capability = PSC-2 or ../switching-capability = PSC-3 or ../switching-capability = PSC-4"; + when "../switching-capability = 'PSC-1' or ../switching-capability = 'PSC-2' or ../switching-capability = 'PSC-3' or ../switching-capability = 'PSC-4'"; description "Interface has packet-switching capabilities"; leaf minimum-lsp-bandwidth { @@ -265,7 +265,7 @@ module ted { } } container time-division-multiplex-capable { - when "../switching-capability = TDM"; + when "../switching-capability = 'TDM'"; description "Interface has time-division multiplex capabilities"; leaf minimum-lsp-bandwidth { --=-=-= -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C --=-=-=-- From muthu@cisco.com Thu Aug 22 09:58:08 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A788F11E80ED for ; Thu, 22 Aug 2013 09:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 wzSn8oUDvngI for ; Thu, 22 Aug 2013 09:58:04 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D541A21F9950 for ; Thu, 22 Aug 2013 09:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3459; q=dns/txt; s=iport; t=1377190684; x=1378400284; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=zxUA/1wEolkqNaLeeEXoP7+/KixZV7Ijfsi31uV8un0=; b=HhJxSIUeZaKlXnHL/3NtSzYveBzeim9UoKwWqf+ZJqq1ps5CSiShRj63 RAVKQkvcY5QNvbu3bqZ4z3LxHFHYke5pJxY3gyCIFq+2gAXeXmHqJ5T4+ CR8TABi1EZR4Jc+/svE4mlTsgRHi9ch2d5UDBvqRig6X8m3hqdkyWbsR+ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAPdBFlKtJV2b/2dsb2JhbABRBgODBzVRwAiBHRZ0giQBAQEEAQEBNzQLDgQBCA4CCAoUKwwLJQIEAQ0FCId2Aw8MrRMIiW0EjyCBESEQBxGDCnsDqUCDH4Ir X-IronPort-AV: E=Sophos;i="4.89,935,1367971200"; d="scan'208";a="250562215" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 22 Aug 2013 16:57:47 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7MGvk8c032423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Aug 2013 16:57:46 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.77]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 11:57:46 -0500 From: "Muthumayan Madhayyan (muthu)" To: David Harrington , Juergen Schoenwaelder Thread-Topic: i2rs client ownership Thread-Index: AQHOnoY+syzZo8WhDEyQwjy3WBRvYJmhTqUA Date: Thu, 22 Aug 2013 16:57:45 +0000 Message-ID: <5A949C32AF740C4798AEECF2568F0D840C15AE87@xmb-rcd-x13.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.21.144.119] Content-Type: text/plain; charset="us-ascii" Content-ID: <4F2B714A0D719446B4289EBAA2A5D841@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Nitin Bahadur , Alia Atlas , "i2rs-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 16:58:08 -0000 Hello David, Please see inline: On 8/21/13 8:50 AM, "David Harrington" wrote: >Hi, > >I have some questions about this requirement to associate client ownership >to injected data. > >1) at what level of detail is the data ownership? >Are we talking about specific subtrees in the datastore, or a complete >datastore (e.g., a variation on candidate)? >If we are talking ownership of a datastore, then this would seem to be a >netconf requirement. >If we are talking ownership of a row in a routing table, or something >similar, then the ownership probably needs to be part of the data model, >comparable to OwnerStrings in the MIB. The ownership is on a specific sub-tree and this is why we needed data model=20 to express it. > >2) Can a client only assert their own ownership of a data subset, or can >they assert that somebody else is the owner? Every subset created in runtime has an ownership tagged to it. Now, the client that created the data is the owner. If this data model states that the data subset is 'exclusive', then only the owner can modify or delete that subset. Else other clients can get read-write access to that any instance of the data sub-set created by another client. >For example, if an operator determines that a static route should be added >to a routing table, based on looking at the hosts file of another node, >can the operator set the ownership to be a URL to that file, or MUST the >ownership be the ID for the user/operator who is setting the information? As defined currently, it is the ID of the user/operator. > >3) If #2 requires the client-as-owner, must the client ID be >authenticated? If the proposal uses NACM to perform the authentication, >then you would presumably create a binding between the ACM mechanism >(e.g., NACM) and the specific data model. Yes, the intent was to tie NACM to do the authentication. > >4) There has been discussion of trying to make YANG protocol independent. >To maintain such independence, would the data model need to be written >such that the user/client ID is protocol-independent? Could any ACM model >be used to provide the user identity and authentication, not just NACM >(and not just Netconf)? Compare for example, the ability for SNMPv3 to use >multiple co-existing security models. Is this the direction this proposal >would require? Any ACM should do. It was just easier to extend NACM group settings to add a client priority. > >-- >David Harrington >Ietfdbh@comcast.net >+1-603-828-1401 > > > > > >On 8/21/13 12:49 AM, "Juergen Schoenwaelder" > wrote: > >>On Tue, Aug 20, 2013 at 10:55:06PM +0000, Muthumayan Madhayyan (muthu) >>wrote: >>> Hello Lada, >>>=20 >>> Apart from the ability to write ephemeral data, I2RS also has a >>> requirement to associate client ownership to data injected by an >>>external >>> client. In NETCONF, the stores are global. >>>=20 >> >>Well, this sounds like a NETCONF requirement, not a YANG requirement. >> >>/js >> >>--=20 >>Juergen Schoenwaelder Jacobs University Bremen gGmbH >>Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>Fax: +49 421 200 3103 >>_______________________________________________ >>netmod mailing list >>netmod@ietf.org >>https://www.ietf.org/mailman/listinfo/netmod > From j.schoenwaelder@jacobs-university.de Thu Aug 22 10:37:56 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC9821F9B11 for ; Thu, 22 Aug 2013 10:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.229 X-Spam-Level: X-Spam-Status: No, score=-103.229 tagged_above=-999 required=5 tests=[AWL=0.020, 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 uhStlxnJzI2c for ; Thu, 22 Aug 2013 10:37:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 359AD21F8904 for ; Thu, 22 Aug 2013 10:37:44 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4FA7B20CCE; Thu, 22 Aug 2013 19:37:43 +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 Upnv3f5QqCvz; Thu, 22 Aug 2013 19:37:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46C0E20CA0; Thu, 22 Aug 2013 19:37:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C2C3827FC269; Thu, 22 Aug 2013 19:37:34 +0200 (CEST) Date: Thu, 22 Aug 2013 19:37:34 +0200 From: Juergen Schoenwaelder To: "Muthumayan Madhayyan (muthu)" Message-ID: <20130822173732.GB7508@elstar.local> Mail-Followup-To: "Muthumayan Madhayyan (muthu)" , David Harrington , "netmod@ietf.org" , Nitin Bahadur , Alia Atlas , "i2rs-chairs@tools.ietf.org" References: <5A949C32AF740C4798AEECF2568F0D840C15AE87@xmb-rcd-x13.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A949C32AF740C4798AEECF2568F0D840C15AE87@xmb-rcd-x13.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alia Atlas , Nitin Bahadur , "i2rs-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 17:37:56 -0000 On Thu, Aug 22, 2013 at 04:57:45PM +0000, Muthumayan Madhayyan (muthu) wrote: > Hello David, > > Please see inline: > > On 8/21/13 8:50 AM, "David Harrington" wrote: > > >Hi, > > > >I have some questions about this requirement to associate client ownership > >to injected data. > > > >1) at what level of detail is the data ownership? > >Are we talking about specific subtrees in the datastore, or a complete > >datastore (e.g., a variation on candidate)? > >If we are talking ownership of a datastore, then this would seem to be a > >netconf requirement. > >If we are talking ownership of a row in a routing table, or something > >similar, then the ownership probably needs to be part of the data model, > >comparable to OwnerStrings in the MIB. > > The ownership is on a specific sub-tree and this is why we needed data > model > to express it. > > > >2) Can a client only assert their own ownership of a data subset, or can > >they assert that somebody else is the owner? > > > Every subset created in runtime has an ownership tagged to it. Now, the > client that created the data is the owner. If this data model states that > the data subset is 'exclusive', then only the owner can modify or delete > that subset. Else other clients can get read-write access to that any > instance of the data sub-set created by another client. > > > >For example, if an operator determines that a static route should be added > >to a routing table, based on looking at the hosts file of another node, > >can the operator set the ownership to be a URL to that file, or MUST the > >ownership be the ID for the user/operator who is setting the information? > > As defined currently, it is the ID of the user/operator. > I am confused. Lets see. If an I2RS client creates a 'foo' in operational state, then I think you want 'foo' associated with the identifier 'joe' representing the identity of the client. Is that automatic (the mere fact that the client authenticated as 'joe' means 'foo' belongs to 'joe') or do you want 'joe' to be explicit, that is joe actually says "create 'foo' owned by 'joe'"? > >3) If #2 requires the client-as-owner, must the client ID be > >authenticated? If the proposal uses NACM to perform the authentication, > >then you would presumably create a binding between the ACM mechanism > >(e.g., NACM) and the specific data model. > > Yes, the intent was to tie NACM to do the authentication. I am confused. NACM does authorization, not authentication. If you want to restrict access to 'foo' to 'joe', NACM would need a rule that says access to 'foo' is restricted to 'joe'. Depending on the answer to 2), the question is how the rule is being injected into NACM (if you were to use NACM and NACM would apply to writable operational state). But then, NACM - as far as I understand it - can only perform access decisions on data that is explicit in the data model. I am actually not sure you want to 'clutter' all your data models with additional leafs to express ownership - this really smells much more like meta-data. > >4) There has been discussion of trying to make YANG protocol independent. > >To maintain such independence, would the data model need to be written > >such that the user/client ID is protocol-independent? Could any ACM model > >be used to provide the user identity and authentication, not just NACM > >(and not just Netconf)? Compare for example, the ability for SNMPv3 to use > >multiple co-existing security models. Is this the direction this proposal > >would require? > > Any ACM should do. It was just easier to extend NACM group settings to add > a client priority. Hm. It might be good to work out a more detailed example of what I2RS may want. Or can someone point to the parts of the architecture I-D where this is clearly described? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From akatlas@juniper.net Thu Aug 22 11:14:09 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7ADC11E81BA for ; Thu, 22 Aug 2013 11:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 QPmO03XjrdDE for ; Thu, 22 Aug 2013 11:14:04 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 1989811E8106 for ; Thu, 22 Aug 2013 11:14:04 -0700 (PDT) Received: from mail9-co1-R.bigfish.com (10.243.78.231) by CO1EHSOBE029.bigfish.com (10.243.66.94) with Microsoft SMTP Server id 14.1.225.22; Thu, 22 Aug 2013 18:14:03 +0000 Received: from mail9-co1 (localhost [127.0.0.1]) by mail9-co1-R.bigfish.com (Postfix) with ESMTP id A334D900170; Thu, 22 Aug 2013 18:14:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI98dI9371I542I1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah1de096h8275dh1de097hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail9-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=akatlas@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(479174003)(377454003)(24454002)(13464003)(51704005)(199002)(189002)(76796001)(81342001)(69226001)(31966008)(76576001)(65816001)(76786001)(80022001)(54356001)(66066001)(76482001)(51856001)(46102001)(77982001)(59766001)(47736001)(47976001)(81542001)(4396001)(49866001)(53806001)(63696002)(79102001)(33646001)(74366001)(81816001)(74502001)(47446002)(74706001)(74662001)(50986001)(74316001)(56816003)(561944002)(74876001)(80976001)(81686001)(19580395003)(56776001)(54316002)(19580405001)(83322001)(77096001)(83072001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB052; H:BL2PR05MB193.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail9-co1 (localhost.localdomain [127.0.0.1]) by mail9-co1 (MessageSwitch) id 1377195240854421_30689; Thu, 22 Aug 2013 18:14:00 +0000 (UTC) Received: from CO1EHSMHS022.bigfish.com (unknown [10.243.78.251]) by mail9-co1.bigfish.com (Postfix) with ESMTP id C883C9E004F; Thu, 22 Aug 2013 18:14:00 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS022.bigfish.com (10.243.66.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 22 Aug 2013 18:14:00 +0000 Received: from BL2PR05MB052.namprd05.prod.outlook.com (10.255.228.156) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.347.3; Thu, 22 Aug 2013 18:14:00 +0000 Received: from BL2PR05MB193.namprd05.prod.outlook.com (10.242.198.143) by BL2PR05MB052.namprd05.prod.outlook.com (10.255.228.156) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 22 Aug 2013 18:13:59 +0000 Received: from BL2PR05MB193.namprd05.prod.outlook.com ([169.254.9.249]) by BL2PR05MB193.namprd05.prod.outlook.com ([169.254.9.249]) with mapi id 15.00.0745.000; Thu, 22 Aug 2013 18:13:59 +0000 From: Alia Atlas To: Juergen Schoenwaelder , "Muthumayan Madhayyan (muthu)" Thread-Topic: i2rs client ownership Thread-Index: AQHOnoZEcTLC2m5QM0Cu3jp6MtVMc5mhdGWAgAALIACAAAhcgA== Date: Thu, 22 Aug 2013 18:13:59 +0000 Message-ID: <919fea51f182429b910962784a9e75fd@BL2PR05MB193.namprd05.prod.outlook.com> References: <5A949C32AF740C4798AEECF2568F0D840C15AE87@xmb-rcd-x13.cisco.com> <20130822173732.GB7508@elstar.local> In-Reply-To: <20130822173732.GB7508@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0946DC87A1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Nitin Bahadur , "i2rs-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 18:14:10 -0000 Hi Juergen, I agree that the ownership of data seems more like meta-data to me than any= thing else. I really would prefer not to clutter the data-models with it. I think there are two (at least!) separate aspects that we need to figure o= ut. One is the permissions aspect - where we need to be able to clearly ex= press what scope a particular role has. The second is what an i2rs agent n= eeds to store, manipulate, and report back. For the latter, the basic concept is described in draft-ietf-i2rs-architect= ure-00 split across Sec 5.2, 6.8, and 6.4 (which discusses identity). In S= ec 5.2, it says: "The I2RS agent stores the set of operations it has applied. Simply, the I2RS agent stores who did what operation to which entity. New changes replace any data about old ones. If an I2RS client does an operation to remove some state, that state is removed and the I2RS agent stores no more information about it. This allows any interested party to determine what the current effect of I2RS on the system is, and why. Meaningful logging is also recommended." Alia -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, August 22, 2013 1:38 PM To: Muthumayan Madhayyan (muthu) Cc: David Harrington; netmod@ietf.org; Nitin Bahadur; Alia Atlas; i2rs-chai= rs@tools.ietf.org Subject: Re: i2rs client ownership On Thu, Aug 22, 2013 at 04:57:45PM +0000, Muthumayan Madhayyan (muthu) wrot= e: > Hello David, >=20 > Please see inline: >=20 > On 8/21/13 8:50 AM, "David Harrington" wrote: >=20 > >Hi, > > > >I have some questions about this requirement to associate client=20 > >ownership to injected data. > > > >1) at what level of detail is the data ownership? > >Are we talking about specific subtrees in the datastore, or a=20 > >complete datastore (e.g., a variation on candidate)? > >If we are talking ownership of a datastore, then this would seem to=20 > >be a netconf requirement. > >If we are talking ownership of a row in a routing table, or something=20 > >similar, then the ownership probably needs to be part of the data=20 > >model, comparable to OwnerStrings in the MIB. >=20 > The ownership is on a specific sub-tree and this is why we needed data=20 > model to express it. > > > >2) Can a client only assert their own ownership of a data subset, or=20 > >can they assert that somebody else is the owner? >=20 >=20 > Every subset created in runtime has an ownership tagged to it. Now,=20 > the client that created the data is the owner. If this data model=20 > states that the data subset is 'exclusive', then only the owner can=20 > modify or delete that subset. Else other clients can get read-write=20 > access to that any instance of the data sub-set created by another client= . >=20 >=20 > >For example, if an operator determines that a static route should be=20 > >added to a routing table, based on looking at the hosts file of=20 > >another node, can the operator set the ownership to be a URL to that=20 > >file, or MUST the ownership be the ID for the user/operator who is setti= ng the information? >=20 > As defined currently, it is the ID of the user/operator. >=20 I am confused. Lets see. If an I2RS client creates a 'foo' in operational s= tate, then I think you want 'foo' associated with the identifier 'joe' repr= esenting the identity of the client. Is that automatic (the mere fact that = the client authenticated as 'joe' means 'foo' belongs to 'joe') or do you w= ant 'joe' to be explicit, that is joe actually says "create 'foo' owned by = 'joe'"? > >3) If #2 requires the client-as-owner, must the client ID be=20 > >authenticated? If the proposal uses NACM to perform the=20 > >authentication, then you would presumably create a binding between=20 > >the ACM mechanism (e.g., NACM) and the specific data model. >=20 > Yes, the intent was to tie NACM to do the authentication. I am confused. NACM does authorization, not authentication. If you want to = restrict access to 'foo' to 'joe', NACM would need a rule that says access = to 'foo' is restricted to 'joe'. Depending on the answer to 2), the questio= n is how the rule is being injected into NACM (if you were to use NACM and = NACM would apply to writable operational state). But then, NACM - as far as= I understand it - can only perform access decisions on data that is explic= it in the data model. I am actually not sure you want to 'clutter' all your= data models with additional leafs to express ownership - this really smell= s much more like meta-data. > >4) There has been discussion of trying to make YANG protocol independent= . > >To maintain such independence, would the data model need to be=20 > >written such that the user/client ID is protocol-independent? Could=20 > >any ACM model be used to provide the user identity and=20 > >authentication, not just NACM (and not just Netconf)? Compare for=20 > >example, the ability for SNMPv3 to use multiple co-existing security=20 > >models. Is this the direction this proposal would require? >=20 > Any ACM should do. It was just easier to extend NACM group settings to=20 > add a client priority. Hm. It might be good to work out a more detailed example of what I2RS may w= ant. Or can someone point to the parts of the architecture I-D where this i= s clearly described? /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Aug 22 11:48:20 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EBB11E815C for ; Thu, 22 Aug 2013 11:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.23 X-Spam-Level: X-Spam-Status: No, score=-103.23 tagged_above=-999 required=5 tests=[AWL=0.019, 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 LNBKYitffRNl for ; Thu, 22 Aug 2013 11:48:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 94A7021F9D53 for ; Thu, 22 Aug 2013 11:48:14 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2786420CC6; Thu, 22 Aug 2013 20:48:13 +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 iOvnQFTJJDPB; Thu, 22 Aug 2013 20:48:13 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B98920C9F; Thu, 22 Aug 2013 20:48:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AF15527FC3EA; Thu, 22 Aug 2013 20:48:03 +0200 (CEST) Date: Thu, 22 Aug 2013 20:48:02 +0200 From: Juergen Schoenwaelder To: Alia Atlas Message-ID: <20130822184800.GA7809@elstar.local> Mail-Followup-To: Alia Atlas , "Muthumayan Madhayyan (muthu)" , David Harrington , "netmod@ietf.org" , Nitin Bahadur , "i2rs-chairs@tools.ietf.org" References: <5A949C32AF740C4798AEECF2568F0D840C15AE87@xmb-rcd-x13.cisco.com> <20130822173732.GB7508@elstar.local> <919fea51f182429b910962784a9e75fd@BL2PR05MB193.namprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <919fea51f182429b910962784a9e75fd@BL2PR05MB193.namprd05.prod.outlook.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Nitin Bahadur , "i2rs-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 18:48:21 -0000 On Thu, Aug 22, 2013 at 06:13:59PM +0000, Alia Atlas wrote: > Hi Juergen, > > I agree that the ownership of data seems more like meta-data to me than anything else. I really would prefer not to clutter the data-models with it. > > I think there are two (at least!) separate aspects that we need to figure out. One is the permissions aspect - where we need to be able to clearly express what scope a particular role has. As defined in section 3.3.5 of RFC 6536, NACM has four types of access control rules: module rule: controls access for definitions in a specific YANG module, identified by its name. protocol operation rule: controls access for a specific protocol operation, identified by its YANG module and name. data node rule: controls access for a specific data node, identified by its path location within the conceptual XML document for the data node. notification rule: controls access for a specific notification event type, identified by its YANG module and name. What I hear you saying is that I2RS likes to have access control rules based on the concept of 'ownership' of data (where a client creating a piece of data implicitely gets the ownership over that piece of data). If this is what I2RS indeed requires, I would say NACM does not yet provide this and in general NETCONF does not provide a clean means to deal with such metadata (although there seem to be proposals and running code out there). > The second is what an i2rs agent needs to store, manipulate, and report back. > > For the latter, the basic concept is described in draft-ietf-i2rs-architecture-00 split across Sec 5.2, 6.8, and 6.4 (which discusses identity). In Sec 5.2, it says: > > "The I2RS agent stores the set of > operations it has applied. Simply, the I2RS agent stores who did > what operation to which entity. New changes replace any data about > old ones. If an I2RS client does an operation to remove some state, > that state is removed and the I2RS agent stores no more information > about it. This allows any interested party to determine what the > current effect of I2RS on the system is, and why. Meaningful logging > is also recommended." > Yep, but this thread is about ownership and permissions. And section 3.4 of the I2RS architecture could perhaps be a bit more explicit concering state ownership and authorization. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jmedved@cisco.com Thu Aug 22 14:08:57 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5C811E811E for ; Thu, 22 Aug 2013 14:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 PcDXnOzt0231 for ; Thu, 22 Aug 2013 14:08:53 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6479011E8124 for ; Thu, 22 Aug 2013 14:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6281; q=dns/txt; s=iport; t=1377205723; x=1378415323; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+XAA4UOs984SyqZCwDg3arpNoFPm5pQ3d8URWL5PNlU=; b=SrWSZfvrknxmUBQcrRlgB2/hs06a4XlxXiKKw/o3AyyNgxFI50U5cph1 Ia3QpiJzBXCxy3oGc/c4F+vxCgC6a45qsLveE3wdew/ynBeUos2o6n59X 4PMqHfmrAa+KSVCL/1ZxNMzsipxbc2kcGtdvgZs2WTVZHnn4HyhJ594a+ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAM18FlKtJV2b/2dsb2JhbABRBgODBzVRwAuBHRZ0giQBAQEDAQEBATc0CwUHAgQBCA4CAQEDAQEBChQJIgwLFAMGCAIEAQ0FCId2AwkGDK0MCIltBI8ggREhEAcGC4MKewOpQIMfgis X-IronPort-AV: E=Sophos;i="4.89,936,1367971200"; d="scan'208";a="250675536" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 22 Aug 2013 21:08:42 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7ML8gED021412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Aug 2013 21:08:42 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.56]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 16:08:42 -0500 From: "Jan Medved (jmedved)" To: Alia Atlas , Juergen Schoenwaelder , "Muthumayan Madhayyan (muthu)" Thread-Topic: [netmod] i2rs client ownership Thread-Index: AQHOn2NoQ+Adz5ekfUGn0kuI+JV/h5mhlz8A Date: Thu, 22 Aug 2013 21:08:42 +0000 Message-ID: In-Reply-To: <919fea51f182429b910962784a9e75fd@BL2PR05MB193.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.86.241.53] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Nitin Bahadur , "i2rs-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 21:08:58 -0000 Hi Alia, On 8/22/13 11:13 AM, "Alia Atlas" wrote: >Hi Juergen, > >I agree that the ownership of data seems more like meta-data to me than >anything else. I really would prefer not to clutter the data-models with >it. It depends. If ownership is coarse grained, then having the ownership metadata in a separate tree is manageable. If it's fine-grained, having the ownership metadata embedded in the data tree is easier - both for the server as well as for the clients. I think with I2RS, ownership will likely be fine-grained. > >I think there are two (at least!) separate aspects that we need to figure >out. One is the permissions aspect - where we need to be able to clearly >express what scope a particular role has. Agreed.=20 > The second is what an i2rs agent needs to store, manipulate, and report >back. > >For the latter, the basic concept is described in >draft-ietf-i2rs-architecture-00 split across Sec 5.2, 6.8, and 6.4 (which >discusses identity). In Sec 5.2, it says: > > "The I2RS agent stores the set of > operations it has applied. Simply, the I2RS agent stores who did > what operation to which entity. New changes replace any data about > old ones. If an I2RS client does an operation to remove some state, > that state is removed and the I2RS agent stores no more information > about it. This allows any interested party to determine what the > current effect of I2RS on the system is, and why. Meaningful logging > is also recommended." > >Alia /Jan > >-----Original Message----- >From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >Sent: Thursday, August 22, 2013 1:38 PM >To: Muthumayan Madhayyan (muthu) >Cc: David Harrington; netmod@ietf.org; Nitin Bahadur; Alia Atlas; >i2rs-chairs@tools.ietf.org >Subject: Re: i2rs client ownership > >On Thu, Aug 22, 2013 at 04:57:45PM +0000, Muthumayan Madhayyan (muthu) >wrote: >> Hello David, >>=20 >> Please see inline: >>=20 >> On 8/21/13 8:50 AM, "David Harrington" wrote: >>=20 >> >Hi, >> > >> >I have some questions about this requirement to associate client >> >ownership to injected data. >> > >> >1) at what level of detail is the data ownership? >> >Are we talking about specific subtrees in the datastore, or a >> >complete datastore (e.g., a variation on candidate)? >> >If we are talking ownership of a datastore, then this would seem to >> >be a netconf requirement. >> >If we are talking ownership of a row in a routing table, or something >> >similar, then the ownership probably needs to be part of the data >> >model, comparable to OwnerStrings in the MIB. >>=20 >> The ownership is on a specific sub-tree and this is why we needed data >> model to express it. >> > >> >2) Can a client only assert their own ownership of a data subset, or >> >can they assert that somebody else is the owner? >>=20 >>=20 >> Every subset created in runtime has an ownership tagged to it. Now, >> the client that created the data is the owner. If this data model >> states that the data subset is 'exclusive', then only the owner can >> modify or delete that subset. Else other clients can get read-write >> access to that any instance of the data sub-set created by another >>client. >>=20 >>=20 >> >For example, if an operator determines that a static route should be >> >added to a routing table, based on looking at the hosts file of >> >another node, can the operator set the ownership to be a URL to that >> >file, or MUST the ownership be the ID for the user/operator who is >>setting the information? >>=20 >> As defined currently, it is the ID of the user/operator. >>=20 > >I am confused. Lets see. If an I2RS client creates a 'foo' in operational >state, then I think you want 'foo' associated with the identifier 'joe' >representing the identity of the client. Is that automatic (the mere fact >that the client authenticated as 'joe' means 'foo' belongs to 'joe') or >do you want 'joe' to be explicit, that is joe actually says "create 'foo' >owned by 'joe'"? > >> >3) If #2 requires the client-as-owner, must the client ID be >> >authenticated? If the proposal uses NACM to perform the >> >authentication, then you would presumably create a binding between >> >the ACM mechanism (e.g., NACM) and the specific data model. >>=20 >> Yes, the intent was to tie NACM to do the authentication. > >I am confused. NACM does authorization, not authentication. If you want >to restrict access to 'foo' to 'joe', NACM would need a rule that says >access to 'foo' is restricted to 'joe'. Depending on the answer to 2), >the question is how the rule is being injected into NACM (if you were to >use NACM and NACM would apply to writable operational state). But then, >NACM - as far as I understand it - can only perform access decisions on >data that is explicit in the data model. I am actually not sure you want >to 'clutter' all your data models with additional leafs to express >ownership - this really smells much more like meta-data. > >> >4) There has been discussion of trying to make YANG protocol >>independent. >> >To maintain such independence, would the data model need to be >> >written such that the user/client ID is protocol-independent? Could >> >any ACM model be used to provide the user identity and >> >authentication, not just NACM (and not just Netconf)? Compare for >> >example, the ability for SNMPv3 to use multiple co-existing security >> >models. Is this the direction this proposal would require? >>=20 >> Any ACM should do. It was just easier to extend NACM group settings to >> add a client priority. > >Hm. It might be good to work out a more detailed example of what I2RS may >want. Or can someone point to the parts of the architecture I-D where >this is clearly described? > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 > > > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Thu Aug 22 15:36:23 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D27411E822F for ; Thu, 22 Aug 2013 15:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.350, 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 J7eHvTYShYof for ; Thu, 22 Aug 2013 15:36:16 -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 3717211E822A for ; Thu, 22 Aug 2013 15:36:16 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so2415677pbc.35 for ; Thu, 22 Aug 2013 15:36:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dUoEIKfCC/6B7qGXNo5T/LqR1LVewSG2nXz5ZKOAzWM=; b=Ibu9ShA9WQh/OcDm5vj34zoZDKolP/oEpT12uDJHk/acSvmgtv0QtDAdl7zk5vDzb/ NWzbRtLU42KvjAhle4IJX+4A1tkQ9XegL6rYQz+je9cIxrtIw+EtkWR6SMGv9YVAdzC4 ibCj7PhB/LvN0gs9xtAOmHtMupfRJ4sEYtcYhoXWLwzyJCJ7TEG+wQ689xE61kwRY9fn 2EtKROnHxTFrAn0DEyP6s6Ls6zAbTismdFkRX6wSLVsdsQuMZkJvLyfGPU4yeeWubLv1 cHf5kBTuMQtxUBFKqbwj39ZC0QYo2tI8T7gMMRSDHjheDsDrLX0cNaEDMCZ5dCoeJ5wm nhUA== X-Gm-Message-State: ALoCoQk7sEqtKYQZEjpFscq8IwHzIACeYUivLVkHyo0UYnWJa4LpZnFfg38JWPH0LI6MPgZxhm+M MIME-Version: 1.0 X-Received: by 10.66.250.47 with SMTP id yz15mr7871031pac.154.1377210975819; Thu, 22 Aug 2013 15:36:15 -0700 (PDT) Received: by 10.70.41.162 with HTTP; Thu, 22 Aug 2013 15:36:15 -0700 (PDT) In-Reply-To: References: <919fea51f182429b910962784a9e75fd@BL2PR05MB193.namprd05.prod.outlook.com> Date: Thu, 22 Aug 2013 15:36:15 -0700 Message-ID: From: Andy Bierman To: "Jan Medved (jmedved)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "netmod@ietf.org" , Nitin Bahadur , Alia Atlas , "i2rs-chairs@tools.ietf.org" Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 22:36:23 -0000 On Thu, Aug 22, 2013 at 2:08 PM, Jan Medved (jmedved) wrote: > Hi Alia, > > On 8/22/13 11:13 AM, "Alia Atlas" wrote: > >>Hi Juergen, >> >>I agree that the ownership of data seems more like meta-data to me than >>anything else. I really would prefer not to clutter the data-models with >>it. > > It depends. If ownership is coarse grained, then having the ownership > metadata in a separate tree is manageable. If it's fine-grained, having > the ownership metadata embedded in the data tree is easier - both for the > server as well as for the clients. > > I think with I2RS, ownership will likely be fine-grained. > I think this "owner" concept needs a lot more work. If owner 1 has a higher priority than owner 2, then owner 1 can clobber anything that owner 2 already created. That doesn't sound fine-grained to me. The "first one wins" concept only applies to clients with the same priority. The "last one wins" problem is addressed by assigning priorities to the clients. Now it is "highest priority wins" which is what is desired. If the client writing existing data has the same or lower priority as the owner that set the data, then the access is denied. (Problem solved, first one wins). NACM would need some changes to support owner priority. The augments that has been proposed is insufficient: http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00#section-3.6 (IMO, only sec. 3.6 of this draft is needed.) >> >>I think there are two (at least!) separate aspects that we need to figure >>out. One is the permissions aspect - where we need to be able to clearly >>express what scope a particular role has. > > Agreed. > >> The second is what an i2rs agent needs to store, manipulate, and report >>back. >> >>For the latter, the basic concept is described in >>draft-ietf-i2rs-architecture-00 split across Sec 5.2, 6.8, and 6.4 (which >>discusses identity). In Sec 5.2, it says: >> >> "The I2RS agent stores the set of >> operations it has applied. Simply, the I2RS agent stores who did >> what operation to which entity. New changes replace any data about >> old ones. If an I2RS client does an operation to remove some state, >> that state is removed and the I2RS agent stores no more information >> about it. This allows any interested party to determine what the >> current effect of I2RS on the system is, and why. Meaningful logging >> is also recommended." If a client is really a broker, then is the owner string going to be for the upstream application or the broker? Which clients are likely to have the same priority and collide on the same data? >> >>Alia > > /Jan Andy From andy@yumaworks.com Fri Aug 23 07:25:48 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254CA11E82FF for ; Fri, 23 Aug 2013 07:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=-0.189, 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 D91SbrvZ8HJK for ; Fri, 23 Aug 2013 07:25:43 -0700 (PDT) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1999811E82F7 for ; Fri, 23 Aug 2013 07:25:43 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id r10so744300pdi.14 for ; Fri, 23 Aug 2013 07:25:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=7L+ZZ/TxULaPlvjBnoOQejX0ljyLL+TW9urbmj75U+s=; b=b9KhZa1V2Mq4Y/qUxTsfihfcnnworYO+M1qOxi2vObmwYR2xBOQLvrbJeGbkPj8ubO rpxLd/PJM7ogNnUrwiCWL8vYYp4L6BRtyKrKQmhrQnxiwfm2Ipu9ptJ8armvUjqCRHo2 /YoDpSmLmCIpcAr2zwZhREMACHW7OQYcXFru8FE52pEZHT1cyleqVvEZX+2eMI/e+0jz R17zsPR7GxBbM+JAwXXLZePFScuSaPHwYhhU790fwTNOdx2EVHtgZzyJWFu0HInFAXMR OOGKObys10gzJ+pqVND+75rZ8kgiVHDcbz/ldMWtfQ3QkD63dfVqwjgV+xBVKi0ixaWM fZIw== X-Gm-Message-State: ALoCoQloA1/6dsMpZaZPWlmuRxGcB2DwC1FZT9PQaVWPJQ7+2F5chGKKBJ0e1+eJiETKK7ZIeDxB MIME-Version: 1.0 X-Received: by 10.66.161.38 with SMTP id xp6mr11286347pab.145.1377267942717; Fri, 23 Aug 2013 07:25:42 -0700 (PDT) Received: by 10.70.41.162 with HTTP; Fri, 23 Aug 2013 07:25:42 -0700 (PDT) In-Reply-To: <20130821044957.GA4650@elstar.local> References: <5A949C32AF740C4798AEECF2568F0D840C156729@xmb-rcd-x13.cisco.com> <20130821044957.GA4650@elstar.local> Date: Fri, 23 Aug 2013 07:25:42 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Muthumayan Madhayyan (muthu)" , Ladislav Lhotka , "Jan Medved (jmedved)" , Alia Atlas , "i2rs-chairs@tools.ietf.org" , Nitin Bahadur , "netmod@ietf.org" , "Alexander Clemm (alex)" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 14:25:48 -0000 On Tue, Aug 20, 2013 at 9:49 PM, Juergen Schoenwaelder wrote: > On Tue, Aug 20, 2013 at 10:55:06PM +0000, Muthumayan Madhayyan (muthu) wrote: >> Hello Lada, >> >> Apart from the ability to write ephemeral data, I2RS also has a >> requirement to associate client ownership to data injected by an external >> client. In NETCONF, the stores are global. >> > > Well, this sounds like a NETCONF requirement, not a YANG requirement. +1 The owner is a property of the datastore, not the data model. Ditto for the "ephemeral" YANG extension. I don't see the need for any YANG extensions, just protocol extensions. > > /js Andy From jmh@joelhalpern.com Sat Aug 24 02:31:41 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F35921F9E83 for ; Sat, 24 Aug 2013 02:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-+tulEqBkHC for ; Sat, 24 Aug 2013 02:31:36 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 9372921F9E63 for ; Sat, 24 Aug 2013 02:31:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 99B001BC963A; Sat, 24 Aug 2013 02:31:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 066531BC9623; Sat, 24 Aug 2013 02:31:33 -0700 (PDT) Message-ID: <52187D76.2030001@joelhalpern.com> Date: Sat, 24 Aug 2013 05:31:34 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andy Bierman References: <919fea51f182429b910962784a9e75fd@BL2PR05MB193.namprd05.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alia Atlas , Nitin Bahadur , "i2rs-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 09:31:41 -0000 For me, "ownership" of data is not a helpful way to think about this. (It is not incorrect, just unhelpful.) Rather, the base concept is that two different clients should not be writing the same data in the same time period. (i.e. from when the first one writes it until he removes his modification.) When this fails, it is an error. We need to detect this error. So the I2RS Agent is required to keep track of enough information to detect and provide a predictable behavior in the event this occurs. The priority mechanism is a mechanism for providing better predictability. If we don't like it, we can ditch it. In particular, one corrollary of this is that "ownership" does not, it seems to me, belong in the data model. It is, as Alia and other said, metadata. Yours, Joel On 8/22/13 6:36 PM, Andy Bierman wrote: > On Thu, Aug 22, 2013 at 2:08 PM, Jan Medved (jmedved) wrote: >> Hi Alia, >> >> On 8/22/13 11:13 AM, "Alia Atlas" wrote: >> >>> Hi Juergen, >>> >>> I agree that the ownership of data seems more like meta-data to me than >>> anything else. I really would prefer not to clutter the data-models with >>> it. >> >> It depends. If ownership is coarse grained, then having the ownership >> metadata in a separate tree is manageable. If it's fine-grained, having >> the ownership metadata embedded in the data tree is easier - both for the >> server as well as for the clients. >> >> I think with I2RS, ownership will likely be fine-grained. >> > > I think this "owner" concept needs a lot more work. > If owner 1 has a higher priority than owner 2, then owner 1 can clobber > anything that owner 2 already created. That doesn't sound fine-grained > to me. > > The "first one wins" concept only applies to clients with the same priority. > The "last one wins" problem is addressed by assigning priorities to the clients. > Now it is "highest priority wins" which is what is desired. > > If the client writing existing data has the same or lower priority as the owner > that set the data, then the access is denied. (Problem solved, first one wins). > NACM would need some changes to support owner priority. > The augments that has been proposed is insufficient: > http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00#section-3.6 > > (IMO, only sec. 3.6 of this draft is needed.) > > >>> >>> I think there are two (at least!) separate aspects that we need to figure >>> out. One is the permissions aspect - where we need to be able to clearly >>> express what scope a particular role has. >> >> Agreed. >> >>> The second is what an i2rs agent needs to store, manipulate, and report >>> back. >>> >>> For the latter, the basic concept is described in >>> draft-ietf-i2rs-architecture-00 split across Sec 5.2, 6.8, and 6.4 (which >>> discusses identity). In Sec 5.2, it says: >>> >>> "The I2RS agent stores the set of >>> operations it has applied. Simply, the I2RS agent stores who did >>> what operation to which entity. New changes replace any data about >>> old ones. If an I2RS client does an operation to remove some state, >>> that state is removed and the I2RS agent stores no more information >>> about it. This allows any interested party to determine what the >>> current effect of I2RS on the system is, and why. Meaningful logging >>> is also recommended." > > > If a client is really a broker, then is the owner string going to be for the > upstream application or the broker? Which clients are likely to > have the same priority and collide on the same data? > > >>> >>> Alia >> >> /Jan > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From andy@yumaworks.com Sat Aug 24 07:44:59 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6947E11E8101 for ; Sat, 24 Aug 2013 07:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.330, 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 7opme61sAIFW for ; Sat, 24 Aug 2013 07:44:55 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2720111E80FE for ; Sat, 24 Aug 2013 07:44:55 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bg4so1761300pad.4 for ; Sat, 24 Aug 2013 07:44:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mNF/U+5aDl7EMnRubMN8eQK/eaSbTsQwfYNXOXSYkXM=; b=mQFVR/1JBeT/t8T4f2JL7z6wPM/R3NSWlben2J7uqCZTu2fS2Rdd6/MFw6VlECKUTc ANzR3Vkll93U9Z443NZh7pB6oll75LEaDbW1KUyfMGA+pcpwFY6bUlCLMj10luTmV/Jg waS48NYtIvUvr38tfjN4ndxIy4XpdM9FC1S18WFPJEzJa0uOTjDIkPoHh6syxgYrl2KV w0sQ3QUyfRA9ZprBVHVtcq+ub1XeMFj/h+Ie1kdj9W+j/u9WNZKvIxnKPCBXnQzDnurG FEFsOsOt70g4mGDZLYps/ur4mf1H7W5vlv+ay2/BMdjEexwoHNoDjYfGaXy+JVrQGHK1 +mlg== X-Gm-Message-State: ALoCoQl+P8OOiDPulwmm1VFG83EKxOQpzD+hXACr6MusBXEgQDNflPhyjKHpUg8ycGN2A/+OLWMC MIME-Version: 1.0 X-Received: by 10.67.22.67 with SMTP id hq3mr4659670pad.132.1377355488660; Sat, 24 Aug 2013 07:44:48 -0700 (PDT) Received: by 10.70.41.162 with HTTP; Sat, 24 Aug 2013 07:44:48 -0700 (PDT) In-Reply-To: <52187D76.2030001@joelhalpern.com> References: <919fea51f182429b910962784a9e75fd@BL2PR05MB193.namprd05.prod.outlook.com> <52187D76.2030001@joelhalpern.com> Date: Sat, 24 Aug 2013 07:44:48 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Cc: Alia Atlas , Nitin Bahadur , "i2rs-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 14:44:59 -0000 On Sat, Aug 24, 2013 at 2:31 AM, Joel M. Halpern wrote: > For me, "ownership" of data is not a helpful way to think about this. (It is > not incorrect, just unhelpful.) > > Rather, the base concept is that two different clients should not be writing > the same data in the same time period. (i.e. from when the first one writes > it until he removes his modification.) > > When this fails, it is an error. > We need to detect this error. I am confused. This implies that the clients are coordinated, but that is clearly out of scope. Do you mean 2 clients with the same priority? The particular data model will have some "collision scope" which could be 1 of [row, multiple rows, table, container, ad-hoc]. It seems very likely that 2 clients could collide, especially if the scope was wider than per-row. A low-priority client that gets over-written by a higher priority client will get a notification that the data was deleted. A low-priority client that attempts to over-write a same or higher priority client will get an error response that the data was inserted. > So the I2RS Agent is required to keep track of enough information to detect > and provide a predictable behavior in the event this occurs. > The priority mechanism is a mechanism for providing better predictability. > If we don't like it, we can ditch it. > > In particular, one corrollary of this is that "ownership" does not, it seems > to me, belong in the data model. It is, as Alia and other said, metadata. > A YANG extension could be used if there was concern that maintaining owner meta-data is too expensive for every resource, and only certain data needs to maintain it. IMO this is not needed. > Yours, > Joel > Andy > On 8/22/13 6:36 PM, Andy Bierman wrote: >> >> On Thu, Aug 22, 2013 at 2:08 PM, Jan Medved (jmedved) >> wrote: >>> >>> Hi Alia, >>> >>> On 8/22/13 11:13 AM, "Alia Atlas" wrote: >>> >>>> Hi Juergen, >>>> >>>> I agree that the ownership of data seems more like meta-data to me than >>>> anything else. I really would prefer not to clutter the data-models >>>> with >>>> it. >>> >>> >>> It depends. If ownership is coarse grained, then having the ownership >>> metadata in a separate tree is manageable. If it's fine-grained, having >>> the ownership metadata embedded in the data tree is easier - both for the >>> server as well as for the clients. >>> >>> I think with I2RS, ownership will likely be fine-grained. >>> >> >> I think this "owner" concept needs a lot more work. >> If owner 1 has a higher priority than owner 2, then owner 1 can clobber >> anything that owner 2 already created. That doesn't sound fine-grained >> to me. >> >> The "first one wins" concept only applies to clients with the same >> priority. >> The "last one wins" problem is addressed by assigning priorities to the >> clients. >> Now it is "highest priority wins" which is what is desired. >> >> If the client writing existing data has the same or lower priority as the >> owner >> that set the data, then the access is denied. (Problem solved, first one >> wins). >> NACM would need some changes to support owner priority. >> The augments that has been proposed is insufficient: >> http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00#section-3.6 >> >> (IMO, only sec. 3.6 of this draft is needed.) >> >> >>>> >>>> I think there are two (at least!) separate aspects that we need to >>>> figure >>>> out. One is the permissions aspect - where we need to be able to >>>> clearly >>>> express what scope a particular role has. >>> >>> >>> Agreed. >>> >>>> The second is what an i2rs agent needs to store, manipulate, and >>>> report >>>> back. >>>> >>>> For the latter, the basic concept is described in >>>> draft-ietf-i2rs-architecture-00 split across Sec 5.2, 6.8, and 6.4 >>>> (which >>>> discusses identity). In Sec 5.2, it says: >>>> >>>> "The I2RS agent stores the set of >>>> operations it has applied. Simply, the I2RS agent stores who did >>>> what operation to which entity. New changes replace any data about >>>> old ones. If an I2RS client does an operation to remove some state, >>>> that state is removed and the I2RS agent stores no more information >>>> about it. This allows any interested party to determine what the >>>> current effect of I2RS on the system is, and why. Meaningful logging >>>> is also recommended." >> >> >> >> If a client is really a broker, then is the owner string going to be for >> the >> upstream application or the broker? Which clients are likely to >> have the same priority and collide on the same data? >> >> >>>> >>>> Alia >>> >>> >>> /Jan >> >> >> Andy >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > From internet-drafts@ietf.org Sun Aug 25 13:38:33 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DCE21F85EB; Sun, 25 Aug 2013 13:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 bcMMkzGOBrb3; Sun, 25 Aug 2013 13:38:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8327821F9E2B; Sun, 25 Aug 2013 13:38:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> Date: Sun, 25 Aug 2013 13:38:31 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 20:38:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : A YANG Data Model for IP Management Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-ip-cfg-10.txt Pages : 33 Date : 2013-08-25 Abstract: This document defines a YANG data model for management of IP implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-ip-cfg-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mbj@tail-f.com Sun Aug 25 13:57:44 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9172521F9F9E for ; Sun, 25 Aug 2013 13:57:43 -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 j4gxwfOVZS-e for ; Sun, 25 Aug 2013 13:57:37 -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 5C5D921F9FC8 for ; Sun, 25 Aug 2013 13:57:36 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id BB83012000A9 for ; Sun, 25 Aug 2013 22:57:34 +0200 (CEST) Date: Sun, 25 Aug 2013 22:57:34 +0200 (CEST) Message-Id: <20130825.225734.296927526.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> References: <20130825203831.20582.30133.idtracker@ietfa.amsl.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 Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 20:57:44 -0000 Hi, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the NETCONF Data Modeling Language Working Group > of the IETF. > > Title : A YANG Data Model for IP Management > Author(s) : Martin Bjorklund > Filename : draft-ietf-netmod-ip-cfg-10.txt > Pages : 33 > Date : 2013-08-25 This draft adds IP state data to /interfaces-state/interface (assigned addresses) and to /ip-state (neighbors). In the /if:interfaces/if:interface/ipv6/address/status leaf, I blindly copied the corresponding enumeration from IP-MIB, IpAddressStatusTC. But I do not know if this is correct, or if we should use only the three states defined in RFC 4862 - preferred, deprecated and tentative. (and other or unknown makes sense). For example, the value 'invalid' is used in the MIB, but 4862 says that an invalid address is "an address that is not assigned to any interface [...]". So how can it be reported? Also, 'duplicate' is a value in the MIB, but 4862 says: "A tentative address that is determined to be a duplicate as described above MUST NOT be assigned to an interface" so it unclear again how it can be reported. /martin From jmedved@cisco.com Sun Aug 25 20:23:59 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78E911E813A for ; Sun, 25 Aug 2013 20:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 w6GDZlRXjafr for ; Sun, 25 Aug 2013 20:23:55 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C158411E8138 for ; Sun, 25 Aug 2013 20:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5399; q=dns/txt; s=iport; t=1377487435; x=1378697035; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=alBM2SZwTeRUTBgpuMXOO6pIeOG2xPh+Lcqpl4bxeLI=; b=Ctvp0ng6EFlG1zTbkiId78kFhPEOrnncsBlDCSGMJxvzq6be0KoVn3Rk AHwK1EuazWbpGWXMnVKgjGwPfNAyTrbxSg8FTRYU7xapZzR1eFO1/odsk 2mYjARFz4vSoZEozyKFC72SZ1HEp6xffXMEkwvmBE/9+Sjcwi9W9LgUPL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAGzJGlKtJXHA/2dsb2JhbABRCYMHNVHAEYEeFnSCJAEBAQQBAQE3NAsSAQgSBgoUNwsXDgIEAQ0FCId5DLcIjzaBETEHgxx9A5kbkDSDHoFqJBw X-IronPort-AV: E=Sophos;i="4.89,955,1367971200"; d="scan'208";a="251507352" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 26 Aug 2013 03:23:54 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7Q3NsHc018357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Aug 2013 03:23:54 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.56]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Sun, 25 Aug 2013 22:23:53 -0500 From: "Jan Medved (jmedved)" To: "Joel M. Halpern" , Andy Bierman Thread-Topic: [netmod] i2rs client ownership Thread-Index: AQHOn2NoQ+Adz5ekfUGn0kuI+JV/h5mhlz8AgACN0YCAAklsAIACSJUA Date: Mon, 26 Aug 2013 03:23:53 +0000 Message-ID: In-Reply-To: <52187D76.2030001@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.27.7.167] Content-Type: text/plain; charset="us-ascii" Content-ID: <694637FDDC7FBC4A980456CB81A52F11@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Nitin Bahadur , Alia Atlas , "i2rs-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 03:23:59 -0000 On 8/24/13 2:31 AM, "Joel M. Halpern" wrote: >For me, "ownership" of data is not a helpful way to think about this. >(It is not incorrect, just unhelpful.) > >Rather, the base concept is that two different clients should not be >writing the same data in the same time period. (i.e. from when the >first one writes it until he removes his modification.) This is necessary, but not sufficient. If we allow multiple clients (actually, identities, since the same identity can cover multiple clients) to change state programmatically, we must allow for mechanisms for programmatic state validation and troubleshooting. For example, when there is a failover between a redundant pair of clients, the newly active client instance must perform state synchronization, which includes reading all the state that the previously active instance of the client injected into the system. Therefore, the agent needs to know which client injected which state into system (if the agent does not do that, we need an external entity, such as the controller, to keep track of this). Similarly for troubleshooting - when, for example, an operator wants to purge state of a client that is/should not be active anymore, the system should facilitate this action. A state purge for a client could happen, for example, when an operator wants to shut down an application. > >When this fails, it is an error. >We need to detect this error. >So the I2RS Agent is required to keep track of enough information to >detect and provide a predictable behavior in the event this occurs. >The priority mechanism is a mechanism for providing better >predictability. If we don't like it, we can ditch it. Priority is useful - no reason to ditch it. But it is not sufficient :-) > >In particular, one corrollary of this is that "ownership" does not, it >seems to me, belong in the data model. It is, as Alia and other said, >metadata. Yes, it is metadata. But it would be premature to exclude the option to provide metadata along with the data - there are plenty of systems out there that implement this concept and work quite well. > >Yours, >Joel Thanks, Jan > >On 8/22/13 6:36 PM, Andy Bierman wrote: >> On Thu, Aug 22, 2013 at 2:08 PM, Jan Medved (jmedved) >> wrote: >>> Hi Alia, >>> >>> On 8/22/13 11:13 AM, "Alia Atlas" wrote: >>> >>>> Hi Juergen, >>>> >>>> I agree that the ownership of data seems more like meta-data to me >>>>than >>>> anything else. I really would prefer not to clutter the data-models >>>>with >>>> it. >>> >>> It depends. If ownership is coarse grained, then having the ownership >>> metadata in a separate tree is manageable. If it's fine-grained, having >>> the ownership metadata embedded in the data tree is easier - both for >>>the >>> server as well as for the clients. >>> >>> I think with I2RS, ownership will likely be fine-grained. >>> >> >> I think this "owner" concept needs a lot more work. >> If owner 1 has a higher priority than owner 2, then owner 1 can clobber >> anything that owner 2 already created. That doesn't sound fine-grained >> to me. >> >> The "first one wins" concept only applies to clients with the same >>priority. >> The "last one wins" problem is addressed by assigning priorities to the >>clients. >> Now it is "highest priority wins" which is what is desired. >> >> If the client writing existing data has the same or lower priority as >>the owner >> that set the data, then the access is denied. (Problem solved, first >>one wins). >> NACM would need some changes to support owner priority. >> The augments that has been proposed is insufficient: >> http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00#section-3.6 >> >> (IMO, only sec. 3.6 of this draft is needed.) >> >> >>>> >>>> I think there are two (at least!) separate aspects that we need to >>>>figure >>>> out. One is the permissions aspect - where we need to be able to >>>>clearly >>>> express what scope a particular role has. >>> >>> Agreed. >>> >>>> The second is what an i2rs agent needs to store, manipulate, and >>>>report >>>> back. >>>> >>>> For the latter, the basic concept is described in >>>> draft-ietf-i2rs-architecture-00 split across Sec 5.2, 6.8, and 6.4 >>>>(which >>>> discusses identity). In Sec 5.2, it says: >>>> >>>> "The I2RS agent stores the set of >>>> operations it has applied. Simply, the I2RS agent stores who did >>>> what operation to which entity. New changes replace any data about >>>> old ones. If an I2RS client does an operation to remove some >>>>state, >>>> that state is removed and the I2RS agent stores no more information >>>> about it. This allows any interested party to determine what the >>>> current effect of I2RS on the system is, and why. Meaningful >>>>logging >>>> is also recommended." >> >> >> If a client is really a broker, then is the owner string going to be >>for the >> upstream application or the broker? Which clients are likely to >> have the same priority and collide on the same data? >> >> >>>> >>>> Alia >>> >>> /Jan >> >> Andy >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> From muthu@cisco.com Sun Aug 25 22:28:17 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B55E21F90A7 for ; Sun, 25 Aug 2013 22:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 4NAhy2cP0IRG for ; Sun, 25 Aug 2013 22:28:10 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 375B721F92B5 for ; Sun, 25 Aug 2013 22:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5159; q=dns/txt; s=iport; t=1377494890; x=1378704490; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=nMOWaFvEZ1YqH5zBmKUFBnNKusHo9ci+uYk7Ub59m0Y=; b=Z37lWujcSq9XHuG7J3EjWD/9yhMj+FF/D1G66Y4r+2N1AGlN01eFL6Wg XnRnYpMUii/N1Joh+ETRAn3l5AdA/IYCr26FoTwYtEh4+uXv7PFqJhAHi nEw/4WhTNEizhQOpNQ2SLPIbGBGRXjIAgbhtaJG2VHbqfnaP5nDFK8DT5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAHfmGlKtJV2Z/2dsb2JhbABRBgODBzVRwBKBIBZ0giQBAQEDATo/BQkEAQgOAgIGChQrFxcOAgQOBQiHZwMJBq0vCIlvBI8ygREhEAcRgwt9A6lPgx6CKg X-IronPort-AV: E=Sophos;i="4.89,955,1367971200"; d="scan'208";a="251494809" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 26 Aug 2013 05:28:09 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7Q5S8LO002279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Aug 2013 05:28:09 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.77]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Mon, 26 Aug 2013 00:28:08 -0500 From: "Muthumayan Madhayyan (muthu)" To: Juergen Schoenwaelder Thread-Topic: i2rs client ownership Thread-Index: AQHOnoY+syzZo8WhDEyQwjy3WBRvYJmhTqUAgACEsgCABQgngA== Date: Mon, 26 Aug 2013 05:28:07 +0000 Message-ID: <5A949C32AF740C4798AEECF2568F0D840C15F8E2@xmb-rcd-x13.cisco.com> In-Reply-To: <20130822173732.GB7508@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.21.94.93] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alia Atlas , Nitin Bahadur , "i2rs-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 05:28:17 -0000 On 8/22/13 10:37 AM, "Juergen Schoenwaelder" wrote: >On Thu, Aug 22, 2013 at 04:57:45PM +0000, Muthumayan Madhayyan (muthu) >wrote: >> Hello David, >>=20 >> Please see inline: >>=20 >> On 8/21/13 8:50 AM, "David Harrington" wrote: >>=20 >> >Hi, >> > >> >I have some questions about this requirement to associate client >>ownership >> >to injected data. >> > >> >1) at what level of detail is the data ownership? >> >Are we talking about specific subtrees in the datastore, or a complete >> >datastore (e.g., a variation on candidate)? >> >If we are talking ownership of a datastore, then this would seem to be >>a >> >netconf requirement. >> >If we are talking ownership of a row in a routing table, or something >> >similar, then the ownership probably needs to be part of the data >>model, >> >comparable to OwnerStrings in the MIB. >>=20 >> The ownership is on a specific sub-tree and this is why we needed data >> model=20 >> to express it. >> > >> >2) Can a client only assert their own ownership of a data subset, or >>can >> >they assert that somebody else is the owner? >>=20 >>=20 >> Every subset created in runtime has an ownership tagged to it. Now, the >> client that created the data is the owner. If this data model states >>that >> the data subset is 'exclusive', then only the owner can modify or delete >> that subset. Else other clients can get read-write access to that any >> instance of the data sub-set created by another client. >>=20 >>=20 >> >For example, if an operator determines that a static route should be >>added >> >to a routing table, based on looking at the hosts file of another node, >> >can the operator set the ownership to be a URL to that file, or MUST >>the >> >ownership be the ID for the user/operator who is setting the >>information? >>=20 >> As defined currently, it is the ID of the user/operator. >>=20 > >I am confused. Lets see. If an I2RS client creates a 'foo' in >operational state, then I think you want 'foo' associated with the >identifier 'joe' representing the identity of the client. Is that >automatic (the mere fact that the client authenticated as 'joe' means >'foo' belongs to 'joe') or do you want 'joe' to be explicit, that >is joe actually says "create 'foo' owned by 'joe'"? i2rs at the time of writing had 'foo' belongs to 'joe' type of requirement . So, assuming you have a global operational table, each row could be potentially owned by different clients. > >> >3) If #2 requires the client-as-owner, must the client ID be >> >authenticated? If the proposal uses NACM to perform the authentication, >> >then you would presumably create a binding between the ACM mechanism >> >(e.g., NACM) and the specific data model. >>=20 >> Yes, the intent was to tie NACM to do the authentication. > >I am confused. NACM does authorization, not authentication. That is true. NACM RFC talks about use of RADIUS for authentication and mapping users to user-groups. We could adopt the same or better approach for i2rs. > If you >want to restrict access to 'foo' to 'joe', NACM would need a rule that >says access to 'foo' is restricted to 'joe'. Depending on the answer >to 2), the question is how the rule is being injected into NACM (if >you were to use NACM and NACM would apply to writable operational >state). But then, NACM - as far as I understand it - can only perform >access decisions on data that is explicit in the data model. I am >actually not sure you want to 'clutter' all your data models with >additional leafs to express ownership - this really smells much more >like meta-data. NACM is used for mainly for specifying a relative priority for a user-group. The reason for those additional ownership leaf objects is not such much for the 'write'. During write, the owner field is actually meta-data. But then there is a 'read' aspect as well. Any client should be able to access data that was created by some other client. Client A wants to know about routes injected by another Client B or C. > >> >4) There has been discussion of trying to make YANG protocol >>independent. >> >To maintain such independence, would the data model need to be written >> >such that the user/client ID is protocol-independent? Could any ACM >>model >> >be used to provide the user identity and authentication, not just NACM >> >(and not just Netconf)? Compare for example, the ability for SNMPv3 to >>use >> >multiple co-existing security models. Is this the direction this >>proposal >> >would require? >>=20 >> Any ACM should do. It was just easier to extend NACM group settings to >>add >> a client priority. > >Hm. It might be good to work out a more detailed example of what I2RS >may want. Or can someone point to the parts of the architecture I-D >where this is clearly described? > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From muthu@cisco.com Sun Aug 25 22:40:32 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1095F11E8158 for ; Sun, 25 Aug 2013 22:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 6EzQbddgEluY for ; Sun, 25 Aug 2013 22:40:25 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D9A4B11E8109 for ; Sun, 25 Aug 2013 22:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1328; q=dns/txt; s=iport; t=1377495625; x=1378705225; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=KX8fWPY6xg4AZuH9lD/u097W+NhbTyTRxiWXFniQJEo=; b=I0Ni6x4q9iu/QpSAvM+gJYpMNsuTXQK7qlkSpW/LQWalXZbB7hxit9UA eXuwOdLcPQFfVl4xQ1VLOCIbsqdxZ0E34AOA08YxbCIwERteaHX6EeDTN D7LYsvt2lLMX1wrsIr/9yhkVY5MA6OPxSraxusHDh8wkAVfiGv80ptSfK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FABrpGlKtJXG+/2dsb2JhbABagweBBsASgSAWdIIkAQEBBDpRAQgQCAoUQiUCBAESCId5tyyPRYECOIMcfQOpT4MegWlB X-IronPort-AV: E=Sophos;i="4.89,956,1367971200"; d="scan'208";a="251547548" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 26 Aug 2013 05:40:24 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7Q5eO7J010366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Aug 2013 05:40:24 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.77]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Mon, 26 Aug 2013 00:40:23 -0500 From: "Muthumayan Madhayyan (muthu)" To: Andy Bierman , Juergen Schoenwaelder , Ladislav Lhotka , "Jan Medved (jmedved)" , Alia Atlas , "i2rs-chairs@tools.ietf.org" , Nitin Bahadur , "netmod@ietf.org" , "Alexander Clemm (alex)" Thread-Topic: [netmod] comments on draft-ietf-netmod-routing-cfg-10 Thread-Index: AQHOmGEBI8PXbbfFTkmYweHRl90ooJmUqm6AgABxvICAAAK4gIAADosAgAD7V4CAAFAGAIAATr4AgAFHWYCABZAwgIAAhBEAgAB7MACAANiCgIADxYcAgAOu24A= Date: Mon, 26 Aug 2013 05:40:23 +0000 Message-ID: <5A949C32AF740C4798AEECF2568F0D840C15F90B@xmb-rcd-x13.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.21.94.93] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 05:40:32 -0000 On 8/23/13 7:25 AM, "Andy Bierman" wrote: >On Tue, Aug 20, 2013 at 9:49 PM, Juergen Schoenwaelder > wrote: >> On Tue, Aug 20, 2013 at 10:55:06PM +0000, Muthumayan Madhayyan (muthu) >>wrote: >>> Hello Lada, >>> >>> Apart from the ability to write ephemeral data, I2RS also has a >>> requirement to associate client ownership to data injected by an >>>external >>> client. In NETCONF, the stores are global. >>> >> >> Well, this sounds like a NETCONF requirement, not a YANG requirement. > >+1 > >The owner is a property of the datastore, not the data model. >Ditto for the "ephemeral" YANG extension. I don't see the need >for any YANG extensions, just protocol extensions. There is no central 'datastore' for those schema nodes marked ephemeral. The i2rs client directly talks to an i2rs server that does not provide any form of storage, but relays all requests to relevant backend applications with adequate metadata like client identification and relative priority etc to the backend. All data injected by i2rs clients are maintained by the backend i2rs applications. In that sense this deviates a lot from traditional NETCONF datastore. Hope that explains why an 'ephemeral' extension is needed. > > > >> >> /js > >Andy From jmh.direct@joelhalpern.com Mon Aug 26 00:15:15 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B2E21F9B92 for ; Mon, 26 Aug 2013 00:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+M-zICYPxxG for ; Mon, 26 Aug 2013 00:15:09 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id E461311E816D for ; Mon, 26 Aug 2013 00:15:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D355B1C0466; Mon, 26 Aug 2013 00:15:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from localhost (unknown [192.165.183.201]) by mailb2.tigertech.net (Postfix) with ESMTPA id AAE921C0066; Mon, 26 Aug 2013 00:15:06 -0700 (PDT) Date: Mon, 26 Aug 2013 09:15:00 +0200 Message-ID: Importance: low From: "Jmh.direct" To: jmedved@cisco.com, jmh@joelhalpern.com, andy@yumaworks.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_307628585996187" Cc: nitinb@juniper.net, akatlas@juniper.net, i2rs-chairs@tools.ietf.org, netmod@ietf.org Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 07:15:15 -0000 ----_com.android.email_307628585996187 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 TW9zdGx5LCBJIGFtIGNvbWZvcnRhYmxlIHdpdGggeW91ciBkZXNjcmlwdGlvbi4gwqBIYXZvbmcg YW4gaW5mb3JtYXRpb24gbW9kZWwgb2YgdGhlIG1ldGFkYXRhIHNlZW1zIHVhZWZ1bC4KCk9uIHRo ZSBvdGhlciBoYW5kIGZvciByZWR1bmRhbnQgY2xpZW50cyBjb29wZXJhdGluZyBmb3IgZmFpbG92 ZXIsIGV0Yy4gSSB0aGluayBpdCBpcyB3b3J0aCBrZWVwaW5nIGluIG1pbmQgdGhhdCB0aGV5IHdp bGwgbmVlZCB0aGVpciBvd24gYmFjay1lbmQgY29vcmRpbmF0aW9uLiDCoFRoZSBJMlJTIGFnZW50 IG91Z2h0IG5vdCBiZSB0aGUgcHJpbWFyeSBjb29yZGluYXRpb24gY2hhbm5lbC4KCllvdXJzLApK b2VsCgoKU2VudCBmcm9tIG15IFNhbXN1bmcgc21hcnRwaG9uZSBvbiBBVCZUCgotLS0tLS0tLSBP cmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBpMnJzIGNsaWVu dCBvd25lcnNoaXAgCkZyb206ICJKYW4gTWVkdmVkIChqbWVkdmVkKSIgPGptZWR2ZWRAY2lzY28u Y29tPiAKVG86ICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPixBbmR5IEJp ZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gCkNDOiAibmV0bW9kQGlldGYub3JnIiA8bmV0bW9k QGlldGYub3JnPixOaXRpbiBCYWhhZHVyIDxuaXRpbmJAanVuaXBlci5uZXQ+LEFsaWEgQXRsYXMg PGFrYXRsYXNAanVuaXBlci5uZXQ+LCJpMnJzLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgPGkycnMt Y2hhaXJzQHRvb2xzLmlldGYub3JnPiAKCgoKT24gOC8yNC8xMyAyOjMxIEFNLCAiSm9lbCBNLiBI YWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6Cgo+Rm9yIG1lLCAib3duZXJzaGlw IiBvZiBkYXRhIGlzIG5vdCBhIGhlbHBmdWwgd2F5IHRvIHRoaW5rIGFib3V0IHRoaXMuCj4oSXQg aXMgbm90IGluY29ycmVjdCwganVzdCB1bmhlbHBmdWwuKQo+Cj5SYXRoZXIsIHRoZSBiYXNlIGNv bmNlcHQgaXMgdGhhdCB0d28gZGlmZmVyZW50IGNsaWVudHMgc2hvdWxkIG5vdCBiZQo+d3JpdGlu ZyB0aGUgc2FtZSBkYXRhIGluIHRoZSBzYW1lIHRpbWUgcGVyaW9kLsKgIChpLmUuIGZyb20gd2hl biB0aGUKPmZpcnN0IG9uZSB3cml0ZXMgaXQgdW50aWwgaGUgcmVtb3ZlcyBoaXMgbW9kaWZpY2F0 aW9uLikKClRoaXMgaXMgbmVjZXNzYXJ5LCBidXQgbm90IHN1ZmZpY2llbnQuIElmIHdlIGFsbG93 IG11bHRpcGxlIGNsaWVudHMKKGFjdHVhbGx5LCBpZGVudGl0aWVzLCBzaW5jZSB0aGUgc2FtZSBp ZGVudGl0eSBjYW4gY292ZXIgbXVsdGlwbGUgY2xpZW50cykKdG8gY2hhbmdlIHN0YXRlIHByb2dy YW1tYXRpY2FsbHksIHdlIG11c3QgYWxsb3cgZm9yIG1lY2hhbmlzbXMgZm9yCnByb2dyYW1tYXRp YyBzdGF0ZSB2YWxpZGF0aW9uIGFuZCB0cm91Ymxlc2hvb3RpbmcuCgpGb3IgZXhhbXBsZSwgd2hl biB0aGVyZSBpcyBhIGZhaWxvdmVyIGJldHdlZW4gYSByZWR1bmRhbnQgcGFpciBvZiBjbGllbnRz LAp0aGUgbmV3bHkgYWN0aXZlIGNsaWVudCBpbnN0YW5jZSBtdXN0IHBlcmZvcm0gc3RhdGUgc3lu Y2hyb25pemF0aW9uLCB3aGljaAppbmNsdWRlcyByZWFkaW5nIGFsbCB0aGUgc3RhdGUgdGhhdCB0 aGUgcHJldmlvdXNseSBhY3RpdmUgaW5zdGFuY2Ugb2YgdGhlCmNsaWVudCBpbmplY3RlZCBpbnRv IHRoZSBzeXN0ZW0uIFRoZXJlZm9yZSwgdGhlIGFnZW50IG5lZWRzIHRvIGtub3cgd2hpY2gKY2xp ZW50IGluamVjdGVkIHdoaWNoIHN0YXRlIGludG8gc3lzdGVtIChpZiB0aGUgYWdlbnQgZG9lcyBu b3QgZG8gdGhhdCwgd2UKbmVlZCBhbiBleHRlcm5hbCBlbnRpdHksIHN1Y2ggYXMgdGhlIGNvbnRy b2xsZXIsIHRvIGtlZXAgdHJhY2sgb2YgdGhpcykuCgpTaW1pbGFybHkgZm9yIHRyb3VibGVzaG9v dGluZyAtIHdoZW4sIGZvciBleGFtcGxlLCBhbiBvcGVyYXRvciB3YW50cyB0bwpwdXJnZSBzdGF0 ZSBvZiBhIGNsaWVudCB0aGF0IGlzL3Nob3VsZCBub3QgYmUgYWN0aXZlIGFueW1vcmUsIHRoZSBz eXN0ZW0Kc2hvdWxkIGZhY2lsaXRhdGUgdGhpcyBhY3Rpb24uIEEgc3RhdGUgcHVyZ2UgZm9yIGEg Y2xpZW50IGNvdWxkIGhhcHBlbiwKZm9yIGV4YW1wbGUsIHdoZW4gYW4gb3BlcmF0b3Igd2FudHMg dG8gc2h1dCBkb3duIGFuIGFwcGxpY2F0aW9uLgoKPgo+V2hlbiB0aGlzIGZhaWxzLCBpdCBpcyBh biBlcnJvci4KPldlIG5lZWQgdG8gZGV0ZWN0IHRoaXMgZXJyb3IuCj5TbyB0aGUgSTJSUyBBZ2Vu dCBpcyByZXF1aXJlZCB0byBrZWVwIHRyYWNrIG9mIGVub3VnaCBpbmZvcm1hdGlvbiB0bwo+ZGV0 ZWN0IGFuZCBwcm92aWRlIGEgcHJlZGljdGFibGUgYmVoYXZpb3IgaW4gdGhlIGV2ZW50IHRoaXMg b2NjdXJzLgo+VGhlIHByaW9yaXR5IG1lY2hhbmlzbSBpcyBhIG1lY2hhbmlzbSBmb3IgcHJvdmlk aW5nIGJldHRlcgo+cHJlZGljdGFiaWxpdHkuwqAgSWYgd2UgZG9uJ3QgbGlrZSBpdCwgd2UgY2Fu IGRpdGNoIGl0LgoKUHJpb3JpdHkgaXMgdXNlZnVsIC0gbm8gcmVhc29uIHRvIGRpdGNoIGl0LiBC dXQgaXQgaXMgbm90IHN1ZmZpY2llbnQgOi0pCgo+Cj5JbiBwYXJ0aWN1bGFyLCBvbmUgY29ycm9s bGFyeSBvZiB0aGlzIGlzIHRoYXQgIm93bmVyc2hpcCIgZG9lcyBub3QsIGl0Cj5zZWVtcyB0byBt ZSwgYmVsb25nIGluIHRoZSBkYXRhIG1vZGVsLsKgIEl0IGlzLCBhcyBBbGlhIGFuZCBvdGhlciBz YWlkLAo+bWV0YWRhdGEuCgpZZXMsIGl0IGlzIG1ldGFkYXRhLiBCdXQgaXQgd291bGQgYmUgcHJl bWF0dXJlIHRvIGV4Y2x1ZGUgdGhlIG9wdGlvbiB0bwpwcm92aWRlIG1ldGFkYXRhIGFsb25nIHdp dGggdGhlIGRhdGEgLSB0aGVyZSBhcmUgcGxlbnR5IG9mIHN5c3RlbXMgb3V0CnRoZXJlIHRoYXQg aW1wbGVtZW50IHRoaXMgY29uY2VwdCBhbmQgd29yayBxdWl0ZSB3ZWxsLgoKPgo+WW91cnMsCj5K b2VsCgpUaGFua3MsCkphbgoKPgo+T24gOC8yMi8xMyA2OjM2IFBNLCBBbmR5IEJpZXJtYW4gd3Jv dGU6Cj4+IE9uIFRodSwgQXVnIDIyLCAyMDEzIGF0IDI6MDggUE0sIEphbiBNZWR2ZWQgKGptZWR2 ZWQpCj4+PGptZWR2ZWRAY2lzY28uY29tPiB3cm90ZToKPj4+IEhpIEFsaWEsCj4+Pgo+Pj4gT24g OC8yMi8xMyAxMToxMyBBTSwgIkFsaWEgQXRsYXMiIDxha2F0bGFzQGp1bmlwZXIubmV0PiB3cm90 ZToKPj4+Cj4+Pj4gSGkgSnVlcmdlbiwKPj4+Pgo+Pj4+IEkgYWdyZWUgdGhhdCB0aGUgb3duZXJz aGlwIG9mIGRhdGEgc2VlbXMgbW9yZSBsaWtlIG1ldGEtZGF0YSB0byBtZQo+Pj4+dGhhbgo+Pj4+ IGFueXRoaW5nIGVsc2UuwqAgSSByZWFsbHkgd291bGQgcHJlZmVyIG5vdCB0byBjbHV0dGVyIHRo ZSBkYXRhLW1vZGVscwo+Pj4+d2l0aAo+Pj4+IGl0Lgo+Pj4KPj4+IEl0IGRlcGVuZHMuIElmIG93 bmVyc2hpcCBpcyBjb2Fyc2UgZ3JhaW5lZCwgdGhlbiBoYXZpbmcgdGhlIG93bmVyc2hpcAo+Pj4g bWV0YWRhdGEgaW4gYSBzZXBhcmF0ZSB0cmVlIGlzIG1hbmFnZWFibGUuIElmIGl0J3MgZmluZS1n cmFpbmVkLCBoYXZpbmcKPj4+IHRoZSBvd25lcnNoaXAgbWV0YWRhdGEgZW1iZWRkZWQgaW4gdGhl IGRhdGEgdHJlZSBpcyBlYXNpZXIgLSBib3RoIGZvcgo+Pj50aGUKPj4+IHNlcnZlciBhcyB3ZWxs IGFzIGZvciB0aGUgY2xpZW50cy4KPj4+Cj4+PiBJIHRoaW5rIHdpdGggSTJSUywgb3duZXJzaGlw IHdpbGwgbGlrZWx5IGJlIGZpbmUtZ3JhaW5lZC4KPj4+Cj4+Cj4+IEkgdGhpbmsgdGhpcyAib3du ZXIiIGNvbmNlcHQgbmVlZHMgYSBsb3QgbW9yZSB3b3JrLgo+PiBJZiBvd25lciAxIGhhcyBhIGhp Z2hlciBwcmlvcml0eSB0aGFuIG93bmVyIDIsIHRoZW4gb3duZXIgMSBjYW4gY2xvYmJlcgo+PiBh bnl0aGluZyB0aGF0IG93bmVyIDIgYWxyZWFkeSBjcmVhdGVkLiBUaGF0IGRvZXNuJ3Qgc291bmQg ZmluZS1ncmFpbmVkCj4+IHRvIG1lLgo+Pgo+PiBUaGUgImZpcnN0IG9uZSB3aW5zIiBjb25jZXB0 IG9ubHkgYXBwbGllcyB0byBjbGllbnRzIHdpdGggdGhlIHNhbWUKPj5wcmlvcml0eS4KPj4gVGhl ICJsYXN0IG9uZSB3aW5zIiBwcm9ibGVtIGlzIGFkZHJlc3NlZCBieSBhc3NpZ25pbmcgcHJpb3Jp dGllcyB0byB0aGUKPj5jbGllbnRzLgo+PiBOb3cgaXQgaXMgImhpZ2hlc3QgcHJpb3JpdHkgd2lu cyIgd2hpY2ggaXMgd2hhdCBpcyBkZXNpcmVkLgo+Pgo+PiBJZiB0aGUgY2xpZW50IHdyaXRpbmcg ZXhpc3RpbmcgZGF0YSBoYXMgdGhlIHNhbWUgb3IgbG93ZXIgcHJpb3JpdHkgYXMKPj50aGUgb3du ZXIKPj4gdGhhdCBzZXQgdGhlIGRhdGEsIHRoZW4gdGhlIGFjY2VzcyBpcyBkZW5pZWQuwqAgKFBy b2JsZW0gc29sdmVkLCBmaXJzdAo+Pm9uZSB3aW5zKS4KPj4gTkFDTSB3b3VsZCBuZWVkIHNvbWUg Y2hhbmdlcyB0byBzdXBwb3J0IG93bmVyIHByaW9yaXR5Lgo+PiBUaGUgYXVnbWVudHMgdGhhdCBo YXMgYmVlbiBwcm9wb3NlZCBpcyBpbnN1ZmZpY2llbnQ6Cj4+IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXJmZXJuYW5kby1pMnJzLXlhbmctbW9kcy0wMCNzZWN0aW9uLTMuNgo+Pgo+ PiAoSU1PLCBvbmx5IHNlYy4gMy42IG9mIHRoaXMgZHJhZnQgaXMgbmVlZGVkLikKPj4KPj4KPj4+ Pgo+Pj4+IEkgdGhpbmsgdGhlcmUgYXJlIHR3byAoYXQgbGVhc3QhKSBzZXBhcmF0ZSBhc3BlY3Rz IHRoYXQgd2UgbmVlZCB0bwo+Pj4+ZmlndXJlCj4+Pj4gb3V0LsKgIE9uZSBpcyB0aGUgcGVybWlz c2lvbnMgYXNwZWN0IC0gd2hlcmUgd2UgbmVlZCB0byBiZSBhYmxlIHRvCj4+Pj5jbGVhcmx5Cj4+ Pj4gZXhwcmVzcyB3aGF0IHNjb3BlIGEgcGFydGljdWxhciByb2xlIGhhcy4KPj4+Cj4+PiBBZ3Jl ZWQuCj4+Pgo+Pj4+wqDCoCBUaGUgc2Vjb25kIGlzIHdoYXQgYW4gaTJycyBhZ2VudCBuZWVkcyB0 byBzdG9yZSwgbWFuaXB1bGF0ZSwgYW5kCj4+Pj5yZXBvcnQKPj4+PiBiYWNrLgo+Pj4+Cj4+Pj4g Rm9yIHRoZSBsYXR0ZXIsIHRoZSBiYXNpYyBjb25jZXB0IGlzIGRlc2NyaWJlZCBpbgo+Pj4+IGRy YWZ0LWlldGYtaTJycy1hcmNoaXRlY3R1cmUtMDAgc3BsaXQgYWNyb3NzIFNlYyA1LjIsIDYuOCwg YW5kIDYuNAo+Pj4+KHdoaWNoCj4+Pj4gZGlzY3Vzc2VzIGlkZW50aXR5KS7CoCBJbiBTZWMgNS4y LCBpdCBzYXlzOgo+Pj4+Cj4+Pj7CoMKgwqAgIlRoZSBJMlJTIGFnZW50IHN0b3JlcyB0aGUgc2V0 IG9mCj4+Pj7CoMKgwqAgb3BlcmF0aW9ucyBpdCBoYXMgYXBwbGllZC7CoCBTaW1wbHksIHRoZSBJ MlJTIGFnZW50IHN0b3JlcyB3aG8gZGlkCj4+Pj7CoMKgwqAgd2hhdCBvcGVyYXRpb24gdG8gd2hp Y2ggZW50aXR5LsKgIE5ldyBjaGFuZ2VzIHJlcGxhY2UgYW55IGRhdGEgYWJvdXQKPj4+PsKgwqDC oCBvbGQgb25lcy7CoCBJZiBhbiBJMlJTIGNsaWVudCBkb2VzIGFuIG9wZXJhdGlvbiB0byByZW1v dmUgc29tZQo+Pj4+c3RhdGUsCj4+Pj7CoMKgwqAgdGhhdCBzdGF0ZSBpcyByZW1vdmVkIGFuZCB0 aGUgSTJSUyBhZ2VudCBzdG9yZXMgbm8gbW9yZSBpbmZvcm1hdGlvbgo+Pj4+wqDCoMKgIGFib3V0 IGl0LsKgIFRoaXMgYWxsb3dzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGRldGVybWluZSB3aGF0 IHRoZQo+Pj4+wqDCoMKgIGN1cnJlbnQgZWZmZWN0IG9mIEkyUlMgb24gdGhlIHN5c3RlbSBpcywg YW5kIHdoeS7CoCBNZWFuaW5nZnVsCj4+Pj5sb2dnaW5nCj4+Pj7CoMKgwqAgaXMgYWxzbyByZWNv bW1lbmRlZC4iCj4+Cj4+Cj4+IElmIGEgY2xpZW50IGlzIHJlYWxseSBhIGJyb2tlciwgdGhlbiBp cyB0aGUgb3duZXIgc3RyaW5nIGdvaW5nIHRvIGJlCj4+Zm9yIHRoZQo+PiB1cHN0cmVhbSBhcHBs aWNhdGlvbiBvciB0aGUgYnJva2VyP8KgIFdoaWNoIGNsaWVudHMgYXJlIGxpa2VseSB0bwo+PiBo YXZlIHRoZSBzYW1lIHByaW9yaXR5IGFuZCBjb2xsaWRlIG9uIHRoZSBzYW1lIGRhdGE/Cj4+Cj4+ Cj4+Pj4KPj4+PiBBbGlhCj4+Pgo+Pj4gL0phbgo+Pgo+PiBBbmR5Cj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QK Pj4gbmV0bW9kQGlldGYub3JnCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0bW9kCj4+Cgo= ----_com.android.email_307628585996187 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT5Nb3N0bHksIEkgYW0gY29tZm9ydGFi bGUgd2l0aCB5b3VyIGRlc2NyaXB0aW9uLiAmbmJzcDtIYXZvbmcgYW4gaW5mb3JtYXRpb24gbW9k ZWwgb2YgdGhlIG1ldGFkYXRhIHNlZW1zIHVhZWZ1bC48ZGl2Pjxicj48L2Rpdj48ZGl2Pk9uIHRo ZSBvdGhlciBoYW5kIGZvciByZWR1bmRhbnQgY2xpZW50cyBjb29wZXJhdGluZyBmb3IgZmFpbG92 ZXIsIGV0Yy4gSSB0aGluayBpdCBpcyB3b3J0aCBrZWVwaW5nIGluIG1pbmQgdGhhdCB0aGV5IHdp bGwgbmVlZCB0aGVpciBvd24gYmFjay1lbmQgY29vcmRpbmF0aW9uLiAmbmJzcDtUaGUgSTJSUyBh Z2VudCBvdWdodCBub3QgYmUgdGhlIHByaW1hcnkgY29vcmRpbmF0aW9uIGNoYW5uZWwuPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5Zb3Vycyw8L2Rpdj48ZGl2PkpvZWw8YnI+PGRpdj48YnI+PC9k aXY+PGRpdj48YnI+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjg3JSI+U2VudCBmcm9tIG15 IFNhbXN1bmcgc21hcnRwaG9uZSBvbiBBVCZhbXA7VDwvc3Bhbj4gPC9kaXY+PC9kaXY+PC9kaXY+ PGJyPjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTxicj5TdWJqZWN0 OiBSZTogW25ldG1vZF0gaTJycyBjbGllbnQgb3duZXJzaGlwIDxicj5Gcm9tOiAiSmFuIE1lZHZl ZCAoam1lZHZlZCkiICZsdDtqbWVkdmVkQGNpc2NvLmNvbSZndDsgPGJyPlRvOiAiSm9lbCBNLiBI YWxwZXJuIiAmbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDssQW5keSBCaWVybWFuICZsdDthbmR5 QHl1bWF3b3Jrcy5jb20mZ3Q7IDxicj5DQzogIm5ldG1vZEBpZXRmLm9yZyIgJmx0O25ldG1vZEBp ZXRmLm9yZyZndDssTml0aW4gQmFoYWR1ciAmbHQ7bml0aW5iQGp1bmlwZXIubmV0Jmd0OyxBbGlh IEF0bGFzICZsdDtha2F0bGFzQGp1bmlwZXIubmV0Jmd0OywiaTJycy1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmciICZsdDtpMnJzLWNoYWlyc0B0b29scy5pZXRmLm9yZyZndDsgPGJyPjxicj48YnI+PGRp diBzdHlsZT0id29yZC1icmVhazpicmVhay1hbGw7Ij48YnI+PGJyPk9uIDgvMjQvMTMgMjozMSBB TSwgIkpvZWwgTS4gSGFscGVybiIgJmx0O2ptaEBqb2VsaGFscGVybi5jb20mZ3Q7IHdyb3RlOjxi cj48YnI+Jmd0O0ZvciBtZSwgIm93bmVyc2hpcCIgb2YgZGF0YSBpcyBub3QgYSBoZWxwZnVsIHdh eSB0byB0aGluayBhYm91dCB0aGlzLjxicj4mZ3Q7KEl0IGlzIG5vdCBpbmNvcnJlY3QsIGp1c3Qg dW5oZWxwZnVsLik8YnI+Jmd0Ozxicj4mZ3Q7UmF0aGVyLCB0aGUgYmFzZSBjb25jZXB0IGlzIHRo YXQgdHdvIGRpZmZlcmVudCBjbGllbnRzIHNob3VsZCBub3QgYmU8YnI+Jmd0O3dyaXRpbmcgdGhl IHNhbWUgZGF0YSBpbiB0aGUgc2FtZSB0aW1lIHBlcmlvZC4mbmJzcDsgKGkuZS4gZnJvbSB3aGVu IHRoZTxicj4mZ3Q7Zmlyc3Qgb25lIHdyaXRlcyBpdCB1bnRpbCBoZSByZW1vdmVzIGhpcyBtb2Rp ZmljYXRpb24uKTxicj48YnI+VGhpcyBpcyBuZWNlc3NhcnksIGJ1dCBub3Qgc3VmZmljaWVudC4g SWYgd2UgYWxsb3cgbXVsdGlwbGUgY2xpZW50czxicj4oYWN0dWFsbHksIGlkZW50aXRpZXMsIHNp bmNlIHRoZSBzYW1lIGlkZW50aXR5IGNhbiBjb3ZlciBtdWx0aXBsZSBjbGllbnRzKTxicj50byBj aGFuZ2Ugc3RhdGUgcHJvZ3JhbW1hdGljYWxseSwgd2UgbXVzdCBhbGxvdyBmb3IgbWVjaGFuaXNt cyBmb3I8YnI+cHJvZ3JhbW1hdGljIHN0YXRlIHZhbGlkYXRpb24gYW5kIHRyb3VibGVzaG9vdGlu Zy48YnI+PGJyPkZvciBleGFtcGxlLCB3aGVuIHRoZXJlIGlzIGEgZmFpbG92ZXIgYmV0d2VlbiBh IHJlZHVuZGFudCBwYWlyIG9mIGNsaWVudHMsPGJyPnRoZSBuZXdseSBhY3RpdmUgY2xpZW50IGlu c3RhbmNlIG11c3QgcGVyZm9ybSBzdGF0ZSBzeW5jaHJvbml6YXRpb24sIHdoaWNoPGJyPmluY2x1 ZGVzIHJlYWRpbmcgYWxsIHRoZSBzdGF0ZSB0aGF0IHRoZSBwcmV2aW91c2x5IGFjdGl2ZSBpbnN0 YW5jZSBvZiB0aGU8YnI+Y2xpZW50IGluamVjdGVkIGludG8gdGhlIHN5c3RlbS4gVGhlcmVmb3Jl LCB0aGUgYWdlbnQgbmVlZHMgdG8ga25vdyB3aGljaDxicj5jbGllbnQgaW5qZWN0ZWQgd2hpY2gg c3RhdGUgaW50byBzeXN0ZW0gKGlmIHRoZSBhZ2VudCBkb2VzIG5vdCBkbyB0aGF0LCB3ZTxicj5u ZWVkIGFuIGV4dGVybmFsIGVudGl0eSwgc3VjaCBhcyB0aGUgY29udHJvbGxlciwgdG8ga2VlcCB0 cmFjayBvZiB0aGlzKS48YnI+PGJyPlNpbWlsYXJseSBmb3IgdHJvdWJsZXNob290aW5nIC0gd2hl biwgZm9yIGV4YW1wbGUsIGFuIG9wZXJhdG9yIHdhbnRzIHRvPGJyPnB1cmdlIHN0YXRlIG9mIGEg Y2xpZW50IHRoYXQgaXMvc2hvdWxkIG5vdCBiZSBhY3RpdmUgYW55bW9yZSwgdGhlIHN5c3RlbTxi cj5zaG91bGQgZmFjaWxpdGF0ZSB0aGlzIGFjdGlvbi4gQSBzdGF0ZSBwdXJnZSBmb3IgYSBjbGll bnQgY291bGQgaGFwcGVuLDxicj5mb3IgZXhhbXBsZSwgd2hlbiBhbiBvcGVyYXRvciB3YW50cyB0 byBzaHV0IGRvd24gYW4gYXBwbGljYXRpb24uPGJyPjxicj4mZ3Q7PGJyPiZndDtXaGVuIHRoaXMg ZmFpbHMsIGl0IGlzIGFuIGVycm9yLjxicj4mZ3Q7V2UgbmVlZCB0byBkZXRlY3QgdGhpcyBlcnJv ci48YnI+Jmd0O1NvIHRoZSBJMlJTIEFnZW50IGlzIHJlcXVpcmVkIHRvIGtlZXAgdHJhY2sgb2Yg ZW5vdWdoIGluZm9ybWF0aW9uIHRvPGJyPiZndDtkZXRlY3QgYW5kIHByb3ZpZGUgYSBwcmVkaWN0 YWJsZSBiZWhhdmlvciBpbiB0aGUgZXZlbnQgdGhpcyBvY2N1cnMuPGJyPiZndDtUaGUgcHJpb3Jp dHkgbWVjaGFuaXNtIGlzIGEgbWVjaGFuaXNtIGZvciBwcm92aWRpbmcgYmV0dGVyPGJyPiZndDtw cmVkaWN0YWJpbGl0eS4mbmJzcDsgSWYgd2UgZG9uJ3QgbGlrZSBpdCwgd2UgY2FuIGRpdGNoIGl0 Ljxicj48YnI+UHJpb3JpdHkgaXMgdXNlZnVsIC0gbm8gcmVhc29uIHRvIGRpdGNoIGl0LiBCdXQg aXQgaXMgbm90IHN1ZmZpY2llbnQgOi0pPGJyPjxicj4mZ3Q7PGJyPiZndDtJbiBwYXJ0aWN1bGFy LCBvbmUgY29ycm9sbGFyeSBvZiB0aGlzIGlzIHRoYXQgIm93bmVyc2hpcCIgZG9lcyBub3QsIGl0 PGJyPiZndDtzZWVtcyB0byBtZSwgYmVsb25nIGluIHRoZSBkYXRhIG1vZGVsLiZuYnNwOyBJdCBp cywgYXMgQWxpYSBhbmQgb3RoZXIgc2FpZCw8YnI+Jmd0O21ldGFkYXRhLjxicj48YnI+WWVzLCBp dCBpcyBtZXRhZGF0YS4gQnV0IGl0IHdvdWxkIGJlIHByZW1hdHVyZSB0byBleGNsdWRlIHRoZSBv cHRpb24gdG88YnI+cHJvdmlkZSBtZXRhZGF0YSBhbG9uZyB3aXRoIHRoZSBkYXRhIC0gdGhlcmUg YXJlIHBsZW50eSBvZiBzeXN0ZW1zIG91dDxicj50aGVyZSB0aGF0IGltcGxlbWVudCB0aGlzIGNv bmNlcHQgYW5kIHdvcmsgcXVpdGUgd2VsbC48YnI+PGJyPiZndDs8YnI+Jmd0O1lvdXJzLDxicj4m Z3Q7Sm9lbDxicj48YnI+VGhhbmtzLDxicj5KYW48YnI+PGJyPiZndDs8YnI+Jmd0O09uIDgvMjIv MTMgNjozNiBQTSwgQW5keSBCaWVybWFuIHdyb3RlOjxicj4mZ3Q7Jmd0OyBPbiBUaHUsIEF1ZyAy MiwgMjAxMyBhdCAyOjA4IFBNLCBKYW4gTWVkdmVkIChqbWVkdmVkKTxicj4mZ3Q7Jmd0OyZsdDtq bWVkdmVkQGNpc2NvLmNvbSZndDsgd3JvdGU6PGJyPiZndDsmZ3Q7Jmd0OyBIaSBBbGlhLDxicj4m Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IE9uIDgvMjIvMTMgMTE6MTMgQU0sICJBbGlhIEF0 bGFzIiAmbHQ7YWthdGxhc0BqdW5pcGVyLm5ldCZndDsgd3JvdGU6PGJyPiZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7IEhpIEp1ZXJnZW4sPGJyPiZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyBJIGFncmVlIHRoYXQgdGhlIG93bmVyc2hpcCBvZiBkYXRhIHNlZW1zIG1v cmUgbGlrZSBtZXRhLWRhdGEgdG8gbWU8YnI+Jmd0OyZndDsmZ3Q7Jmd0O3RoYW48YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyBhbnl0aGluZyBlbHNlLiZuYnNwOyBJIHJlYWxseSB3b3VsZCBwcmVmZXIgbm90 IHRvIGNsdXR0ZXIgdGhlIGRhdGEtbW9kZWxzPGJyPiZndDsmZ3Q7Jmd0OyZndDt3aXRoPGJyPiZn dDsmZ3Q7Jmd0OyZndDsgaXQuPGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgSXQgZGVw ZW5kcy4gSWYgb3duZXJzaGlwIGlzIGNvYXJzZSBncmFpbmVkLCB0aGVuIGhhdmluZyB0aGUgb3du ZXJzaGlwPGJyPiZndDsmZ3Q7Jmd0OyBtZXRhZGF0YSBpbiBhIHNlcGFyYXRlIHRyZWUgaXMgbWFu YWdlYWJsZS4gSWYgaXQncyBmaW5lLWdyYWluZWQsIGhhdmluZzxicj4mZ3Q7Jmd0OyZndDsgdGhl IG93bmVyc2hpcCBtZXRhZGF0YSBlbWJlZGRlZCBpbiB0aGUgZGF0YSB0cmVlIGlzIGVhc2llciAt IGJvdGggZm9yPGJyPiZndDsmZ3Q7Jmd0O3RoZTxicj4mZ3Q7Jmd0OyZndDsgc2VydmVyIGFzIHdl bGwgYXMgZm9yIHRoZSBjbGllbnRzLjxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IEkg dGhpbmsgd2l0aCBJMlJTLCBvd25lcnNoaXAgd2lsbCBsaWtlbHkgYmUgZmluZS1ncmFpbmVkLjxi cj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgSSB0aGluayB0aGlzICJvd25l ciIgY29uY2VwdCBuZWVkcyBhIGxvdCBtb3JlIHdvcmsuPGJyPiZndDsmZ3Q7IElmIG93bmVyIDEg aGFzIGEgaGlnaGVyIHByaW9yaXR5IHRoYW4gb3duZXIgMiwgdGhlbiBvd25lciAxIGNhbiBjbG9i YmVyPGJyPiZndDsmZ3Q7IGFueXRoaW5nIHRoYXQgb3duZXIgMiBhbHJlYWR5IGNyZWF0ZWQuJm5i c3A7IFRoYXQgZG9lc24ndCBzb3VuZCBmaW5lLWdyYWluZWQ8YnI+Jmd0OyZndDsgdG8gbWUuPGJy PiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IFRoZSAiZmlyc3Qgb25lIHdpbnMiIGNvbmNlcHQgb25seSBh cHBsaWVzIHRvIGNsaWVudHMgd2l0aCB0aGUgc2FtZTxicj4mZ3Q7Jmd0O3ByaW9yaXR5Ljxicj4m Z3Q7Jmd0OyBUaGUgImxhc3Qgb25lIHdpbnMiIHByb2JsZW0gaXMgYWRkcmVzc2VkIGJ5IGFzc2ln bmluZyBwcmlvcml0aWVzIHRvIHRoZTxicj4mZ3Q7Jmd0O2NsaWVudHMuPGJyPiZndDsmZ3Q7IE5v dyBpdCBpcyAiaGlnaGVzdCBwcmlvcml0eSB3aW5zIiB3aGljaCBpcyB3aGF0IGlzIGRlc2lyZWQu PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IElmIHRoZSBjbGllbnQgd3JpdGluZyBleGlzdGluZyBk YXRhIGhhcyB0aGUgc2FtZSBvciBsb3dlciBwcmlvcml0eSBhczxicj4mZ3Q7Jmd0O3RoZSBvd25l cjxicj4mZ3Q7Jmd0OyB0aGF0IHNldCB0aGUgZGF0YSwgdGhlbiB0aGUgYWNjZXNzIGlzIGRlbmll ZC4mbmJzcDsgKFByb2JsZW0gc29sdmVkLCBmaXJzdDxicj4mZ3Q7Jmd0O29uZSB3aW5zKS48YnI+ Jmd0OyZndDsgTkFDTSB3b3VsZCBuZWVkIHNvbWUgY2hhbmdlcyB0byBzdXBwb3J0IG93bmVyIHBy aW9yaXR5Ljxicj4mZ3Q7Jmd0OyBUaGUgYXVnbWVudHMgdGhhdCBoYXMgYmVlbiBwcm9wb3NlZCBp cyBpbnN1ZmZpY2llbnQ6PGJyPiZndDsmZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXJmZXJuYW5kby1pMnJzLXlhbmctbW9kcy0wMCNzZWN0aW9uLTMuNjxicj4mZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyAoSU1PLCBvbmx5IHNlYy4gMy42IG9mIHRoaXMgZHJhZnQgaXMgbmVlZGVkLik8 YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7IEkgdGhpbmsgdGhlcmUgYXJlIHR3byAoYXQgbGVhc3QhKSBzZXBhcmF0ZSBhc3BlY3Rz IHRoYXQgd2UgbmVlZCB0bzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7ZmlndXJlPGJyPiZndDsmZ3Q7Jmd0 OyZndDsgb3V0LiZuYnNwOyBPbmUgaXMgdGhlIHBlcm1pc3Npb25zIGFzcGVjdCAtIHdoZXJlIHdl IG5lZWQgdG8gYmUgYWJsZSB0bzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Y2xlYXJseTxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7IGV4cHJlc3Mgd2hhdCBzY29wZSBhIHBhcnRpY3VsYXIgcm9sZSBoYXMuPGJyPiZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgQWdyZWVkLjxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBUaGUgc2Vjb25kIGlzIHdoYXQgYW4gaTJycyBhZ2Vu dCBuZWVkcyB0byBzdG9yZSwgbWFuaXB1bGF0ZSwgYW5kPGJyPiZndDsmZ3Q7Jmd0OyZndDtyZXBv cnQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBiYWNrLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsm Z3Q7Jmd0OyZndDsgRm9yIHRoZSBsYXR0ZXIsIHRoZSBiYXNpYyBjb25jZXB0IGlzIGRlc2NyaWJl ZCBpbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IGRyYWZ0LWlldGYtaTJycy1hcmNoaXRlY3R1cmUtMDAg c3BsaXQgYWNyb3NzIFNlYyA1LjIsIDYuOCwgYW5kIDYuNDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7KHdo aWNoPGJyPiZndDsmZ3Q7Jmd0OyZndDsgZGlzY3Vzc2VzIGlkZW50aXR5KS4mbmJzcDsgSW4gU2Vj IDUuMiwgaXQgc2F5czo8YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICJUaGUgSTJSUyBhZ2VudCBzdG9yZXMgdGhlIHNldCBvZjxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wZXJhdGlvbnMgaXQgaGFzIGFwcGxpZWQu Jm5ic3A7IFNpbXBseSwgdGhlIEkyUlMgYWdlbnQgc3RvcmVzIHdobyBkaWQ8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB3aGF0IG9wZXJhdGlvbiB0byB3aGljaCBlbnRpdHku Jm5ic3A7IE5ldyBjaGFuZ2VzIHJlcGxhY2UgYW55IGRhdGEgYWJvdXQ8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBvbGQgb25lcy4mbmJzcDsgSWYgYW4gSTJSUyBjbGllbnQg ZG9lcyBhbiBvcGVyYXRpb24gdG8gcmVtb3ZlIHNvbWU8YnI+Jmd0OyZndDsmZ3Q7Jmd0O3N0YXRl LDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgc3RhdGUgaXMgcmVt b3ZlZCBhbmQgdGhlIEkyUlMgYWdlbnQgc3RvcmVzIG5vIG1vcmUgaW5mb3JtYXRpb248YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBhYm91dCBpdC4mbmJzcDsgVGhpcyBhbGxv d3MgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gZGV0ZXJtaW5lIHdoYXQgdGhlPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgY3VycmVudCBlZmZlY3Qgb2YgSTJSUyBvbiB0aGUg c3lzdGVtIGlzLCBhbmQgd2h5LiZuYnNwOyBNZWFuaW5nZnVsPGJyPiZndDsmZ3Q7Jmd0OyZndDts b2dnaW5nPGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgYWxzbyByZWNv bW1lbmRlZC4iPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IElmIGEgY2xpZW50 IGlzIHJlYWxseSBhIGJyb2tlciwgdGhlbiBpcyB0aGUgb3duZXIgc3RyaW5nIGdvaW5nIHRvIGJl PGJyPiZndDsmZ3Q7Zm9yIHRoZTxicj4mZ3Q7Jmd0OyB1cHN0cmVhbSBhcHBsaWNhdGlvbiBvciB0 aGUgYnJva2VyPyZuYnNwOyBXaGljaCBjbGllbnRzIGFyZSBsaWtlbHkgdG88YnI+Jmd0OyZndDsg aGF2ZSB0aGUgc2FtZSBwcmlvcml0eSBhbmQgY29sbGlkZSBvbiB0aGUgc2FtZSBkYXRhPzxicj4m Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZn dDsgQWxpYTxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IC9KYW48YnI+Jmd0OyZndDs8 YnI+Jmd0OyZndDsgQW5keTxicj4mZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJyPiZn dDsmZ3Q7IG5ldG1vZEBpZXRmLm9yZzxicj4mZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZDxicj4mZ3Q7Jmd0Ozxicj48YnI+PC9kaXY+IDwvYm9keT4= ----_com.android.email_307628585996187-- From lhotka@nic.cz Mon Aug 26 01:07:26 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009FA11E817F for ; Mon, 26 Aug 2013 01:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, HOST_EQ_CZ=0.904, 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 4tBugkN8yxOH for ; Mon, 26 Aug 2013 01:07:15 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB8B11E8177 for ; Mon, 26 Aug 2013 01:07:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 69931540216; Mon, 26 Aug 2013 10:06:48 +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 YKEkm24VVKaA; Mon, 26 Aug 2013 10:06:42 +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 B52FA54018C; Mon, 26 Aug 2013 10:06:36 +0200 (CEST) From: Ladislav Lhotka To: "Muthumayan Madhayyan \(muthu\)" , Andy Bierman , Juergen Schoenwaelder , "Jan Medved \(jmedved\)" , Alia Atlas , "i2rs-chairs\@tools.ietf.org" , Nitin Bahadur , "netmod\@ietf.org" , "Alexander Clemm \(alex\)" In-Reply-To: <5A949C32AF740C4798AEECF2568F0D840C15F90B@xmb-rcd-x13.cisco.com> References: <5A949C32AF740C4798AEECF2568F0D840C15F90B@xmb-rcd-x13.cisco.com> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: "Muthumayan Madhayyan \(muthu\)" , Andy Bierman , Juergen Schoenwaelder , "Jan Medved \(jmedved\)" , Alia Atlas , "i2rs-chairs\@tools.ietf.org" , Nitin Bahadur , "netmod\@ietf.org" , "Alexander Clemm \(alex\)" Date: Mon, 26 Aug 2013 10:06:35 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 08:07:26 -0000 "Muthumayan Madhayyan (muthu)" writes: > On 8/23/13 7:25 AM, "Andy Bierman" wrote: > >>On Tue, Aug 20, 2013 at 9:49 PM, Juergen Schoenwaelder >> wrote: >>> On Tue, Aug 20, 2013 at 10:55:06PM +0000, Muthumayan Madhayyan (muthu) >>>wrote: >>>> Hello Lada, >>>> >>>> Apart from the ability to write ephemeral data, I2RS also has a >>>> requirement to associate client ownership to data injected by an >>>>external >>>> client. In NETCONF, the stores are global. >>>> >>> >>> Well, this sounds like a NETCONF requirement, not a YANG requirement. >> >>+1 >> >>The owner is a property of the datastore, not the data model. >>Ditto for the "ephemeral" YANG extension. I don't see the need >>for any YANG extensions, just protocol extensions. > > There is no central 'datastore' for those schema nodes marked ephemeral. > The i2rs client directly talks to an i2rs server that does not provide any > form of storage, but relays all requests to relevant backend applications > with adequate metadata like client identification and relative priority > etc to the backend. All data injected by i2rs clients are maintained by > the backend i2rs applications. In that sense this deviates a lot from > traditional NETCONF datastore. Hope that explains why an 'ephemeral' > extension is needed. I think we have to be careful with terminology because YANG is defined for the specific NETCONF context. My understanding is that the "I2RS data store" is (a subset of) operational state data in NETCONF/YANG terms, which are by definition read-only - but only for the NETCONF protocol! There can be (and usually are) other means for for changing directly the underlying parameters and structures, and I2RS will be one of them. So, if YANG was to be used as the data modelling language for I2RS data, it IMO means that: 1. The YANG "config" statement is irrelevant because everything is essentially "config false". 2. A flag is needed to indicate the data that can be written by I2RS clients. A YANG extension can be used for this purpose. 3. The ownership information has to be managed by I2RS backend applications. There is no need to deal with it in the data model, and it is up to the I2RS protocol to define a way for attaching the ownership info to the data sent to the client (if it is needed). Also, I understand that all changes performed by I2RS clients are ephemeral, so isn't the distinction really between read-only and read-write? Lada > >> >> >> >>> >>> /js >> >>Andy > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Aug 26 07:13:24 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586A111E81A5 for ; Mon, 26 Aug 2013 07:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 YUi+EUw6B-jE for ; Mon, 26 Aug 2013 07:13:20 -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 735B411E8197 for ; Mon, 26 Aug 2013 07:13:20 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id q10so3471792pdj.7 for ; Mon, 26 Aug 2013 07:13:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZUye6S4kVlEolfMRAuVk8qG8ZXoHyB38Fkw03Wg2In0=; b=Yn+V8eZWRhGk9RdR/56C2U/TuoJ6wvY2B8Q2vDZbilcuoixKLay5A5DfrxyneYvmSL tOcP5dCEBqEo50X69fqC+HgdIFGPHWMU1scde5E/L5fx//9fjOiyHg8EjfQmb2n147js 1fQ0KDbJEkoUE+ol+3dP1Zy/9w1A7rU2e6oKjd5A4r+c9QbrX+xkgiSYwaYpOhw0dHDE 072LrF9oAl7CueHTUDcuz+b3rS1/BptfwO4zCJNFSwNz8snwwXLcO4lkiLpvTdNsiTrs 1ycO8WDaVj7K05caWXPiyUqXrqpTCq5hkYc1F7Hb6F4+c2kX5YFtyH/FikU2iiqHoUCd 2OXg== X-Gm-Message-State: ALoCoQncdsFknT0oi9UQ+Qsxp01dXngOw5pOG1x8a6kXLZkGWT9v0MJPlU5wbpNFUNwpD6K1ygjG MIME-Version: 1.0 X-Received: by 10.68.212.199 with SMTP id nm7mr3110509pbc.177.1377526400065; Mon, 26 Aug 2013 07:13:20 -0700 (PDT) Received: by 10.70.41.162 with HTTP; Mon, 26 Aug 2013 07:13:19 -0700 (PDT) In-Reply-To: <5A949C32AF740C4798AEECF2568F0D840C15F8E2@xmb-rcd-x13.cisco.com> References: <20130822173732.GB7508@elstar.local> <5A949C32AF740C4798AEECF2568F0D840C15F8E2@xmb-rcd-x13.cisco.com> Date: Mon, 26 Aug 2013 07:13:19 -0700 Message-ID: From: Andy Bierman To: "Muthumayan Madhayyan (muthu)" Content-Type: text/plain; charset=ISO-8859-1 Cc: Alia Atlas , Nitin Bahadur , "i2rs-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 14:13:24 -0000 On Sun, Aug 25, 2013 at 10:28 PM, Muthumayan Madhayyan (muthu) wrote: > > > On 8/22/13 10:37 AM, "Juergen Schoenwaelder" > wrote: > >>On Thu, Aug 22, 2013 at 04:57:45PM +0000, Muthumayan Madhayyan (muthu) >>wrote: >>> Hello David, >>> >>> Please see inline: >>> >>> On 8/21/13 8:50 AM, "David Harrington" wrote: >>> >>> >Hi, >>> > >>> >I have some questions about this requirement to associate client >>>ownership >>> >to injected data. >>> > >>> >1) at what level of detail is the data ownership? >>> >Are we talking about specific subtrees in the datastore, or a complete >>> >datastore (e.g., a variation on candidate)? >>> >If we are talking ownership of a datastore, then this would seem to be >>>a >>> >netconf requirement. >>> >If we are talking ownership of a row in a routing table, or something >>> >similar, then the ownership probably needs to be part of the data >>>model, >>> >comparable to OwnerStrings in the MIB. >>> >>> The ownership is on a specific sub-tree and this is why we needed data >>> model >>> to express it. >>> > >>> >2) Can a client only assert their own ownership of a data subset, or >>>can >>> >they assert that somebody else is the owner? >>> >>> >>> Every subset created in runtime has an ownership tagged to it. Now, the >>> client that created the data is the owner. If this data model states >>>that >>> the data subset is 'exclusive', then only the owner can modify or delete >>> that subset. Else other clients can get read-write access to that any >>> instance of the data sub-set created by another client. >>> >>> >>> >For example, if an operator determines that a static route should be >>>added >>> >to a routing table, based on looking at the hosts file of another node, >>> >can the operator set the ownership to be a URL to that file, or MUST >>>the >>> >ownership be the ID for the user/operator who is setting the >>>information? >>> >>> As defined currently, it is the ID of the user/operator. >>> >> >>I am confused. Lets see. If an I2RS client creates a 'foo' in >>operational state, then I think you want 'foo' associated with the >>identifier 'joe' representing the identity of the client. Is that >>automatic (the mere fact that the client authenticated as 'joe' means >>'foo' belongs to 'joe') or do you want 'joe' to be explicit, that >>is joe actually says "create 'foo' owned by 'joe'"? > > i2rs at the time of writing had 'foo' belongs to 'joe' type of requirement > . So, assuming you have a global operational table, each row could be > potentially owned by different clients. > >> >>> >3) If #2 requires the client-as-owner, must the client ID be >>> >authenticated? If the proposal uses NACM to perform the authentication, >>> >then you would presumably create a binding between the ACM mechanism >>> >(e.g., NACM) and the specific data model. >>> >>> Yes, the intent was to tie NACM to do the authentication. >> >>I am confused. NACM does authorization, not authentication. > > That is true. NACM RFC talks about use of RADIUS for authentication and > mapping users to user-groups. We could adopt the same or better approach > for i2rs. > >> If you >>want to restrict access to 'foo' to 'joe', NACM would need a rule that >>says access to 'foo' is restricted to 'joe'. Depending on the answer >>to 2), the question is how the rule is being injected into NACM (if >>you were to use NACM and NACM would apply to writable operational >>state). But then, NACM - as far as I understand it - can only perform >>access decisions on data that is explicit in the data model. I am >>actually not sure you want to 'clutter' all your data models with >>additional leafs to express ownership - this really smells much more >>like meta-data. > > NACM is used for mainly for specifying a relative priority for a > user-group. The reason for those additional ownership leaf objects is not > such much for the 'write'. During write, the owner field is actually > meta-data. But then there is a 'read' aspect as well. Any client should be > able to access data that was created by some other client. Client A wants > to know about routes injected by another Client B or C. > This seems like a security hole. It may be be a good idea for all data to be readable by all other clients. There are ways to include meta-data in protocol responses. Unless a router needs the owner name "fred" to forward packets, then the owner name is not part of the routing table entry data. >> >>> >4) There has been discussion of trying to make YANG protocol >>>independent. >>> >To maintain such independence, would the data model need to be written >>> >such that the user/client ID is protocol-independent? Could any ACM >>>model >>> >be used to provide the user identity and authentication, not just NACM >>> >(and not just Netconf)? Compare for example, the ability for SNMPv3 to >>>use >>> >multiple co-existing security models. Is this the direction this >>>proposal >>> >would require? >>> >>> Any ACM should do. It was just easier to extend NACM group settings to >>>add >>> a client priority. >> >>Hm. It might be good to work out a more detailed example of what I2RS >>may want. Or can someone point to the parts of the architecture I-D >>where this is clearly described? >> >>/js >> >>-- >>Juergen Schoenwaelder Jacobs University Bremen gGmbH >>Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Andy From andy@yumaworks.com Mon Aug 26 07:24:46 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED1611E819F for ; Mon, 26 Aug 2013 07:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=0.317, 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 hnhNSRq-emnW for ; Mon, 26 Aug 2013 07:24:41 -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 3850111E8194 for ; Mon, 26 Aug 2013 07:24:41 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj1so3516587pad.0 for ; Mon, 26 Aug 2013 07:24:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lqh1lCZf2vvO9v/zceKUbGrEghh6H1gscE8QdmIiets=; b=RhjQf0uEpVD0V4FQiJNHxGTW8ez2L2HM1YFR+40rJEVJfjm4m+OsxmINDo1pYbvTP/ QhX5IaDR/KwRz08NT3XS1wy61lw6e5uizwgCv2/g8aqjO2u0sWoiD/egIexNEmR+pacA NVuoIpiAeQ3Hjhd/Sd89zK4of0STsWxxghhqWuFST+gTD3h0NyeIQ5I6epysfzPro/eB IhXjk+O0Q46eviQvZgtJOAP6z/Jre2dGgOpcb5TX7a5R7fntoAabW/jRGDYAbt6j3KcE aM8aeYLeZPjo3QX1MfocbL70/ELJYVELVfx/Vg9Pu+Tuleocmkpczj4r+KHen9JlpMS0 /pbg== X-Gm-Message-State: ALoCoQkA6u/VBnZJoGMbqLBgPQVxpy/nzK7tPjngHj0uPHYzPqO0v5LTuoFGyuP6jTSCqKPdl06t MIME-Version: 1.0 X-Received: by 10.68.189.5 with SMTP id ge5mr15827743pbc.42.1377527079037; Mon, 26 Aug 2013 07:24:39 -0700 (PDT) Received: by 10.70.41.162 with HTTP; Mon, 26 Aug 2013 07:24:38 -0700 (PDT) In-Reply-To: <5A949C32AF740C4798AEECF2568F0D840C15F90B@xmb-rcd-x13.cisco.com> References: <5A949C32AF740C4798AEECF2568F0D840C15F90B@xmb-rcd-x13.cisco.com> Date: Mon, 26 Aug 2013 07:24:38 -0700 Message-ID: From: Andy Bierman To: "Muthumayan Madhayyan (muthu)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "netmod@ietf.org" , Nitin Bahadur , Alia Atlas , "i2rs-chairs@tools.ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 14:24:46 -0000 On Sun, Aug 25, 2013 at 10:40 PM, Muthumayan Madhayyan (muthu) wrote: > > > On 8/23/13 7:25 AM, "Andy Bierman" wrote: > >>On Tue, Aug 20, 2013 at 9:49 PM, Juergen Schoenwaelder >> wrote: >>> On Tue, Aug 20, 2013 at 10:55:06PM +0000, Muthumayan Madhayyan (muthu) >>>wrote: >>>> Hello Lada, >>>> >>>> Apart from the ability to write ephemeral data, I2RS also has a >>>> requirement to associate client ownership to data injected by an >>>>external >>>> client. In NETCONF, the stores are global. >>>> >>> >>> Well, this sounds like a NETCONF requirement, not a YANG requirement. >> >>+1 >> >>The owner is a property of the datastore, not the data model. >>Ditto for the "ephemeral" YANG extension. I don't see the need >>for any YANG extensions, just protocol extensions. > > There is no central 'datastore' for those schema nodes marked ephemeral. > The i2rs client directly talks to an i2rs server that does not provide any > form of storage, but relays all requests to relevant backend applications > with adequate metadata like client identification and relative priority > etc to the backend. All data injected by i2rs clients are maintained by > the backend i2rs applications. In that sense this deviates a lot from > traditional NETCONF datastore. Hope that explains why an 'ephemeral' > extension is needed. > The datastore is conceptual -- it is just an abstraction for the API. None of the NETCONF datastores are required to be implemented as a centralized tree. All NETCONF 'running' datastore contents have "back-end" components that translate the API data into device behavior -- it is exactly the same for I2RS (except the dynamic datastore has different ownership and validation requirements). >> >> >> >>> >>> /js >> >>Andy > Andy From akatlas@gmail.com Mon Aug 26 08:08:49 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9EB21E8055 for ; Mon, 26 Aug 2013 08:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 3jFTHMr-kXEJ for ; Mon, 26 Aug 2013 08:08:48 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEBB21F9D2B for ; Mon, 26 Aug 2013 08:08:45 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id ef5so3347212obb.37 for ; Mon, 26 Aug 2013 08:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TYltA9TFLXUcUfibu3Er687zamcsGwqrks7Dg7hP6Js=; b=0X59FQhVlRzvzJAHPLUv8gETZ7DVQlJ7F6PEf7+JyBzNWYKt0/oonMsuPmQJmKxCow A8hU025/Zh5qwVQSzqE0TfxzxxZFlqvK8dJ3Qz52tjCL4pVa+8xSpNj62mcoxwex5nry zPsZ3W/cIpxU+y4u4AOCpNwxp+btooBiPNZHzgaZiXAc2pqqvzOrdJLEW1Zt1qw6MbZ5 BIIgVvy2Z+wX+SyoYtLDUmpFkqi+O27DsVQpSk0vyfO8VRyp7stHRAHXwHm3rrkfN4Wp v/tbA62ETUHGrqIVIqECdNbG9J/ghZqHd5z28M5QVmkwQK7HBi5v1Uzig0UoJz2A/pSe gcoA== MIME-Version: 1.0 X-Received: by 10.60.138.136 with SMTP id qq8mr1151882oeb.59.1377529724786; Mon, 26 Aug 2013 08:08:44 -0700 (PDT) Received: by 10.182.89.105 with HTTP; Mon, 26 Aug 2013 08:08:44 -0700 (PDT) In-Reply-To: <20130819082320.GA62925@elstar.local> References: <20130813.220912.447857853.mbj@tail-f.com> <20130814.165235.319391216.mbj@tail-f.com> <56010AF8-450D-4645-AF32-C33F74865C24@nic.cz> <20130815064413.GA8087@elstar.local> <5F1B12E3-5A49-4DA4-8233-B271F978B75B@nic.cz> <20130819082320.GA62925@elstar.local> Date: Mon, 26 Aug 2013 11:08:44 -0400 Message-ID: From: Alia Atlas To: Juergen Schoenwaelder , Alia Atlas , Ladislav Lhotka , "netmod@ietf.org" , "i2rs-chairs@tools.ietf.org" , Nitin Bahadur Content-Type: multipart/alternative; boundary=047d7b41ccf8e9e1c204e4db212b Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 15:08:49 -0000 --047d7b41ccf8e9e1c204e4db212b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 19, 2013 at 4:23 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Aug 15, 2013 at 04:12:28PM +0000, Alia Atlas wrote: > > > > Of course. We need to identify places where our routing model cannot be > augmented to suit I2RS needs, due to either its current design or > limitations in YANG. I hope the *needs* can be formulated soon. > > > > [Alia] First, I certainly agree that NetMod shouldn't wait until I2RS is > finished. I do think that the routing model and the RIB info-model are > trying to support different things. It may make sense that the routing > model has higher abstractions, does different or additional configuration, > and so on. That said, I do think the RIB info-model draft is fairly > accurate in describing what is needed for the RIB - and that can support a > wide range of static routes. However, in routing, usually there are higher > level abstractions that are applied for accuracy and ease; one can put an > MPLS label on an outgoing packet - but this is frequently modeled as going > into an LSP or a tunnel or connected to LDP's FECs or an L3VPN or so on. > > > > Alia, I think basic concepts and terminology should be aligned between > a standard routing configuration interface and a standard routing > state manipulation interface. I surely expect that the I2RS info model > goes beyond what we have in NETMOD but for the core bits and pieces > (basic concepts and in particular also terminology), I think the > industry will benefit if things turn out to be reasonably consistent. > I hope by Vancouver we are in a situation where basic concepts and > terminology have already started to converge. This would be great. > > Juergen, I agree that basic concepts and terminology should be aligned. For the RIB, many other routing concepts and abstractions are built on top of it and it isn't usually exposed as such at the management interface. For instance, the RIB info model has the next-hop chains which are ways of imposing additional headers and specifying their details. At the network management layer, those would be exposed as tunnels. For different routing, they might be exposed as MPLS out-segments, or LSPs or MPLS tunnels. Another example is the ability to specify load-balancing amounts per next-hop. At the management interface and for routing protocols, multiple next-hops can be specified, but an even distribution of traffic across the next-hops is assumed. Different hardware may have different ranges and precision for load-balancing. So - I agree that converging common basic concepts and terminology is very good. I'm just concerned that the multiple abstractions built on top of the RIB are not as clear in part because the initial focus for the YANG routing model is on static routes. Alia > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7b41ccf8e9e1c204e4db212b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 19, 2013 at 4:23 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote= :
On Thu, Aug 15, 2013 at 04:12:28PM +0000, Alia = Atlas wrote:
>
> Of course. We need to identify places where our routing model cannot b= e augmented to suit I2RS needs, due to either its current design or limitat= ions in YANG. I hope the *needs* can be formulated soon.
>
> [Alia] First, I certainly agree that NetMod shouldn't wait until I= 2RS is finished. =A0I do think that the routing model and the RIB info-mode= l are trying to support different things. =A0It may make sense that the rou= ting model has higher abstractions, does different or additional configurat= ion, and so on. =A0That said, I do think the RIB info-model draft is fairly= accurate in describing what is needed for the RIB - and that can support a= wide range of static routes. =A0However, in routing, usually there are hig= her level abstractions that are applied for accuracy and ease; one can put = an MPLS label on an outgoing packet - but this is frequently modeled as goi= ng into an LSP or a tunnel or connected to LDP's FECs or an L3VPN or so= on.
>

Alia, I think basic concepts and terminology should be aligned betwee= n
a standard routing configuration interface and a standard routing
state manipulation interface. I surely expect that the I2RS info model
goes beyond what we have in NETMOD but for the core bits and pieces
(basic concepts and in particular also terminology), I think the
industry will benefit if things turn out to be reasonably consistent.
I hope by Vancouver we are in a situation where basic concepts and
terminology have already started to converge. This would be great.

Juergen,

I agree that basic concepts and t= erminology should be aligned. =A0For the RIB, many other routing concepts a= nd abstractions are built on top of it and it isn't usually exposed as = such at the management interface. =A0For instance, the RIB info model has t= he next-hop chains which are ways of imposing additional headers and specif= ying their details. =A0At the network management layer, those would be expo= sed as tunnels. =A0For different routing, they might be exposed as MPLS out= -segments, or LSPs or MPLS tunnels. =A0Another example is the ability to sp= ecify load-balancing amounts per next-hop. =A0At the management interface a= nd for routing protocols, multiple next-hops can be specified, but an even = distribution of traffic across the next-hops is assumed. =A0 Different hard= ware may have different ranges and precision for load-balancing.

So - I agree that converging common basic concepts and = terminology is very good. =A0I'm just concerned that the multiple abstr= actions built on top of the RIB are not as clear in part because the initia= l focus for the YANG routing model is on static routes. =A0

Alia
/js

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

--047d7b41ccf8e9e1c204e4db212b-- From akatlas@gmail.com Mon Aug 26 08:12:48 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8B021F9BD1 for ; Mon, 26 Aug 2013 08:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 Rhzs74i+-l-R for ; Mon, 26 Aug 2013 08:12:47 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 63E7721F96EF for ; Mon, 26 Aug 2013 08:12:47 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so3316884obc.6 for ; Mon, 26 Aug 2013 08:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cQvMLS7jP8RQo6JMx0+9vyT7gLvfBFZz+lqtuWLYiEo=; b=iWZ7Yx6S27cX+mVO9yxfw3YcTMmlijWZSVX4P7S6YoprWkD0Bqqpxhy/p2qQ7ZLMzz t+y8vhOck5WUd1MvjCWiwSJnPoNYKXe+IISPLCY7AcIvpzmY1rs6pqab43YD6ODFYHFo PLvL542TEWRYYmHx7zGo+GhnPYX9cWvvgZojvLa7IRhOaHG6yqp6p9wAwB0t5AAco/mY ZpW5qogZ0ZG6MTYfvsqTPICiN+EsbKoHlWWY+BgtHzKvi7GCiDUgQ2D5sVjmi3Qj/5JP +DGThS3tSi9Uz22guEu7Lxl4p4d0AF9AQ0wE/cmNPXN+E2HPuBKT4F0N1HSMdfZWTETp Gu2g== MIME-Version: 1.0 X-Received: by 10.182.101.165 with SMTP id fh5mr1302357obb.58.1377529966957; Mon, 26 Aug 2013 08:12:46 -0700 (PDT) Received: by 10.182.89.105 with HTTP; Mon, 26 Aug 2013 08:12:46 -0700 (PDT) In-Reply-To: References: <5A949C32AF740C4798AEECF2568F0D840C15F90B@xmb-rcd-x13.cisco.com> Date: Mon, 26 Aug 2013 11:12:46 -0400 Message-ID: From: Alia Atlas To: Andy Bierman Content-Type: multipart/alternative; boundary=e89a8f6436d259193a04e4db30d8 Cc: Nitin Bahadur , Alia Atlas , "i2rs-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 15:12:48 -0000 --e89a8f6436d259193a04e4db30d8 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 26, 2013 at 10:24 AM, Andy Bierman wrote: > On Sun, Aug 25, 2013 at 10:40 PM, Muthumayan Madhayyan (muthu) > wrote: > > > > > > On 8/23/13 7:25 AM, "Andy Bierman" wrote: > > > >>On Tue, Aug 20, 2013 at 9:49 PM, Juergen Schoenwaelder > >> wrote: > >>> On Tue, Aug 20, 2013 at 10:55:06PM +0000, Muthumayan Madhayyan (muthu) > >>>wrote: > >>>> Hello Lada, > >>>> > >>>> Apart from the ability to write ephemeral data, I2RS also has a > >>>> requirement to associate client ownership to data injected by an > >>>>external > >>>> client. In NETCONF, the stores are global. > >>>> > >>> > >>> Well, this sounds like a NETCONF requirement, not a YANG requirement. > >> > >>+1 > >> > >>The owner is a property of the datastore, not the data model. > >>Ditto for the "ephemeral" YANG extension. I don't see the need > >>for any YANG extensions, just protocol extensions. > > > > There is no central 'datastore' for those schema nodes marked ephemeral. > > The i2rs client directly talks to an i2rs server that does not provide > any > > form of storage, but relays all requests to relevant backend applications > > with adequate metadata like client identification and relative priority > > etc to the backend. All data injected by i2rs clients are maintained by > > the backend i2rs applications. In that sense this deviates a lot from > > traditional NETCONF datastore. Hope that explains why an 'ephemeral' > > extension is needed. > > > > The datastore is conceptual -- it is just an abstraction for the API. > None of the NETCONF datastores are required to be implemented > as a centralized tree. All NETCONF 'running' datastore contents > have "back-end" components that translate the API data into > device behavior -- it is exactly the same for I2RS (except the > dynamic datastore has different ownership and validation requirements). > For what it's worth, I've been picturing that the I2RS agent stores the ownership information and other I2RS-specific meta-data. What is written and read is pushed into the "back-end" components. But I think this is basically an implementation decision. Alia > >> > >> > >> > >>> > >>> /js > >> > >>Andy > > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --e89a8f6436d259193a04e4db30d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 26, 2013 at 10:24 AM, Andy Bierman <andy@y= umaworks.com> wrote:
On S= un, Aug 25, 2013 at 10:40 PM, Muthumayan Madhayyan (muthu)
<muthu@cisco.com> wrote:
>
>
> On 8/23/13 7:25 AM, "Andy Bierman" <andy@yumaworks.com> wrote:
>
>>On Tue, Aug 20, 2013 at 9:49 PM, Juergen Schoenwaelder
>><j.schoe= nwaelder@jacobs-university.de> wrote:
>>> On Tue, Aug 20, 2013 at 10:55:06PM +0000, Muthumayan Madhayyan= (muthu)
>>>wrote:
>>>> Hello Lada,
>>>>
>>>> Apart from the ability to write ephemeral data, I2RS also = has a
>>>> requirement to associate client ownership to data injected= by an
>>>>external
>>>> client. In NETCONF, the stores are global.
>>>>
>>>
>>> Well, this sounds like a NETCONF requirement, not a YANG requi= rement.
>>
>>+1
>>
>>The owner is a property of the datastore, not the data model.
>>Ditto for the "ephemeral" YANG extension. =A0I don't = see the need
>>for any YANG extensions, just protocol extensions.
>
> There is no central 'datastore' for those schema nodes marked = ephemeral.
> The i2rs client directly talks to an i2rs server that does not provide= any
> form of storage, but relays all requests to relevant backend applicati= ons
> with adequate metadata like client identification and relative priorit= y
> etc to the backend. All data injected by i2rs clients are maintained b= y
> the backend i2rs applications. In that sense this deviates a lot from<= br> > traditional NETCONF datastore. Hope that explains why an 'ephemera= l'
> extension is needed.
>

The datastore is conceptual =A0-- it is just an abstraction for= the API.
None of the NETCONF datastores are required to be implemented
as a centralized tree. =A0All NETCONF 'running' datastore contents<= br> have "back-end" components that translate the API data into
device behavior -- it is exactly the same for I2RS (except the
dynamic datastore has different ownership and validation requirements).
=

For what it's worth, I've been pic= turing that the I2RS agent stores the ownership information and other I2RS-= specific meta-data. =A0What is written and read is pushed into the "ba= ck-end" components. =A0But I think this is basically an implementation= decision.

Alia=A0
=A0
>>
>>
>>
>>>
>>> /js
>>
>>Andy
>

Andy
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--e89a8f6436d259193a04e4db30d8-- From akatlas@juniper.net Mon Aug 26 08:46:24 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDE511E81A9 for ; Mon, 26 Aug 2013 08:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ybUqjB+iCSbq for ; Mon, 26 Aug 2013 08:46:19 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 57B3811E81A3 for ; Mon, 26 Aug 2013 08:46:18 -0700 (PDT) Received: from mail97-am1-R.bigfish.com (10.3.201.234) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.22; Mon, 26 Aug 2013 15:46:16 +0000 Received: from mail97-am1 (localhost [127.0.0.1]) by mail97-am1-R.bigfish.com (Postfix) with ESMTP id 0681C180098; Mon, 26 Aug 2013 15:46:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I146fI542I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah186068h8275bh8275dh1de097hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail97-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=akatlas@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(479174003)(199002)(189002)(52314003)(164054003)(24454002)(13464003)(51704005)(83322001)(19580395003)(46102001)(19580405001)(80976001)(51856001)(81542001)(4396001)(74502001)(69226001)(47446002)(15975445006)(31966008)(50986001)(47976001)(81342001)(47736001)(49866001)(74662001)(65816001)(66066001)(80022001)(77096001)(56816003)(63696002)(59766001)(77982001)(81816001)(53806001)(76576001)(74316001)(54316002)(76786001)(54356001)(79102001)(56776001)(33646001)(76796001)(76482001)(83072001)(74366001)(81686001)(74706001)(74876001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB050; H:BL2PR05MB193.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail97-am1 (localhost.localdomain [127.0.0.1]) by mail97-am1 (MessageSwitch) id 137753197445548_26759; Mon, 26 Aug 2013 15:46:14 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.238]) by mail97-am1.bigfish.com (Postfix) with ESMTP id 0763860054; Mon, 26 Aug 2013 15:46:14 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 26 Aug 2013 15:46:13 +0000 Received: from BL2PR05MB050.namprd05.prod.outlook.com (10.255.228.146) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.347.3; Mon, 26 Aug 2013 15:46:08 +0000 Received: from BL2PR05MB193.namprd05.prod.outlook.com (10.242.198.143) by BL2PR05MB050.namprd05.prod.outlook.com (10.255.228.146) with Microsoft SMTP Server (TLS) id 15.0.745.25; Mon, 26 Aug 2013 15:46:07 +0000 Received: from BL2PR05MB193.namprd05.prod.outlook.com ([169.254.9.249]) by BL2PR05MB193.namprd05.prod.outlook.com ([169.254.9.249]) with mapi id 15.00.0745.000; Mon, 26 Aug 2013 15:46:07 +0000 From: Alia Atlas To: "Jan Medved (jmedved)" , "Joel M. Halpern" , Andy Bierman Thread-Topic: [netmod] i2rs client ownership Thread-Index: AQHOnoZEcTLC2m5QM0Cu3jp6MtVMc5mhdGWAgAALIACAAAhcgIAAMqEAgAAYdoCAAkltAIACve+AgADOnUA= Date: Mon, 26 Aug 2013 15:46:06 +0000 Message-ID: <4d59d45d7ca04c79958b36fa298b7f27@BL2PR05MB193.namprd05.prod.outlook.com> References: <52187D76.2030001@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0950706AC1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Nitin Bahadur , "i2rs-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 15:46:24 -0000 -----Original Message----- From: Jan Medved (jmedved) [mailto:jmedved@cisco.com]=20 Sent: Sunday, August 25, 2013 11:24 PM To: Joel M. Halpern; Andy Bierman Cc: netmod@ietf.org; Nitin Bahadur; Alia Atlas; i2rs-chairs@tools.ietf.org Subject: Re: [netmod] i2rs client ownership On 8/24/13 2:31 AM, "Joel M. Halpern" wrote: >For me, "ownership" of data is not a helpful way to think about this. >(It is not incorrect, just unhelpful.) > >Rather, the base concept is that two different clients should not be=20 >writing the same data in the same time period. (i.e. from when the=20 >first one writes it until he removes his modification.) This is necessary, but not sufficient. If we allow multiple clients (actual= ly, identities, since the same identity can cover multiple clients) to chan= ge state programmatically, we must allow for mechanisms for programmatic st= ate validation and troubleshooting. For example, when there is a failover between a redundant pair of clients, = the newly active client instance must perform state synchronization, which = includes reading all the state that the previously active instance of the c= lient injected into the system. Therefore, the agent needs to know which cl= ient injected which state into system (if the agent does not do that, we ne= ed an external entity, such as the controller, to keep track of this). [Alia] As Joel said, I don't think that the I2RS agent can or should be the= only means of communication or coordination between the redundant pair of = clients. However, given that keeping client ownership information is neede= d anyway, this would be one way to learn this information. Similarly for troubleshooting - when, for example, an operator wants to pur= ge state of a client that is/should not be active anymore, the system shoul= d facilitate this action. A state purge for a client could happen, for exam= ple, when an operator wants to shut down an application. [Alia] Absolutely - this is another good use-case for the ownership informa= tion. Alia > >When this fails, it is an error. >We need to detect this error. >So the I2RS Agent is required to keep track of enough information to=20 >detect and provide a predictable behavior in the event this occurs. >The priority mechanism is a mechanism for providing better=20 >predictability. If we don't like it, we can ditch it. Priority is useful - no reason to ditch it. But it is not sufficient :-) > >In particular, one corrollary of this is that "ownership" does not, it=20 >seems to me, belong in the data model. It is, as Alia and other said,=20 >metadata. Yes, it is metadata. But it would be premature to exclude the option to pro= vide metadata along with the data - there are plenty of systems out there t= hat implement this concept and work quite well. > >Yours, >Joel Thanks, Jan > >On 8/22/13 6:36 PM, Andy Bierman wrote: >> On Thu, Aug 22, 2013 at 2:08 PM, Jan Medved (jmedved)=20 >> wrote: >>> Hi Alia, >>> >>> On 8/22/13 11:13 AM, "Alia Atlas" wrote: >>> >>>> Hi Juergen, >>>> >>>> I agree that the ownership of data seems more like meta-data to me=20 >>>>than anything else. I really would prefer not to clutter the=20 >>>>data-models with it. >>> >>> It depends. If ownership is coarse grained, then having the=20 >>>ownership metadata in a separate tree is manageable. If it's=20 >>>fine-grained, having the ownership metadata embedded in the data=20 >>>tree is easier - both for the server as well as for the clients. >>> >>> I think with I2RS, ownership will likely be fine-grained. >>> >> >> I think this "owner" concept needs a lot more work. >> If owner 1 has a higher priority than owner 2, then owner 1 can=20 >> clobber anything that owner 2 already created. That doesn't sound=20 >> fine-grained to me. >> >> The "first one wins" concept only applies to clients with the same=20 >>priority. >> The "last one wins" problem is addressed by assigning priorities to=20 >>the clients. >> Now it is "highest priority wins" which is what is desired. >> >> If the client writing existing data has the same or lower priority as=20 >>the owner that set the data, then the access is denied. (Problem=20 >>solved, first one wins). >> NACM would need some changes to support owner priority. >> The augments that has been proposed is insufficient: >>=20 >>http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00#section-3 >>.6 >> >> (IMO, only sec. 3.6 of this draft is needed.) >> >> >>>> >>>> I think there are two (at least!) separate aspects that we need to=20 >>>>figure out. One is the permissions aspect - where we need to be=20 >>>>able to clearly express what scope a particular role has. >>> >>> Agreed. >>> >>>> The second is what an i2rs agent needs to store, manipulate, and=20 >>>>report back. >>>> >>>> For the latter, the basic concept is described in >>>> draft-ietf-i2rs-architecture-00 split across Sec 5.2, 6.8, and 6.4=20 >>>>(which discusses identity). In Sec 5.2, it says: >>>> >>>> "The I2RS agent stores the set of >>>> operations it has applied. Simply, the I2RS agent stores who did >>>> what operation to which entity. New changes replace any data about >>>> old ones. If an I2RS client does an operation to remove some=20 >>>>state, >>>> that state is removed and the I2RS agent stores no more information >>>> about it. This allows any interested party to determine what the >>>> current effect of I2RS on the system is, and why. Meaningful=20 >>>>logging >>>> is also recommended." >> >> >> If a client is really a broker, then is the owner string going to be=20 >>for the upstream application or the broker? Which clients are likely=20 >>to have the same priority and collide on the same data? >> >> >>>> >>>> Alia >>> >>> /Jan >> >> Andy >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> From lhotka@nic.cz Mon Aug 26 08:49:03 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FEF21F9BB1 for ; Mon, 26 Aug 2013 08:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_13=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 2Ka83JcjxFrT for ; Mon, 26 Aug 2013 08:49:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 06A0621F9A4C for ; Mon, 26 Aug 2013 08:49:02 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 0948A13FDD6; Mon, 26 Aug 2013 17:49:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1377532141; bh=EmS82USeeAlRsYyn2TDaIzjFaDymiFgfnicc23FpJqY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=RHIyEk8YbTtFRBh0VK7WJJiGuYjYEQmiABNH7G2KiWtFO0VpwZVelJdDfX3acpkNL AmBibpIT1pVpoocV7KTW/j8lhd9E5AuVHz8jTsuZNVDXZor2d5zGOq5PJFVClZFGYr 0/Tk/U4fjTVCU6lD/vVODZifVP1A+cK5R498mbZ4= 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: Mon, 26 Aug 2013 17:49:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130813.220912.447857853.mbj@tail-f.com> <20130814.165235.319391216.mbj@tail-f.com> <56010AF8-450D-4645-AF32-C33F74865C24@nic.cz> <20130815064413.GA8087@elstar.local> <5F1B12E3-5A49-4DA4-8233-B271F978B75B@nic.cz> <20130819082320.GA62925@elstar.local> To: Alia Atlas X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: Alia Atlas , "i2rs-chairs@tools.ietf.org" , Nitin Bahadur , "netmod@ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 15:49:03 -0000 Hi Alia, On Aug 26, 2013, at 5:08 PM, Alia Atlas wrote: > On Mon, Aug 19, 2013 at 4:23 AM, Juergen Schoenwaelder = wrote: > On Thu, Aug 15, 2013 at 04:12:28PM +0000, Alia Atlas wrote: > > > > Of course. We need to identify places where our routing model cannot = be augmented to suit I2RS needs, due to either its current design or = limitations in YANG. I hope the *needs* can be formulated soon. > > > > [Alia] First, I certainly agree that NetMod shouldn't wait until = I2RS is finished. I do think that the routing model and the RIB = info-model are trying to support different things. It may make sense = that the routing model has higher abstractions, does different or = additional configuration, and so on. That said, I do think the RIB = info-model draft is fairly accurate in describing what is needed for the = RIB - and that can support a wide range of static routes. However, in = routing, usually there are higher level abstractions that are applied = for accuracy and ease; one can put an MPLS label on an outgoing packet - = but this is frequently modeled as going into an LSP or a tunnel or = connected to LDP's FECs or an L3VPN or so on. > > >=20 > Alia, I think basic concepts and terminology should be aligned between > a standard routing configuration interface and a standard routing > state manipulation interface. I surely expect that the I2RS info model > goes beyond what we have in NETMOD but for the core bits and pieces > (basic concepts and in particular also terminology), I think the > industry will benefit if things turn out to be reasonably consistent. > I hope by Vancouver we are in a situation where basic concepts and > terminology have already started to converge. This would be great. >=20 > Juergen, >=20 > I agree that basic concepts and terminology should be aligned. For = the RIB, many other routing concepts and abstractions are built on top = of it and it isn't usually exposed as such at the management interface. = For instance, the RIB info model has the next-hop chains which are ways = of imposing additional headers and specifying their details. At the = network management layer, those would be exposed as tunnels. For = different routing, they might be exposed as MPLS out-segments, or LSPs = or MPLS tunnels. Another example is the ability to specify = load-balancing amounts per next-hop. At the management interface and = for routing protocols, multiple next-hops can be specified, but an even = distribution of traffic across the next-hops is assumed. Different = hardware may have different ranges and precision for load-balancing. >=20 > So - I agree that converging common basic concepts and terminology is = very good. I'm just concerned that the multiple abstractions built on = top of the RIB are not as clear in part because the initial focus for = the YANG routing model is on static routes. The NETMOD WG deliberately didn't want to go into more complex routing = stuff, but still - the aim of the routing data model is to create a = framework into which routing components of any complexity can be = inserted via augmentation. The framework - multiple routing tables, = route filters etc. - by itself makes little sense for static routing = only. I think the fact that some concepts or abstractions are not exposed in = existing management interfaces doesn't necessarily mean it is worthless = to model them as a part of operational state data. Of course, it is quite possible that the design of the framework in = routing-cfg is not good enough to accomodate some of the advanced = routing concepts, such as the next-hop chains, but then this is exactly = what we would like to hear, preferably before the core routing data = model becomes an RFC. Lada > =20 >=20 > Alia > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jmedved@cisco.com Mon Aug 26 09:11:24 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A2F21E809D for ; Mon, 26 Aug 2013 09:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.398 X-Spam-Level: X-Spam-Status: No, score=-10.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 FYB6lRfVuf1f for ; Mon, 26 Aug 2013 09:11:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id CBD5121E809C for ; Mon, 26 Aug 2013 09:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21119; q=dns/txt; s=iport; t=1377533479; x=1378743079; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=w//rhyff6cKJMqjuLgb4xUgKc6F5VVXBT+/IWmdH/lk=; b=RVYc6mNXx8023spQrw/lId2wTWGzT/9HIhdI9YZv8xm5/Opm0zjzSk/K A4ReTTn41kV/rtLD1hGPLzdVvbKf98G004txg2xLlptXVOeMpZsoG03kH Ia7kL0M7YiIlxbjxKK/WnxFgnUm2a2OwVJf9qqDnIDeLrX0VwLqId5RO8 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAOl9G1KtJXHB/2dsb2JhbABSCYJDRDVRt1KIQ4EiFnSCJAEBAQQBAQFrCxIBAgYRAQIBAgEKHS4LFAMGCAIEAQ0FCId5DLdejzaBESANBAcGgxZ9A5kbkDSDHoFqJBw X-IronPort-AV: E=Sophos;i="4.89,959,1367971200"; d="scan'208,217";a="251706720" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 26 Aug 2013 16:11:18 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7QGBHxd007796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Aug 2013 16:11:17 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.56]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Mon, 26 Aug 2013 11:11:17 -0500 From: "Jan Medved (jmedved)" To: "Jmh.direct" , "jmh@joelhalpern.com" , "andy@yumaworks.com" Thread-Topic: [netmod] i2rs client ownership Thread-Index: AQHOoiv5Q+Adz5ekfUGn0kuI+JV/h5mnh+kA Importance: low X-Priority: 5 Date: Mon, 26 Aug 2013 16:11:16 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.155.64.190] Content-Type: multipart/alternative; boundary="_000_ACC8AB2D98C05F4E9FBDA092017D97FC152F08D0xmbalnx10ciscoc_" MIME-Version: 1.0 Cc: "nitinb@juniper.net" , "akatlas@juniper.net" , "i2rs-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 16:11:24 -0000 --_000_ACC8AB2D98C05F4E9FBDA092017D97FC152F08D0xmbalnx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: "Jmh.direct" > Date: Monday, August 26, 2013 12:15 AM To: Jan Medved >, "jmh@joelhalp= ern.com" >, "andy@yumaworks.com" > Cc: "netmod@ietf.org" >, "nitinb@juniper.net" >, "akatlas@juniper.net" >, "i2rs-chairs@= tools.ietf.org" > Subject: Re: [netmod] i2rs client ownership Mostly, I am comfortable with your description. Havong an information mode= l of the metadata seems uaeful. On the other hand for redundant clients cooperating for failover, etc. I th= ink it is worth keeping in mind that they will need their own back-end coor= dination. The I2RS agent ought not be the primary coordination channel. 100% agreed. But state sync after a failover is still needed. Consider a redundant clien= t with active and standby instances. The active can either update the stand= by instance first and then the agent, or vice versa. The updates to the age= nt and the standby can never be completely in sync. If a failure of the ac= tive instance happens between the updates to the agent and the standby inst= ance, the newly active instance and the agent will be out of sync. Therefor= e, a state sync is needed after a failover. Yours, Joel Thanks, Jan Sent from my Samsung smartphone on AT&T -------- Original message -------- Subject: Re: [netmod] i2rs client ownership From: "Jan Medved (jmedved)" > To: "Joel M. Halpern" >,And= y Bierman > CC: "netmod@ietf.org" >,Nitin Bahadur >,= Alia Atlas >,"i2rs-chairs@t= ools.ietf.org" > On 8/24/13 2:31 AM, "Joel M. Halpern" > wrote: >For me, "ownership" of data is not a helpful way to think about this. >(It is not incorrect, just unhelpful.) > >Rather, the base concept is that two different clients should not be >writing the same data in the same time period. (i.e. from when the >first one writes it until he removes his modification.) This is necessary, but not sufficient. If we allow multiple clients (actually, identities, since the same identity can cover multiple clients) to change state programmatically, we must allow for mechanisms for programmatic state validation and troubleshooting. For example, when there is a failover between a redundant pair of clients, the newly active client instance must perform state synchronization, which includes reading all the state that the previously active instance of the client injected into the system. Therefore, the agent needs to know which client injected which state into system (if the agent does not do that, we need an external entity, such as the controller, to keep track of this). Similarly for troubleshooting - when, for example, an operator wants to purge state of a client that is/should not be active anymore, the system should facilitate this action. A state purge for a client could happen, for example, when an operator wants to shut down an application. > >When this fails, it is an error. >We need to detect this error. >So the I2RS Agent is required to keep track of enough information to >detect and provide a predictable behavior in the event this occurs. >The priority mechanism is a mechanism for providing better >predictability. If we don't like it, we can ditch it. Priority is useful - no reason to ditch it. But it is not sufficient :-) > >In particular, one corrollary of this is that "ownership" does not, it >seems to me, belong in the data model. It is, as Alia and other said, >metadata. Yes, it is metadata. But it would be premature to exclude the option to provide metadata along with the data - there are plenty of systems out there that implement this concept and work quite well. > >Yours, >Joel Thanks, Jan > >On 8/22/13 6:36 PM, Andy Bierman wrote: >> On Thu, Aug 22, 2013 at 2:08 PM, Jan Medved (jmedved) >>> wrote: >>> Hi Alia, >>> >>> On 8/22/13 11:13 AM, "Alia Atlas" > wrote: >>> >>>> Hi Juergen, >>>> >>>> I agree that the ownership of data seems more like meta-data to me >>>>than >>>> anything else. I really would prefer not to clutter the data-models >>>>with >>>> it. >>> >>> It depends. If ownership is coarse grained, then having the ownership >>> metadata in a separate tree is manageable. If it's fine-grained, having >>> the ownership metadata embedded in the data tree is easier - both for >>>the >>> server as well as for the clients. >>> >>> I think with I2RS, ownership will likely be fine-grained. >>> >> >> I think this "owner" concept needs a lot more work. >> If owner 1 has a higher priority than owner 2, then owner 1 can clobber >> anything that owner 2 already created. That doesn't sound fine-grained >> to me. >> >> The "first one wins" concept only applies to clients with the same >>priority. >> The "last one wins" problem is addressed by assigning priorities to the >>clients. >> Now it is "highest priority wins" which is what is desired. >> >> If the client writing existing data has the same or lower priority as >>the owner >> that set the data, then the access is denied. (Problem solved, first >>one wins). >> NACM would need some changes to support owner priority. >> The augments that has been proposed is insufficient: >> http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00#section-3.6 >> >> (IMO, only sec. 3.6 of this draft is needed.) >> >> >>>> >>>> I think there are two (at least!) separate aspects that we need to >>>>figure >>>> out. One is the permissions aspect - where we need to be able to >>>>clearly >>>> express what scope a particular role has. >>> >>> Agreed. >>> >>>> The second is what an i2rs agent needs to store, manipulate, and >>>>report >>>> back. >>>> >>>> For the latter, the basic concept is described in >>>> draft-ietf-i2rs-architecture-00 split across Sec 5.2, 6.8, and 6.4 >>>>(which >>>> discusses identity). In Sec 5.2, it says: >>>> >>>> "The I2RS agent stores the set of >>>> operations it has applied. Simply, the I2RS agent stores who did >>>> what operation to which entity. New changes replace any data about >>>> old ones. If an I2RS client does an operation to remove some >>>>state, >>>> that state is removed and the I2RS agent stores no more information >>>> about it. This allows any interested party to determine what the >>>> current effect of I2RS on the system is, and why. Meaningful >>>>logging >>>> is also recommended." >> >> >> If a client is really a broker, then is the owner string going to be >>for the >> upstream application or the broker? Which clients are likely to >> have the same priority and collide on the same data? >> >> >>>> >>>> Alia >>> >>> /Jan >> >> Andy >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> --_000_ACC8AB2D98C05F4E9FBDA092017D97FC152F08D0xmbalnx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <608683BC7189884CAD68162E380CA30C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable


From: "Jmh.direct" <jmh.direct@joelhalpern.com&= gt;
Date: Monday, August 26, 2013 12:15= AM
To: Jan Medved <jmedved@cisco.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "andy@yumaworks.com" <andy@yumaworks.com>
Cc: "netmod@ietf.org" <= netmod@ietf.org>, "nitinb= @juniper.net" <nitinb@jun= iper.net>, "akatlas@juniper.net"= <akatlas@juniper.net>, &q= uot;i2rs-chairs@tools.ietf.or= g" <i2rs-chairs@t= ools.ietf.org>
Subject: Re: [netmod] i2rs client o= wnership

Mostly, I am comfortable with your description.  Havong an inform= ation model of the metadata seems uaeful.

On the other hand for redundant clients cooperating for failover, etc.= I think it is worth keeping in mind that they will need their own back-end= coordination.  The I2RS agent ought not be the primary coordination c= hannel.

100% agreed. 

But state sync after a failover is still needed. Consider a redundant = client with active and standby instances. The active can either update the = standby instance first and then the agent, or vice versa. The updates to th= e agent and the standby can never be completely  in sync. If a failure of the active instance happens b= etween the updates to the agent and the standby instance, the newly active = instance and the agent will be out of sync. Therefore, a state sync is need= ed after a failover.


Yours,
Joel

Thanks,
Jan


Sent from my Samsung smartphone on AT&am= p;T



-------- Original message --------
Subject: Re: [netmod] i2rs client ownership
From: "Jan Medved (jmedved)" <jmedved@cisco.com>
To: "Joel M. Halpern" <= jmh@joelhalpern.com>,Andy Bierman <andy@yumaworks.com>
CC: "netmod@ietf.org" <= netmod@ietf.org>,Nitin Bahadur &l= t;nitinb@juniper.net>,Alia Atl= as <akatlas@juniper.net>,&= quot;i2rs-chairs@tools.ietf.o= rg" <i2rs-chairs@tools.ietf.o= rg>




On 8/24/13 2:31 AM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:

>For me, "ownership" of data is not a helpful way to think abo= ut this.
>(It is not incorrect, just unhelpful.)
>
>Rather, the base concept is that two different clients should not be >writing the same data in the same time period.  (i.e. from when th= e
>first one writes it until he removes his modification.)

This is necessary, but not sufficient. If we allow multiple clients
(actually, identities, since the same identity can cover multiple clients)<= br> to change state programmatically, we must allow for mechanisms for
programmatic state validation and troubleshooting.

For example, when there is a failover between a redundant pair of clients,<= br> the newly active client instance must perform state synchronization, which<= br> includes reading all the state that the previously active instance of the client injected into the system. Therefore, the agent needs to know which client injected which state into system (if the agent does not do that, we<= br> need an external entity, such as the controller, to keep track of this).
Similarly for troubleshooting - when, for example, an operator wants to
purge state of a client that is/should not be active anymore, the system should facilitate this action. A state purge for a client could happen,
for example, when an operator wants to shut down an application.

>
>When this fails, it is an error.
>We need to detect this error.
>So the I2RS Agent is required to keep track of enough information to >detect and provide a predictable behavior in the event this occurs.
>The priority mechanism is a mechanism for providing better
>predictability.  If we don't like it, we can ditch it.

Priority is useful - no reason to ditch it. But it is not sufficient :-)
>
>In particular, one corrollary of this is that "ownership" doe= s not, it
>seems to me, belong in the data model.  It is, as Alia and other s= aid,
>metadata.

Yes, it is metadata. But it would be premature to exclude the option to
provide metadata along with the data - there are plenty of systems out
there that implement this concept and work quite well.

>
>Yours,
>Joel

Thanks,
Jan

>
>On 8/22/13 6:36 PM, Andy Bierman wrote:
>> On Thu, Aug 22, 2013 at 2:08 PM, Jan Medved (jmedved)
>><jmedved@cisco.com> = wrote:
>>> Hi Alia,
>>>
>>> On 8/22/13 11:13 AM, "Alia Atlas" <akatlas@juniper.net> wrote:
>>>
>>>> Hi Juergen,
>>>>
>>>> I agree that the ownership of data seems more like meta-da= ta to me
>>>>than
>>>> anything else.  I really would prefer not to clutter = the data-models
>>>>with
>>>> it.
>>>
>>> It depends. If ownership is coarse grained, then having the ow= nership
>>> metadata in a separate tree is manageable. If it's fine-graine= d, having
>>> the ownership metadata embedded in the data tree is easier - b= oth for
>>>the
>>> server as well as for the clients.
>>>
>>> I think with I2RS, ownership will likely be fine-grained.
>>>
>>
>> I think this "owner" concept needs a lot more work.
>> If owner 1 has a higher priority than owner 2, then owner 1 can cl= obber
>> anything that owner 2 already created.  That doesn't sound fi= ne-grained
>> to me.
>>
>> The "first one wins" concept only applies to clients wit= h the same
>>priority.
>> The "last one wins" problem is addressed by assigning pr= iorities to the
>>clients.
>> Now it is "highest priority wins" which is what is desir= ed.
>>
>> If the client writing existing data has the same or lower priority= as
>>the owner
>> that set the data, then the access is denied.  (Problem solve= d, first
>>one wins).
>> NACM would need some changes to support owner priority.
>> The augments that has been proposed is insufficient:
>> http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00#section-3.6
>>
>> (IMO, only sec. 3.6 of this draft is needed.)
>>
>>
>>>>
>>>> I think there are two (at least!) separate aspects that we= need to
>>>>figure
>>>> out.  One is the permissions aspect - where we need t= o be able to
>>>>clearly
>>>> express what scope a particular role has.
>>>
>>> Agreed.
>>>
>>>>   The second is what an i2rs agent needs to stor= e, manipulate, and
>>>>report
>>>> back.
>>>>
>>>> For the latter, the basic concept is described in
>>>> draft-ietf-i2rs-architecture-00 split across Sec 5.2, 6.8,= and 6.4
>>>>(which
>>>> discusses identity).  In Sec 5.2, it says:
>>>>
>>>>    "The I2RS agent stores the set of >>>>    operations it has applied.  Simply,= the I2RS agent stores who did
>>>>    what operation to which entity.  Ne= w changes replace any data about
>>>>    old ones.  If an I2RS client does a= n operation to remove some
>>>>state,
>>>>    that state is removed and the I2RS agent= stores no more information
>>>>    about it.  This allows any interest= ed party to determine what the
>>>>    current effect of I2RS on the system is,= and why.  Meaningful
>>>>logging
>>>>    is also recommended."
>>
>>
>> If a client is really a broker, then is the owner string going to = be
>>for the
>> upstream application or the broker?  Which clients are likely= to
>> have the same priority and collide on the same data?
>>
>>
>>>>
>>>> Alia
>>>
>>> /Jan
>>
>> Andy
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://w= ww.ietf.org/mailman/listinfo/netmod
>>

 --_000_ACC8AB2D98C05F4E9FBDA092017D97FC152F08D0xmbalnx10ciscoc_-- From jmh@joelhalpern.com Mon Aug 26 09:27:21 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EBA21E8094 for ; Mon, 26 Aug 2013 09:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 qspOBX-4xlpV for ; Mon, 26 Aug 2013 09:27:17 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 2591221E809C for ; Mon, 26 Aug 2013 09:27:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 04E6B1D25FE; Mon, 26 Aug 2013 09:27:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4D13C1C0066; Mon, 26 Aug 2013 09:27:08 -0700 (PDT) Message-ID: <521B81DD.2060006@joelhalpern.com> Date: Mon, 26 Aug 2013 12:27:09 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Jan Medved (jmedved)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "nitinb@juniper.net" , "i2rs-chairs@tools.ietf.org" , "akatlas@juniper.net" , "netmod@ietf.org" Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 16:27:21 -0000 As long as we are careful not to get carried away with it, and ability to perform queries based on / about ownership does seem a useful capability for I2RS. I observed in some other similar groups people tending to expect that to be sufficient to handle redundancy, without synch between the devices. I was trying to be clear that in my view that is a non-goal. Yours, Joel On 8/26/13 12:11 PM, Jan Medved (jmedved) wrote: > > > From: "Jmh.direct" > > Date: Monday, August 26, 2013 12:15 AM > To: Jan Medved >, > "jmh@joelhalpern.com " >, "andy@yumaworks.com > " > > Cc: "netmod@ietf.org " >, "nitinb@juniper.net > " >, "akatlas@juniper.net > " >, "i2rs-chairs@tools.ietf.org > " > > Subject: Re: [netmod] i2rs client ownership > > Mostly, I am comfortable with your description. Havong an > information model of the metadata seems uaeful. > > On the other hand for redundant clients cooperating for failover, > etc. I think it is worth keeping in mind that they will need their > own back-end coordination. The I2RS agent ought not be the primary > coordination channel. > > > 100% agreed. > > But state sync after a failover is still needed. Consider a redundant > client with active and standby instances. The active can either update > the standby instance first and then the agent, or vice versa. The > updates to the agent and the standby can never be completely in sync. > If a failure of the active instance happens between the updates to the > agent and the standby instance, the newly active instance and the agent > will be out of sync. Therefore, a state sync is needed after a failover. > > > Yours, > Joel > > > Thanks, > Jan > > > Sent from my Samsung smartphone on AT&T > > > > -------- Original message -------- > Subject: Re: [netmod] i2rs client ownership > From: "Jan Medved (jmedved)" > > To: "Joel M. Halpern" >,Andy Bierman > > CC: "netmod@ietf.org " >,Nitin Bahadur >,Alia Atlas >,"i2rs-chairs@tools.ietf.org > " > > > > > > On 8/24/13 2:31 AM, "Joel M. Halpern" > wrote: > > >For me, "ownership" of data is not a helpful way to think about this. > >(It is not incorrect, just unhelpful.) > > > >Rather, the base concept is that two different clients should not be > >writing the same data in the same time period. (i.e. from when the > >first one writes it until he removes his modification.) > > This is necessary, but not sufficient. If we allow multiple clients > (actually, identities, since the same identity can cover multiple > clients) > to change state programmatically, we must allow for mechanisms for > programmatic state validation and troubleshooting. > > For example, when there is a failover between a redundant pair of > clients, > the newly active client instance must perform state synchronization, > which > includes reading all the state that the previously active instance > of the > client injected into the system. Therefore, the agent needs to know > which > client injected which state into system (if the agent does not do > that, we > need an external entity, such as the controller, to keep track of this). > > Similarly for troubleshooting - when, for example, an operator wants to > purge state of a client that is/should not be active anymore, the system > should facilitate this action. A state purge for a client could happen, > for example, when an operator wants to shut down an application. > > > > >When this fails, it is an error. > >We need to detect this error. > >So the I2RS Agent is required to keep track of enough information to > >detect and provide a predictable behavior in the event this occurs. > >The priority mechanism is a mechanism for providing better > >predictability. If we don't like it, we can ditch it. > > Priority is useful - no reason to ditch it. But it is not sufficient :-) > > > > >In particular, one corrollary of this is that "ownership" does not, it > >seems to me, belong in the data model. It is, as Alia and other said, > >metadata. > > Yes, it is metadata. But it would be premature to exclude the option to > provide metadata along with the data - there are plenty of systems out > there that implement this concept and work quite well. > > > > >Yours, > >Joel > > Thanks, > Jan > > > > >On 8/22/13 6:36 PM, Andy Bierman wrote: > >> On Thu, Aug 22, 2013 at 2:08 PM, Jan Medved (jmedved) > >>> wrote: > >>> Hi Alia, > >>> > >>> On 8/22/13 11:13 AM, "Alia Atlas" > wrote: > >>> > >>>> Hi Juergen, > >>>> > >>>> I agree that the ownership of data seems more like meta-data to me > >>>>than > >>>> anything else. I really would prefer not to clutter the data-models > >>>>with > >>>> it. > >>> > >>> It depends. If ownership is coarse grained, then having the ownership > >>> metadata in a separate tree is manageable. If it's fine-grained, having > >>> the ownership metadata embedded in the data tree is easier - both for > >>>the > >>> server as well as for the clients. > >>> > >>> I think with I2RS, ownership will likely be fine-grained. > >>> > >> > >> I think this "owner" concept needs a lot more work. > >> If owner 1 has a higher priority than owner 2, then owner 1 can clobber > >> anything that owner 2 already created. That doesn't sound fine-grained > >> to me. > >> > >> The "first one wins" concept only applies to clients with the same > >>priority. > >> The "last one wins" problem is addressed by assigning priorities to the > >>clients. > >> Now it is "highest priority wins" which is what is desired. > >> > >> If the client writing existing data has the same or lower priority as > >>the owner > >> that set the data, then the access is denied. (Problem solved, first > >>one wins). > >> NACM would need some changes to support owner priority. > >> The augments that has been proposed is insufficient: > >>http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00#section-3.6 > >> > >> (IMO, only sec. 3.6 of this draft is needed.) > >> > >> > >>>> > >>>> I think there are two (at least!) separate aspects that we need to > >>>>figure > >>>> out. One is the permissions aspect - where we need to be able to > >>>>clearly > >>>> express what scope a particular role has. > >>> > >>> Agreed. > >>> > >>>> The second is what an i2rs agent needs to store, manipulate, and > >>>>report > >>>> back. > >>>> > >>>> For the latter, the basic concept is described in > >>>> draft-ietf-i2rs-architecture-00 split across Sec 5.2, 6.8, and 6.4 > >>>>(which > >>>> discusses identity). In Sec 5.2, it says: > >>>> > >>>> "The I2RS agent stores the set of > >>>> operations it has applied. Simply, the I2RS agent stores who did > >>>> what operation to which entity. New changes replace any data about > >>>> old ones. If an I2RS client does an operation to remove some > >>>>state, > >>>> that state is removed and the I2RS agent stores no more information > >>>> about it. This allows any interested party to determine what the > >>>> current effect of I2RS on the system is, and why. Meaningful > >>>>logging > >>>> is also recommended." > >> > >> > >> If a client is really a broker, then is the owner string going to be > >>for the > >> upstream application or the broker? Which clients are likely to > >> have the same priority and collide on the same data? > >> > >> > >>>> > >>>> Alia > >>> > >>> /Jan > >> > >> Andy > >> _______________________________________________ > >> netmod mailing list > >>netmod@ietf.org > >>https://www.ietf.org/mailman/listinfo/netmod > >> > From akatlas@juniper.net Mon Aug 26 10:05:07 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1415E11E81C9 for ; Mon, 26 Aug 2013 10:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 FQ7BTCGrhf9Y for ; Mon, 26 Aug 2013 10:05:02 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id 7E72E11E81C8 for ; Mon, 26 Aug 2013 10:05:01 -0700 (PDT) Received: from mail218-db8-R.bigfish.com (10.174.8.234) by DB8EHSOBE042.bigfish.com (10.174.4.105) with Microsoft SMTP Server id 14.1.225.22; Mon, 26 Aug 2013 17:05:00 +0000 Received: from mail218-db8 (localhost [127.0.0.1]) by mail218-db8-R.bigfish.com (Postfix) with ESMTP id 4BB5A801AC; Mon, 26 Aug 2013 17:05:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah186068h8275bh8275dh1de097hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h) Received-SPF: pass (mail218-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=akatlas@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(13464003)(51704005)(479174003)(377454003)(189002)(199002)(63696002)(80022001)(56816003)(77096001)(81816001)(53806001)(59766001)(77982001)(66066001)(65816001)(15202345003)(76796001)(33646001)(74876001)(74706001)(81686001)(76482001)(74366001)(83072001)(79102001)(54316002)(74316001)(76576001)(54356001)(76786001)(56776001)(19580395003)(83322001)(80976001)(19580405001)(46102001)(49866001)(81342001)(47736001)(74662001)(69226001)(51856001)(74502001)(81542001)(4396001)(50986001)(31966008)(47976001)(47446002)(15975445006)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB050; H:BL2PR05MB193.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail218-db8 (localhost.localdomain [127.0.0.1]) by mail218-db8 (MessageSwitch) id 1377536698952687_26938; Mon, 26 Aug 2013 17:04:58 +0000 (UTC) Received: from DB8EHSMHS010.bigfish.com (unknown [10.174.8.246]) by mail218-db8.bigfish.com (Postfix) with ESMTP id DA777E004F; Mon, 26 Aug 2013 17:04:58 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS010.bigfish.com (10.174.4.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 26 Aug 2013 17:04:58 +0000 Received: from BL2PR05MB050.namprd05.prod.outlook.com (10.255.228.146) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.347.3; Mon, 26 Aug 2013 17:04:57 +0000 Received: from BL2PR05MB193.namprd05.prod.outlook.com (10.242.198.143) by BL2PR05MB050.namprd05.prod.outlook.com (10.255.228.146) with Microsoft SMTP Server (TLS) id 15.0.745.25; Mon, 26 Aug 2013 17:04:56 +0000 Received: from BL2PR05MB193.namprd05.prod.outlook.com ([169.254.9.249]) by BL2PR05MB193.namprd05.prod.outlook.com ([169.254.9.249]) with mapi id 15.00.0745.000; Mon, 26 Aug 2013 17:04:56 +0000 From: Alia Atlas To: Andy Bierman , "Jan Medved (jmedved)" Thread-Topic: [netmod] i2rs client ownership Thread-Index: AQHOnoZEcTLC2m5QM0Cu3jp6MtVMc5mhdGWAgAALIACAAAhcgIAAMqEAgAAYdoCABeoLUA== Date: Mon, 26 Aug 2013 17:04:55 +0000 Message-ID: References: <919fea51f182429b910962784a9e75fd@BL2PR05MB193.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] x-forefront-prvs: 0950706AC1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Nitin Bahadur , "i2rs-chairs@tools.ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 17:05:07 -0000 In-line as [Alia] -----Original Message----- From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Thursday, August 22, 2013 6:36 PM To: Jan Medved (jmedved) Cc: Alia Atlas; Juergen Schoenwaelder; Muthumayan Madhayyan (muthu); Nitin = Bahadur; i2rs-chairs@tools.ietf.org; netmod@ietf.org Subject: Re: [netmod] i2rs client ownership On Thu, Aug 22, 2013 at 2:08 PM, Jan Medved (jmedved) w= rote: > Hi Alia, > > On 8/22/13 11:13 AM, "Alia Atlas" wrote: > >>Hi Juergen, >> >>I agree that the ownership of data seems more like meta-data to me=20 >>than anything else. I really would prefer not to clutter the=20 >>data-models with it. > > It depends. If ownership is coarse grained, then having the ownership=20 > metadata in a separate tree is manageable. If it's fine-grained,=20 > having the ownership metadata embedded in the data tree is easier -=20 > both for the server as well as for the clients. > > I think with I2RS, ownership will likely be fine-grained. > I think this "owner" concept needs a lot more work. If owner 1 has a higher priority than owner 2, then owner 1 can clobber any= thing that owner 2 already created. That doesn't sound fine-grained to me. The "first one wins" concept only applies to clients with the same priority= . The "last one wins" problem is addressed by assigning priorities to the cli= ents. Now it is "highest priority wins" which is what is desired. If the client writing existing data has the same or lower priority as the o= wner that set the data, then the access is denied. (Problem solved, first = one wins). NACM would need some changes to support owner priority. The augments that has been proposed is insufficient: http://tools.ietf.org/html/draft-rfernando-i2rs-yang-mods-00#section-3.6 (IMO, only sec. 3.6 of this draft is needed.) >> >>I think there are two (at least!) separate aspects that we need to=20 >>figure out. One is the permissions aspect - where we need to be able=20 >>to clearly express what scope a particular role has. > > Agreed. > >> The second is what an i2rs agent needs to store, manipulate, and=20 >>report back. >> >>For the latter, the basic concept is described in >>draft-ietf-i2rs-architecture-00 split across Sec 5.2, 6.8, and 6.4=20 >>(which discusses identity). In Sec 5.2, it says: >> >> "The I2RS agent stores the set of >> operations it has applied. Simply, the I2RS agent stores who did >> what operation to which entity. New changes replace any data about >> old ones. If an I2RS client does an operation to remove some state, >> that state is removed and the I2RS agent stores no more information >> about it. This allows any interested party to determine what the >> current effect of I2RS on the system is, and why. Meaningful logging >> is also recommended." If a client is really a broker, then is the owner string going to be for th= e upstream application or the broker? Which clients are likely to have the= same priority and collide on the same data? [Alia] I don't think it is an ownership string that would be stored. There= are several aspects that are important to store - client identity, seconda= ry identity (for the broker case), transport session info (for troubleshoot= ing), client role, client priority. Again, implementation aspects can vary= on how this is stored and indirectly referenced. [Alia] As for which clients are likely to have the same priority, I don't s= ee a reason to limit the size of the priority field so drastically that thi= s is likely. Policy in terms of write-scope could be specified so that cli= ents with the same priority don't have access to write the same information= . Other external-to-I2RS mechanisms should be used to avoid collisions. Alia >> >>Alia > > /Jan Andy From jmedved@cisco.com Mon Aug 26 10:41:06 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C71521E80A9 for ; Mon, 26 Aug 2013 10:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 K+calRcu0n7B for ; Mon, 26 Aug 2013 10:41:00 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D313821E80A7 for ; Mon, 26 Aug 2013 10:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=505; q=dns/txt; s=iport; t=1377538861; x=1378748461; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=HgXD5njz09DHcCSBTaF0wVGl1+LK//On9Z8ScHwK+CA=; b=jpe/UP+tjylsYXLiLz58kALWlU+xz5d/3O70edwpmC2ttfMBt/KU9jTe rXyxvaPbcCyLh5OvWwzPnYKRNGtNcLQ8LFjtwTxUiCLd/j81Dd3aMeL24 yyp0Xiiq2YGbNphPCz1XNMJ7hl0uIBwAGRTjGVYtXBCzvLBVdqSxnrcS+ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAIuSG1KtJXG//2dsb2JhbABagweBBoJgvT2BIhZ0giYBBDotEhIBCCIUQiUCBA4FCId5t1GQRzEHgxx9A6lPgx6CKg X-IronPort-AV: E=Sophos;i="4.89,960,1367971200"; d="scan'208";a="251586110" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 26 Aug 2013 17:41:00 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7QHf05c010252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Aug 2013 17:41:00 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.56]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 26 Aug 2013 12:40:59 -0500 From: "Jan Medved (jmedved)" To: "Joel M. Halpern" Thread-Topic: [netmod] i2rs client ownership Thread-Index: AQHOoiv5Q+Adz5ekfUGn0kuI+JV/h5mnh+kAgAB5yYD//59HAA== Date: Mon, 26 Aug 2013 17:40:59 +0000 Message-ID: In-Reply-To: <521B81DD.2060006@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.155.64.190] Content-Type: text/plain; charset="us-ascii" Content-ID: <37BD955A12F11540A4B408D37FADA8AA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nitinb@juniper.net" , "i2rs-chairs@tools.ietf.org" , "akatlas@juniper.net" , "netmod@ietf.org" Subject: Re: [netmod] i2rs client ownership X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 17:41:06 -0000 On 8/26/13 9:27 AM, "Joel M. Halpern" wrote: >As long as we are careful not to get carried away with it, and ability >to perform queries based on / about ownership does seem a useful >capability for I2RS. I observed in some other similar groups people >tending to expect that to be sufficient to handle redundancy, without >synch between the devices. I was trying to be clear that in my view >that is a non-goal. Agreed 100%. > >Yours, >Joel /Jan > > From j.schoenwaelder@jacobs-university.de Tue Aug 27 06:27:29 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F7711E8312 for ; Tue, 27 Aug 2013 06:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.233 X-Spam-Level: X-Spam-Status: No, score=-103.233 tagged_above=-999 required=5 tests=[AWL=0.016, 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 AUj0Dyw9af-k for ; Tue, 27 Aug 2013 06:27:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2315611E828D for ; Tue, 27 Aug 2013 06:27:24 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1289C20CBA; Tue, 27 Aug 2013 15:27:23 +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 lKWHeF51Oydy; Tue, 27 Aug 2013 15:27:22 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 073B820CB5; Tue, 27 Aug 2013 15:27:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9335128059AE; Tue, 27 Aug 2013 15:27:15 +0200 (CEST) Date: Tue, 27 Aug 2013 15:27:14 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130827132714.GA29951@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20130825.225734.296927526.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130825.225734.296927526.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 13:27:30 -0000 On Sun, Aug 25, 2013 at 10:57:34PM +0200, Martin Bjorklund wrote: > Hi, > > internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the NETCONF Data Modeling Language Working Group > > of the IETF. > > > > Title : A YANG Data Model for IP Management > > Author(s) : Martin Bjorklund > > Filename : draft-ietf-netmod-ip-cfg-10.txt > > Pages : 33 > > Date : 2013-08-25 > > This draft adds IP state data to /interfaces-state/interface (assigned > addresses) and to /ip-state (neighbors). Thanks for the update! > In the /if:interfaces/if:interface/ipv6/address/status leaf, I blindly > copied the corresponding enumeration from IP-MIB, IpAddressStatusTC. > But I do not know if this is correct, or if we should use only the > three states defined in RFC 4862 - preferred, deprecated and > tentative. (and other or unknown makes sense). For example, the > value 'invalid' is used in the MIB, but 4862 says that an invalid > address is "an address that is not assigned to any interface [...]". > So how can it be reported? Also, 'duplicate' is a value in the MIB, > but 4862 says: "A tentative address that is determined to be a > duplicate as described above MUST NOT be assigned to an interface" so > it unclear again how it can be reported. Since this is in the config false state tree, I think we are fine even if certain enums never show up in certain implementations. While reading through the new revision, I found the following little nits (in general the document seems to be in good shape): a) There are some outdated references, see id-nits. b) In the example in Appendix A, please s/DB8/db8/ since the canonical representation of IPv6 addresses uses lowercase characters. c) The introduction is extremely terse. Perhaps add a few more sentences summarizing that the document covers the configuration of IPv4 and IPv6 interfaces as well as mappings to link-layer addresses and that it provides information which addresses are operationally used and which link-layer mappings do exist. d) The data model uses a number of presence containers. I am wondering whether all of them make sense as presence containers. /if:interfaces/if:interface/ipv4 /if:interfaces/if:interface/ipv6 These two really do not carry any semantics or at least the textual description "Configure IPvX on this interface" leaves it unclear what one has to implement. Why are these presence containers? /if:interfaces-state/if:interface/ipv4 /if:interfaces-state/if:interface/ipv6 /ip-state/ipv4 /ip-state/ipv6 These leafs indicate that IPvX is enabled and hence they do actually carry semantics - if they do not show up, then /if:interfaces/if:interface/ipvX/enabled is most likely false. [Perhaps a future revision of the tree diagram should have a way to indicate presence containers so that they are easier to spot.] /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Aug 27 13:29:18 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF8311E81D0 for ; Tue, 27 Aug 2013 13:29: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 5XllToTuT+Ox for ; Tue, 27 Aug 2013 13:29: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 C3FD321F8E7C for ; Tue, 27 Aug 2013 13:29:12 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 8D7121200054; Tue, 27 Aug 2013 22:29:10 +0200 (CEST) Date: Tue, 27 Aug 2013 22:29:10 +0200 (CEST) Message-Id: <20130827.222910.519872461.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130827132714.GA29951@elstar.local> References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20130825.225734.296927526.mbj@tail-f.com> <20130827132714.GA29951@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: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 20:29:18 -0000 Hi, Juergen Schoenwaelder wrote: > While reading through the new revision, I found the following little > nits (in general the document seems to be in good shape): > > a) There are some outdated references, see id-nits. Ok. > b) In the example in Appendix A, please s/DB8/db8/ since the canonical > representation of IPv6 addresses uses lowercase characters. Ok. > c) The introduction is extremely terse. Perhaps add a few more > sentences summarizing that the document covers the configuration of > IPv4 and IPv6 interfaces as well as mappings to link-layer > addresses and that it provides information which addresses are > operationally used and which link-layer mappings do exist. Ok; your words rephrased a bit: The data model covers configuration of per-interface IPv4 and IPv6 parameters, and mappings of IP addresses to link-layer addresses. It also provides information about which IP addresses are operationally used, and which link-layer mappings exist. > d) The data model uses a number of presence containers. I am wondering > whether all of them make sense as presence containers. > > /if:interfaces/if:interface/ipv4 > /if:interfaces/if:interface/ipv6 > > These two really do not carry any semantics or at least the textual > description "Configure IPvX on this interface" leaves it unclear > what one has to implement. Why are these presence containers? Since we have an 'enabled' leaf with a default value of 'true' under these containers, it means that once the container is created, by default IP is enabled. If we made them np-containers, we'd have to change the default of 'enabled' to 'false'. (unless we want to by default enable ipv4 and ipv6 on all (capable) interfaces, but I don't think we want that). > /if:interfaces-state/if:interface/ipv4 > /if:interfaces-state/if:interface/ipv6 > /ip-state/ipv4 > /ip-state/ipv6 > > These leafs indicate that IPvX is enabled and hence they do > actually carry semantics - if they do not show up, then > /if:interfaces/if:interface/ipvX/enabled is most likely false. Yes. > [Perhaps a future revision of the tree diagram should have a way to > indicate presence containers so that they are easier to spot.] Actually they are. Compare: +--ro ip-state +--ro ipv4? ip-state is an np-container and ipv4 is a p-container. Maybe the description of the symbol '?' could be made more explicit. /martin From j.schoenwaelder@jacobs-university.de Tue Aug 27 14:06:23 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CD421F9967 for ; Tue, 27 Aug 2013 14:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.234 X-Spam-Level: X-Spam-Status: No, score=-103.234 tagged_above=-999 required=5 tests=[AWL=0.015, 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 u1MsdWTO80rw for ; Tue, 27 Aug 2013 14:06:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFE621F9950 for ; Tue, 27 Aug 2013 14:06:16 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1ED6020CA3; Tue, 27 Aug 2013 23:06:16 +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 klPJfkpmvb1s; Tue, 27 Aug 2013 23:06: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 AC68F20C6D; Tue, 27 Aug 2013 23:06:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D9B0428065E6; Tue, 27 Aug 2013 23:06:09 +0200 (CEST) Date: Tue, 27 Aug 2013 23:06:09 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130827210609.GA30939@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20130825.225734.296927526.mbj@tail-f.com> <20130827132714.GA29951@elstar.local> <20130827.222910.519872461.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130827.222910.519872461.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 21:06:23 -0000 On Tue, Aug 27, 2013 at 10:29:10PM +0200, Martin Bjorklund wrote: > > d) The data model uses a number of presence containers. I am wondering > > whether all of them make sense as presence containers. > > > > /if:interfaces/if:interface/ipv4 > > /if:interfaces/if:interface/ipv6 > > > > These two really do not carry any semantics or at least the textual > > description "Configure IPvX on this interface" leaves it unclear > > what one has to implement. Why are these presence containers? > > Since we have an 'enabled' leaf with a default value of 'true' under > these containers, it means that once the container is created, by > default IP is enabled. If we made them np-containers, we'd have to > change the default of 'enabled' to 'false'. (unless we want to by > default enable ipv4 and ipv6 on all (capable) interfaces, but I don't > think we want that). OK, I see. This needs better explanation I think. The phrase "Configure IPvX on this interface" is not sufficient - I missed the subtle point of the enabled default value. Perhaps something like this (feel free to find a better wording): "Presence of the ipvX enables IPvX unless the enabled leaf (which defaults to 'true') is set to 'false'" > > /if:interfaces-state/if:interface/ipv4 > > /if:interfaces-state/if:interface/ipv6 > > /ip-state/ipv4 > > /ip-state/ipv6 > > > > These leafs indicate that IPvX is enabled and hence they do > > actually carry semantics - if they do not show up, then > > /if:interfaces/if:interface/ipvX/enabled is most likely false. > > Yes. > > > [Perhaps a future revision of the tree diagram should have a way to > > indicate presence containers so that they are easier to spot.] > > Actually they are. Compare: > > +--ro ip-state > +--ro ipv4? > > ip-state is an np-container and ipv4 is a p-container. > > Maybe the description of the symbol '?' could be made more explicit. The text says: o Symbols after data node names: "?" means an optional node I would prefer to not overload "?" with the presence/non-presence distinction. I would rather prefer to have something more like a warning sign: +--ro ip-state +--ro ipv4! o An exclamation mark "!" after a container indicates that the container is a presence container. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From muthu@cisco.com Tue Aug 27 17:37:32 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB3211E8241 for ; Tue, 27 Aug 2013 17:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 OSNNzlqhtoUL for ; Tue, 27 Aug 2013 17:37:26 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id BA88911E8103 for ; Tue, 27 Aug 2013 17:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2217; q=dns/txt; s=iport; t=1377650243; x=1378859843; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=fvJFjj0qXzsIu2lO1PgpndgC+3+ANw0RNr1uq3AQxfM=; b=gtgTG8hqWKEwVLFzaLqF+S8ZY52YBXYr0AIges4HjRjjB8BtsFSdAXL0 92fow2pCNFdtHyIh8oFozbNDOSV7auy4hEYJFKlQc+T8mFE9yBpP/pnLG qV9ih0K9Odj4D8zWd0/b3PZxezrTpQeCcHIcO4tfVPmveqoq+yYH5Yalu A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAAtFHVKtJXG+/2dsb2JhbABZgweBBsApgSMWdIIkAQEBBDo/EgEIEAgKFEIlAgQOBQiHebkNjjGBAjEHgxx9A6lPgyCBaQEeBhw X-IronPort-AV: E=Sophos;i="4.89,971,1367971200"; d="scan'208";a="252408935" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 28 Aug 2013 00:37:23 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7S0bNEJ015886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Aug 2013 00:37:23 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.77]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Tue, 27 Aug 2013 19:37:22 -0500 From: "Muthumayan Madhayyan (muthu)" To: Andy Bierman Thread-Topic: [netmod] comments on draft-ietf-netmod-routing-cfg-10 Thread-Index: AQHOmGEBI8PXbbfFTkmYweHRl90ooJmUqm6AgABxvICAAAK4gIAADosAgAD7V4CAAFAGAIAATr4AgAFHWYCABZAwgIAAhBEAgAB7MACAANiCgIADxYcAgAOu24CAAQfXAIAByCiA Date: Wed, 28 Aug 2013 00:37:22 +0000 Message-ID: <5A949C32AF740C4798AEECF2568F0D8411E6037E@xmb-rcd-x13.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.154.205.19] Content-Type: text/plain; charset="us-ascii" Content-ID: <9276B61B4EA21F48AF9491EEB6CDDC72@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" , Nitin Bahadur , Alia Atlas , "i2rs-chairs@tools.ietf.org" Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 00:37:32 -0000 On 8/26/13 7:24 AM, "Andy Bierman" wrote: >On Sun, Aug 25, 2013 at 10:40 PM, Muthumayan Madhayyan (muthu) > wrote: >> >> >> On 8/23/13 7:25 AM, "Andy Bierman" wrote: >> >>>On Tue, Aug 20, 2013 at 9:49 PM, Juergen Schoenwaelder >>> wrote: >>>> On Tue, Aug 20, 2013 at 10:55:06PM +0000, Muthumayan Madhayyan (muthu) >>>>wrote: >>>>> Hello Lada, >>>>> >>>>> Apart from the ability to write ephemeral data, I2RS also has a >>>>> requirement to associate client ownership to data injected by an >>>>>external >>>>> client. In NETCONF, the stores are global. >>>>> >>>> >>>> Well, this sounds like a NETCONF requirement, not a YANG requirement. >>> >>>+1 >>> >>>The owner is a property of the datastore, not the data model. >>>Ditto for the "ephemeral" YANG extension. I don't see the need >>>for any YANG extensions, just protocol extensions. >> >> There is no central 'datastore' for those schema nodes marked ephemeral. >> The i2rs client directly talks to an i2rs server that does not provide >>any >> form of storage, but relays all requests to relevant backend >>applications >> with adequate metadata like client identification and relative priority >> etc to the backend. All data injected by i2rs clients are maintained by >> the backend i2rs applications. In that sense this deviates a lot from >> traditional NETCONF datastore. Hope that explains why an 'ephemeral' >> extension is needed. >> > >The datastore is conceptual -- it is just an abstraction for the API. >None of the NETCONF datastores are required to be implemented >as a centralized tree. All NETCONF 'running' datastore contents >have "back-end" components that translate the API data into >device behavior -- it is exactly the same for I2RS (except the >dynamic datastore has different ownership and validation requirements). Correct. It would be great if data model can express which subset of nodes at which ownership is client specific (and not global unlike config store). Same goes for the 'exclusivity' requirements. > > >>> >>> >>> >>>> >>>> /js >>> >>>Andy >> > >Andy From lhotka@nic.cz Tue Aug 27 23:38:22 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A19F11E8141 for ; Tue, 27 Aug 2013 23:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=-1.301, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6, MANGLED_LOAN=2.3] 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 WpiHn5865goz for ; Tue, 27 Aug 2013 23:38:18 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id D332611E8104 for ; Tue, 27 Aug 2013 23:38:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 4CBF95402D9 for ; Wed, 28 Aug 2013 08:38:10 +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 zA+6fvDYuXt0 for ; Wed, 28 Aug 2013 08:38:04 +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 66820540294 for ; Wed, 28 Aug 2013 08:37:59 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20130827210609.GA30939@elstar.local> References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20130825.225734.296927526.mbj@tail-f.com> <20130827132714.GA29951@elstar.local> <20130827.222910.519872461.mbj@tail-f.com> <20130827210609.GA30939@elstar.local> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 28 Aug 2013 08:37:58 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 06:38:22 -0000 Juergen Schoenwaelder writes: > On Tue, Aug 27, 2013 at 10:29:10PM +0200, Martin Bjorklund wrote: > >> > d) The data model uses a number of presence containers. I am wondering >> > whether all of them make sense as presence containers. >> > >> > /if:interfaces/if:interface/ipv4 >> > /if:interfaces/if:interface/ipv6 >> > >> > These two really do not carry any semantics or at least the textual >> > description "Configure IPvX on this interface" leaves it unclear >> > what one has to implement. Why are these presence containers? >> >> Since we have an 'enabled' leaf with a default value of 'true' under >> these containers, it means that once the container is created, by >> default IP is enabled. If we made them np-containers, we'd have to >> change the default of 'enabled' to 'false'. (unless we want to by >> default enable ipv4 and ipv6 on all (capable) interfaces, but I don't >> think we want that). > > OK, I see. This needs better explanation I think. The phrase > "Configure IPvX on this interface" is not sufficient - I missed the > subtle point of the enabled default value. Perhaps something like > this (feel free to find a better wording): > > "Presence of the ipvX enables IPvX unless the enabled leaf > (which defaults to 'true') is set to 'false'" It might also be useful to explain that the purpose of the "enabled" leaf in fact is to allow for disabling IPvX while keeping the configuration, i.e. to override the presence function of the "ipvX" container. This could go to the description of "enabled". > >> > /if:interfaces-state/if:interface/ipv4 >> > /if:interfaces-state/if:interface/ipv6 >> > /ip-state/ipv4 >> > /ip-state/ipv6 >> > >> > These leafs indicate that IPvX is enabled and hence they do >> > actually carry semantics - if they do not show up, then >> > /if:interfaces/if:interface/ipvX/enabled is most likely false. >> >> Yes. >> >> > [Perhaps a future revision of the tree diagram should have a way to >> > indicate presence containers so that they are easier to spot.] >> >> Actually they are. Compare: >> >> +--ro ip-state >> +--ro ipv4? >> >> ip-state is an np-container and ipv4 is a p-container. >> >> Maybe the description of the symbol '?' could be made more explicit. > > The text says: > > o Symbols after data node names: "?" means an optional node > > I would prefer to not overload "?" with the presence/non-presence > distinction. I would rather prefer to have something more like a > warning sign: > > +--ro ip-state > +--ro ipv4! > > o An exclamation mark "!" after a container indicates that the > container is a presence container. +1 Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Aug 28 02:46:34 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FDF21F9A4C for ; Wed, 28 Aug 2013 02:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.236 X-Spam-Level: X-Spam-Status: No, score=-103.236 tagged_above=-999 required=5 tests=[AWL=0.013, 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 T0jmjvZGV2dU for ; Wed, 28 Aug 2013 02:46:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 199F511E80F5 for ; Wed, 28 Aug 2013 02:46:25 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 808D120C7B; Wed, 28 Aug 2013 11:46:24 +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 OD-8dO6R9myi; Wed, 28 Aug 2013 11:46:24 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 123C720C76; Wed, 28 Aug 2013 11:46:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5B10D28076C7; Wed, 28 Aug 2013 11:46:18 +0200 (CEST) Date: Wed, 28 Aug 2013 11:46:18 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund , netmod@ietf.org Message-ID: <20130828094618.GA32565@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20130825.225734.296927526.mbj@tail-f.com> <20130827132714.GA29951@elstar.local> <20130827.222910.519872461.mbj@tail-f.com> <20130827210609.GA30939@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130827210609.GA30939@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 09:46:34 -0000 On Tue, Aug 27, 2013 at 11:06:09PM +0200, Juergen Schoenwaelder wrote: > On Tue, Aug 27, 2013 at 10:29:10PM +0200, Martin Bjorklund wrote: > > > > d) The data model uses a number of presence containers. I am wondering > > > whether all of them make sense as presence containers. > > > > > > /if:interfaces/if:interface/ipv4 > > > /if:interfaces/if:interface/ipv6 > > > > > > These two really do not carry any semantics or at least the textual > > > description "Configure IPvX on this interface" leaves it unclear > > > what one has to implement. Why are these presence containers? > > > > Since we have an 'enabled' leaf with a default value of 'true' under > > these containers, it means that once the container is created, by > > default IP is enabled. If we made them np-containers, we'd have to > > change the default of 'enabled' to 'false'. (unless we want to by > > default enable ipv4 and ipv6 on all (capable) interfaces, but I don't > > think we want that). > > OK, I see. This needs better explanation I think. The phrase > "Configure IPvX on this interface" is not sufficient - I missed the > subtle point of the enabled default value. Perhaps something like > this (feel free to find a better wording): > > "Presence of the ipvX enables IPvX unless the enabled leaf > (which defaults to 'true') is set to 'false'" One more question. Should this same pattern be applied to +--rw system | +--rw ntp | +--rw enabled? boolean in draft-ietf-netmod-system-mgmt-08.txt? The ntp container here is not a presence container. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Wed Aug 28 03:42:23 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E8611E816E for ; Wed, 28 Aug 2013 03:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=0.401, 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 oiS1sp12f8Wr for ; Wed, 28 Aug 2013 03:42:08 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3397511E8160 for ; Wed, 28 Aug 2013 03:42:08 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 3389A14034F; Wed, 28 Aug 2013 12:42:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1377686527; bh=zuKhYon71X3e4B6RDR4f5SNuOfeM5BDNbOT7ciRlvtc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=VWf5tbR74crY3PTmdXkl9BAGrTtoJt9awMCERWrqHGE63XhUSIhALAkNrAz3fYAXH HLGzZsWYOHvf41nhqoXogUnCp/2uVQt3aCvf9pS4xkt8rwumZP1XNsP2Et8gdj3Qnh /rXK5p1V21C6NZNW9RgYrtgRHLUoC3DmG6pD+eqo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130828094618.GA32565@elstar.local> Date: Wed, 28 Aug 2013 12:42:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <569CF208-0808-499B-8A55-782C95CF3B25@nic.cz> References: <20130825203831.20582.30133.idtracker@ietfa.amsl.com> <20130825.225734.296927526.mbj@tail-f.com> <20130827132714.GA29951@elstar.local> <20130827.222910.519872461.mbj@tail-f.com> <20130827210609.GA30939@elstar.local> <20130828094618.GA32565@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 10:42:23 -0000 On Aug 28, 2013, at 11:46 AM, Juergen Schoenwaelder = wrote: > On Tue, Aug 27, 2013 at 11:06:09PM +0200, Juergen Schoenwaelder wrote: >> On Tue, Aug 27, 2013 at 10:29:10PM +0200, Martin Bjorklund wrote: >>=20 >>>> d) The data model uses a number of presence containers. I am = wondering >>>> whether all of them make sense as presence containers. >>>>=20 >>>> /if:interfaces/if:interface/ipv4 >>>> /if:interfaces/if:interface/ipv6 >>>>=20 >>>> These two really do not carry any semantics or at least the = textual >>>> description "Configure IPvX on this interface" leaves it unclear >>>> what one has to implement. Why are these presence containers? >>>=20 >>> Since we have an 'enabled' leaf with a default value of 'true' under >>> these containers, it means that once the container is created, by >>> default IP is enabled. If we made them np-containers, we'd have to >>> change the default of 'enabled' to 'false'. (unless we want to by >>> default enable ipv4 and ipv6 on all (capable) interfaces, but I = don't >>> think we want that). >>=20 >> OK, I see. This needs better explanation I think. The phrase >> "Configure IPvX on this interface" is not sufficient - I missed the >> subtle point of the enabled default value. Perhaps something like >> this (feel free to find a better wording): >>=20 >> "Presence of the ipvX enables IPvX unless the enabled leaf >> (which defaults to 'true') is set to 'false'" >=20 > One more question. Should this same pattern be applied to >=20 > +--rw system > | +--rw ntp > | +--rw enabled? boolean >=20 > in draft-ietf-netmod-system-mgmt-08.txt? The ntp container here is not > a presence container. IMO, yes. I also think there should be "ntp" and "dns-resolver" items under = "system-state" because in both cases there is currently no way for the = client to learn addresses of servers that were obtained from DHCP. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C