From nobody Wed May 7 09:03:38 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B5D1A07D1; Wed, 7 May 2014 09:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYMY7jkAO2a0; Wed, 7 May 2014 09:03:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C644B1A07C9; Wed, 7 May 2014 09:03:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140507160332.4105.65703.idtracker@ietfa.amsl.com> Date: Wed, 07 May 2014 09:03:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/PW09z0zXcFMHWL1mMrWZMtHRtg0 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-consistent-control-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 16:03:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : Consistent Control Mechanism in Software Defined Network Authors : Lieguang Zeng Ye Zhou Mao Yang Yong Li Depeng Jin Li Su Filename : draft-ietf-forces-consistent-control-00.txt Pages : 7 Date : 2014-05-07 Abstract: This document introduces a consistent control mechanism in the framework of Software Defined Network (SDN), which is one method to achieve forwarding and control element separation. In detail, this mechanism uses a centralized control element to control multiple forwarding elements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-consistent-control/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-consistent-control-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 7 09:20:47 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAEB1A032F for ; Wed, 7 May 2014 09:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBXwE9Er2pDP for ; Wed, 7 May 2014 09:20:43 -0700 (PDT) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id 58A4A1A0394 for ; Wed, 7 May 2014 09:20:42 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id jx11so1627496veb.0 for ; Wed, 07 May 2014 09:20:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=q6m+4Nbo6k0CrlAJbTLxnTZndG9UDw3v14jdrnL4o3U=; b=WcRKTUvIFF5WuMeJ/GrXb6uc2iElDqjw+KDdxVc1l4LbyLjD4aQw0qKgiFWhjrQsCZ MIqa67xZ7G642T2Scj1QJkCg1dcog5YjNnqggiTKHeQOsvSljQkto7kQMbV2jD2CgTXF N0sxKJrQyxe7Mml2DwOiLEGHsuPmuuOPmWtlhwleh8/XmUeTlCQQZ/xOuMJcEs1ULWqA KakCUky4XWUrrjxbe/yBABDOtZ2xXTjJw43EvU1gj2icdk54JVEakbWXp5WdjZ04pW72 yCihsMODlsUMgQ96z8Jjceqs5VOa5jMV602zuXDxyIgkO/KtVhuVF3mDUt7owItZ2heY l9QQ== X-Gm-Message-State: ALoCoQkxqowC0oWYShTkWSS2+xfdZNEXEEAOGHqrL5cH3sONlGJ3R3wrjs/wTyjZZCHHpn7nDK+a X-Received: by 10.52.163.145 with SMTP id yi17mr2335632vdb.46.1399479637836; Wed, 07 May 2014 09:20:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Wed, 7 May 2014 09:20:17 -0700 (PDT) From: Jamal Hadi Salim Date: Wed, 7 May 2014 12:20:17 -0400 Message-ID: To: "i2rs@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/NdJ0MemrJSU54LVGLL7ldka_MeQ Cc: Jeffrey Haas , "forces@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic Subject: [forces] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 16:20:44 -0000 I have started updating the I2RS wiki on viability of using ForCES for I2RS. I posted those requirements on the list over the weekend and checking against them. To the other proposals (netconf, restconf, yang), it would be nice if we have a common set of requirements to check against. I will be updating the wiki as more discussions for requirements come up as well as put more commentary. Enjoy! http://wiki.tools.ietf.org/wg/i2rs/trac/wiki/ForcesAnalysis cheers, jamal From nobody Wed May 7 12:46:59 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2501A00E8 for ; Wed, 7 May 2014 12:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYns9TxJ49X0 for ; Wed, 7 May 2014 12:46:55 -0700 (PDT) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id A0B001A02AC for ; Wed, 7 May 2014 12:46:55 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id db12so1925028veb.39 for ; Wed, 07 May 2014 12:46:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=fRNjHJ7fHaiMoE5Ap7IxO07HiYXvDvrf+RytDP+Wh3c=; b=Ukx5fZGMi6aHXt84ifMeaVXesh0C6yPOI0p9dwepSZ6KsBb61pt5AMHFxMiLnsK+uz wryu1A7ZhRATys9q6Lh3V2xxwOjZai4X0PAa3hWNTvtEtP5kESQIkO02UgQuA5ta1dpT VdfraqDGGxnMS+QsUR/pBU+LmInmjv3fvB29yfXmWOu3lGcO9vhYqPrCpW8KKIAyZb/F Wh1+AoU7X8qAz+bfzBm7JiVVItiah6ljjumaKn5aRQTaAxgUhsgDxjnsQhv3jBI2LAq5 kLHLA4wrJk4qodHjVU1PzpiPSNOSI23t28Lxqgwdrw7eSmz3zHwK3wWwEIFq7LCR/OlU jwNg== X-Gm-Message-State: ALoCoQkNeeI5mxQv0RBxBrdOY0DJDJzZv6hk4VK/LnRm/EZbA3TGuPbbpYGi7kh7K5qqHGYsWoaB X-Received: by 10.221.74.200 with SMTP id yx8mr40327805vcb.3.1399492011222; Wed, 07 May 2014 12:46:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.10.136 with HTTP; Wed, 7 May 2014 12:46:31 -0700 (PDT) From: Jamal Hadi Salim Date: Wed, 7 May 2014 15:46:31 -0400 Message-ID: To: draft-ietf-forces-consistent-control@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/GceVVxumdWrUwNn1dLRdGJSU3v4 Cc: "forces@ietf.org" Subject: [forces] regarding draft-ietf-forces-consistent-control X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 19:46:57 -0000 To the authors: There is a process error in your draft. The name of the draft should not start with draft-ietf-forces-XXX-00. Only drafts which have been accepted by the WG should have such a prefix. Take a look at: http://datatracker.ietf.org/wg/forces/ Your document should be renamed to be the same style as "Related Internet-drafts" document at the bottom of that page. Example "draft-jhs-forces-protoextenstion-02" I have a feeling i clicked on the wrong button - I was trying to reject it and i may have accepted it instead. Please make these changes and re-submit. BTW: Just some comment - I have not read your document. Since you are submitting this to the ForCES WG, can you please change figure 1 where it says "(e.g., OpenFlow [FORCES-OF])" to make it read as ForCES acting on OF LFBs. I will provide more comments when you do a full submission with the changed names. Also email address for yetiero@gmail.com is bouncing. Please provide a proper email in your update. cheers, jamal From nobody Mon May 12 07:04:12 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA931A0721 for ; Mon, 12 May 2014 07:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h41ri9oGckRu for ; Mon, 12 May 2014 07:04:10 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id EAC8A1A0711 for ; Mon, 12 May 2014 07:04:06 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id lc6so8726061vcb.2 for ; Mon, 12 May 2014 07:04:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LMkimW4Hg77ElYv78U8ZF5eJ/lgQBmiw/aDgb7xuSVE=; b=V3Hw0B8L+F+2QG2MF1RYz/OKwpbpwsSxdQFDopbwni9KsEsJrH/6spVXpm/jqrEIUn wjJPEsUuND4KFFTxVNYclglU2+svJXrH7ARYtoSehFHON8qjI+FMEf5W0zw3nps5trLu a7aofy4vqeXvn1/yr7/np18WYOL6m0v9asa1XIVJtMf/PjehK8pePJ2kKXdEkAuDxODA uNID4HwNJhWrv5hfBwVi3xNCgQbK4bkmGxn77DeQnSh7PsBNDzy61GnJKmSoUK75pMYT P3UzLWYm35UCI6h/TxS4CV1XBjZsm3EfJYVWCwWl+7aB++ozdWP3F2U71CALV19cJIA6 CUqw== X-Gm-Message-State: ALoCoQkAi3nWJSC7sRfv87zTKpOl+xzeaTVUHUnc3GbHX0DRLb4Yf+oTLwCY9gnXW8J4HiOzJtM4 X-Received: by 10.52.173.165 with SMTP id bl5mr19356470vdc.13.1399903440854; Mon, 12 May 2014 07:04:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.201.164 with HTTP; Mon, 12 May 2014 07:03:40 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Mon, 12 May 2014 10:03:40 -0400 Message-ID: To: "i2rs@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/dT2_zxuxgouitoJYDrly0FJcBsw Cc: Jeffrey Haas , "forces@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic Subject: Re: [forces] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 14:04:11 -0000 I have made another update. question to chairs - if there are none of Restconf/netconf/yang updates to the wiki does that mean you are going to disqualify them from the process ? (/me runs). cheers, jamal On Wed, May 7, 2014 at 12:20 PM, Jamal Hadi Salim wrote: > I have started updating the I2RS wiki on viability of using ForCES > for I2RS. I posted those requirements on the list over the weekend > and checking against them. > To the other proposals (netconf, restconf, yang), it would be nice > if we have a common set of requirements to check against. > I will be updating the wiki as more discussions for requirements come up > as well as put more commentary. > > Enjoy! > http://wiki.tools.ietf.org/wg/i2rs/trac/wiki/ForcesAnalysis > > cheers, > jamal From nobody Tue May 13 19:09:32 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA31C1A0125; Tue, 13 May 2014 18:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id untMZ1WQaDRO; Tue, 13 May 2014 18:37:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 415521A0160; Tue, 13 May 2014 18:37:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C7AAFC1FF; Tue, 13 May 2014 21:37:37 -0400 (EDT) Date: Tue, 13 May 2014 21:37:37 -0400 From: Jeffrey Haas To: Jamal Hadi Salim Message-ID: <20140514013737.GB13387@pfrc> 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) Archived-At: http://mailarchive.ietf.org/arch/msg/forces/SSiWEhy6cPzwut8Hwf1XyfjgEiQ X-Mailman-Approved-At: Tue, 13 May 2014 19:09:30 -0700 Cc: "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , Jeffrey Haas , "forces@ietf.org" Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 01:37:45 -0000 Jamal, On Mon, May 12, 2014 at 10:03:40AM -0400, Jamal Hadi Salim wrote: > I have made another update. > question to chairs - if there are none of Restconf/netconf/yang > updates to the wiki > does that mean you are going to disqualify them from the process ? > (/me runs). Probably not. :-) Thank you for taking the time to fill in the wiki entry. I'd like to encourage the WG to spend a few moments looking over the information Jamal entered. (And, if our Netconf/Yang champions would care to crib his text and use it as the basis for their own, that would be similarly helpful.) The breakdown of Data Model Requirements is particularly a good one. -- Jeff > > cheers, > jamal > > On Wed, May 7, 2014 at 12:20 PM, Jamal Hadi Salim wrote: > > I have started updating the I2RS wiki on viability of using ForCES > > for I2RS. I posted those requirements on the list over the weekend > > and checking against them. > > To the other proposals (netconf, restconf, yang), it would be nice > > if we have a common set of requirements to check against. > > I will be updating the wiki as more discussions for requirements come up > > as well as put more commentary. > > > > Enjoy! > > http://wiki.tools.ietf.org/wg/i2rs/trac/wiki/ForcesAnalysis > > > > cheers, > > jamal > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed May 14 03:11:11 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D06A1A0233; Tue, 13 May 2014 22:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eGNUF8AfyKO; Tue, 13 May 2014 22:43:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id AF0091A022F; Tue, 13 May 2014 22:43:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8E588FD1; Wed, 14 May 2014 07:43:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pp56MO6ITgaP; Wed, 14 May 2014 07:43:13 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 14 May 2014 07:43:13 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32A0220017; Wed, 14 May 2014 07:43:13 +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 zDtesCw3-BeG; Wed, 14 May 2014 07:43:12 +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 BF7D920013; Wed, 14 May 2014 07:43:11 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id B8BEC2CD1365; Wed, 14 May 2014 07:43:10 +0200 (CEST) Date: Wed, 14 May 2014 07:43:10 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Jeffrey Haas , Jamal Hadi Salim , "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , "forces@ietf.org" References: <20140514013737.GB13387@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140514013737.GB13387@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/forces/-VjD0--DWrhvtJHDOuDY_uk3ido X-Mailman-Approved-At: Wed, 14 May 2014 03:11:11 -0700 Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Andy Bierman , "forces@ietf.org" Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 05:43:24 -0000 On Tue, May 13, 2014 at 09:37:37PM -0400, Jeffrey Haas wrote: > Jamal, > > On Mon, May 12, 2014 at 10:03:40AM -0400, Jamal Hadi Salim wrote: > > I have made another update. > > question to chairs - if there are none of Restconf/netconf/yang > > updates to the wiki > > does that mean you are going to disqualify them from the process ? > > (/me runs). > > Probably not. :-) > > Thank you for taking the time to fill in the wiki entry. > > I'd like to encourage the WG to spend a few moments looking over the > information Jamal entered. (And, if our Netconf/Yang champions would care > to crib his text and use it as the basis for their own, that would be > similarly helpful.) > > The breakdown of Data Model Requirements is particularly a good one. > I do not understand the meaning of the following: 3) The data model MUST be able to express semantics of instances. I am not sure why this is a MUST: 2) The model MUST be object oriented. This allows it to extensible in the form of templating and sub-classing. In particular, if 'object oriented' means classes and sub-classes, what does this have to do with templating? Perhaps this is backwards and the requirement really is: 2a) The model MUST be extensible. 2b) The model MUST allow templating. But even then I am not even sure what 'templating' means. /js PS: I may regret having sent this message. I believe requirement discussions like this are not helpful in making a decision since this just leads to an endless debate about the requirements. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed May 14 05:42:34 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D311A006D; Wed, 14 May 2014 05:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9y-3Y62AnDZ; Wed, 14 May 2014 05:42:29 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7751A006B; Wed, 14 May 2014 05:42:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id BB2A71BD1987; Wed, 14 May 2014 05:42:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-10.clppva.east.verizon.net [70.106.135.10]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8631E1BD1980; Wed, 14 May 2014 05:42:21 -0700 (PDT) Message-ID: <537364AB.5040702@joelhalpern.com> Date: Wed, 14 May 2014 08:42:19 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jeffrey Haas , Jamal Hadi Salim , "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , "forces@ietf.org" References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> In-Reply-To: <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/forces/xe3Wkr5UONVYbmVe8gRR0Tk4Yeg Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 12:42:30 -0000 Templating is described in the archtiecture document. However, as I said when i presented the material, this is a topic on which the authors disagree. I personally do not think it should be a protocol behavior, and therefore do not see it as something the model needs to represent. The basic idea of templating is to allow the I2RS client to say to the I2RS agent "I want to set this instance to these values, but for all the things I don't specify, use this template over here to determine what values to set." This clearly has power. Equally clearly, it can be done at the client rather than at the agent. Yours, Joel On 5/14/14, 1:43 AM, Juergen Schoenwaelder wrote: ... > > 2b) The model MUST allow templating. > > But even then I am not even sure what 'templating' means. ... From nobody Wed May 14 06:22:21 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAE51A0095; Wed, 14 May 2014 06:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6QU7xJ1P15A; Wed, 14 May 2014 06:22:16 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 880481A009C; Wed, 14 May 2014 06:22:16 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D8BF9C26A; Wed, 14 May 2014 09:22:09 -0400 (EDT) Date: Wed, 14 May 2014 09:22:09 -0400 From: Jeffrey Haas To: Jeffrey Haas , Jamal Hadi Salim , "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , "forces@ietf.org" Message-ID: <20140514132209.GD16861@pfrc> References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/forces/AVLPPJrAY6vB44U_G0tH-jCT6Qo Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 13:22:17 -0000 Juergen, On Wed, May 14, 2014 at 07:43:10AM +0200, Juergen Schoenwaelder wrote: > PS: I may regret having sent this message. I believe requirement > discussions like this are not helpful in making a decision since > this just leads to an endless debate about the requirements. The goal is not to endlessly debate requirements, it's to converge on the understood set of minimum requirements. While we've had significant good discussion about each proposed mechanism, it has largely been in a "compare and contrast existing mechanisms" format. At the end of the day (or perhaps week, I believe), we will have made our choice and will hopefully be crystal clear on what work is missing so we can move forward in an expeditious fashion. Thanks for contributing. -- Jeff From nobody Wed May 14 06:59:16 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEE71A00B1 for ; Wed, 14 May 2014 06:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uim2ErNmMkhu for ; Wed, 14 May 2014 06:59:09 -0700 (PDT) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE1E1A009C for ; Wed, 14 May 2014 06:59:09 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id sa20so2469069veb.9 for ; Wed, 14 May 2014 06:59:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZDTxvaS6t3fBo9tGs5serCo49B6FRxa4KbbxpRc/THs=; b=PMuqGPT2z8BSICTs8B3esz4wggozTJKjsoiygxV/AouPVWnL0PbiRAMJUSideZi1vN SOAZ0OLuLW1CgukSMOn2fNXCIMhMEQHpcLvszW49+ZXQVUiaRHyxp6kg9YwnhKlWZgpz i7ZCfiuziphgKFXYFY/5KQyqcI1inx5wD3krNxsiMsHyvnqhBQQJH81nmSOc3qcKBWI9 AnIrBtlONdEOIZj08In6hYC2JQHHYvuzbvQS9S1map+fk58tzwT5oKbcyX5/Qm/fHLE1 BDowP6pfRxippwD3at4x7hYxfjlTqwZjBzNHuT5voD6vG4NYWAZkxFGovPaQQUkD9PF1 VCgg== X-Gm-Message-State: ALoCoQkPQBsyVwAb5k8kZ0d4WEutnzojTV2hrUz97UgbXGnS9yha7MBCSCwHow7ehDA4fj9IHxIV X-Received: by 10.58.74.38 with SMTP id q6mr3171828vev.7.1400075942436; Wed, 14 May 2014 06:59:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.201.164 with HTTP; Wed, 14 May 2014 06:58:42 -0700 (PDT) In-Reply-To: <537364AB.5040702@joelhalpern.com> References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> From: Jamal Hadi Salim Date: Wed, 14 May 2014 09:58:42 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/sMjY1QmtR971008MhriPPqd_xYM Cc: "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , Jeffrey Haas , "forces@ietf.org" Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 13:59:10 -0000 On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern wrote: > Templating is described in the archtiecture document. > However, as I said when i presented the material, this is a topic on which > the authors disagree. > I personally do not think it should be a protocol behavior, and therefore do > not see it as something the model needs to represent. > > The basic idea of templating is to allow the I2RS client to say to the I2RS > agent "I want to set this instance to these values, but for all the things I > don't specify, use this template over here to determine what values to set." > This clearly has power. Equally clearly, it can be done at the client > rather than at the agent. > Seems like i abused the term "template". I.e it seems to me that would fall under " Default values MUST be possible to specify" - which is described in the wiki. Shouldnt this be a model problem? I will fix the wiki entry and remove it from that sub-section. On the OO class/instances: The motivation is to be able to describe "set blah to RIB instance foo". The concept for abstracting a "factory" which is essentially a "class" vs an "instance" of that class seems to belong to the model. cheers, jamal From nobody Wed May 14 07:29:12 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AAA1A00D5; Wed, 14 May 2014 07:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuAwUwRLyelf; Wed, 14 May 2014 07:29:08 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6341A00D4; Wed, 14 May 2014 07:29:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 157581BD6855; Wed, 14 May 2014 07:29:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-10.clppva.east.verizon.net [70.106.135.10]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C31B51BD6850; Wed, 14 May 2014 07:28:59 -0700 (PDT) Message-ID: <53737DAA.1040809@joelhalpern.com> Date: Wed, 14 May 2014 10:28:58 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jamal Hadi Salim References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/forces/qthPd_eQORkUdqf8jGUgPwQLPyM Cc: "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , Jeffrey Haas , "forces@ietf.org" Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 14:29:10 -0000 (Alia, correct me if I mis-represent this concept.) No, temnplating is not just "Default values must be possible to specify." An example is that you might have a scheduling structure. it has a set of defaults which create a specific scheduling discipling. The Client can create a scheduling instance, and can over-ride any and all of those defaults. So far, that is just modeling with defaults. The idea with templates is that the Client could also say "For all the values I don't specify, use the WFQ template" or the EF template, or ... If the client does that, the agent would treat the values from that template which are specified in the template and are not specified in the request from the controller as if they had been specified by the controller, rather than using the base defaults. Coupled with this, some mechanism would provide these templates. The power here is that there might be different templates for the "EF Scheduling template" on different boxes to reflect how each box should be configured to achieve the policy goal. Conversely, clearly, all of this data can be on the client and the client can do the inclusion. Yours, Joel On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: > On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern wrote: >> Templating is described in the archtiecture document. >> However, as I said when i presented the material, this is a topic on which >> the authors disagree. >> I personally do not think it should be a protocol behavior, and therefore do >> not see it as something the model needs to represent. >> >> The basic idea of templating is to allow the I2RS client to say to the I2RS >> agent "I want to set this instance to these values, but for all the things I >> don't specify, use this template over here to determine what values to set." >> This clearly has power. Equally clearly, it can be done at the client >> rather than at the agent. >> > > Seems like i abused the term "template". I.e it seems to me that would > fall under > " Default values MUST be possible to specify" - which is described in the wiki. > Shouldnt this be a model problem? > I will fix the wiki entry and remove it from that sub-section. > > On the OO class/instances: > The motivation is to be able to describe "set blah to RIB instance foo". The > concept for abstracting a "factory" which is essentially a "class" vs > an "instance" of > that class seems to belong to the model. > > > cheers, > jamal > From nobody Wed May 14 07:55:47 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FA31A008F for ; Wed, 14 May 2014 07:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DX0K125crjlA for ; Wed, 14 May 2014 07:49:41 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9DC1A00FC for ; Wed, 14 May 2014 07:49:40 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id l6so3017638qcy.9 for ; Wed, 14 May 2014 07:49:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8G5x3btDJf/YHMHsIeN+pemvCUMsfF15tAmjTe4feWk=; b=BhCvk5BXKMgobbG263Bdrfxg38GoyAJ7V6+xGIhe4NRZPlFaTMVglnqXIXSyRNcJFH VcOv06FyQ9HJ/HwVVmsKsr1DlFd730N2576aypITCh5sGxYexv+T6Khoci4TpIlr8njg yfSIc3E6nbfjLrj/+lK52gN6QUOHp2ynJ778R0XjvQHhdXp0GstfzO+Mqg0b0AOlL2jI pIT0MxuZMQfmUSxbE0+VO4Ki8KmBFo++w5vewzLwe3fz3N7Y8K8a8lHN0Es6+CsNb4cR aJcDijCRdUAznYNHOFs1xH23qqmAGq5NGz5isyHoIpq3Uvi3n8fQvxhyME2gXR/zJJaK NSQA== X-Gm-Message-State: ALoCoQlEfclHvKCZrGtP7S/ZOLl8DPipFHwJZzF7NQkf7KShLN1jMElfcAxdyUZ5MSXuzRvtSHk9 MIME-Version: 1.0 X-Received: by 10.229.96.199 with SMTP id i7mr6814062qcn.20.1400078974120; Wed, 14 May 2014 07:49:34 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Wed, 14 May 2014 07:49:33 -0700 (PDT) In-Reply-To: <53737DAA.1040809@joelhalpern.com> References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> Date: Wed, 14 May 2014 07:49:33 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a1133886ee906f304f95d49af Archived-At: http://mailarchive.ietf.org/arch/msg/forces/tbj33pygywZLdmzE0_Fjed3W6ws X-Mailman-Approved-At: Wed, 14 May 2014 07:55:44 -0700 Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Jeffrey Haas , "forces@ietf.org" Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 14:49:43 -0000 --001a1133886ee906f304f95d49af Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 14, 2014 at 7:28 AM, Joel M. Halpern wrote: > (Alia, correct me if I mis-represent this concept.) > > No, temnplating is not just "Default values must be possible to specify." > > An example is that you might have a scheduling structure. it has a set of > defaults which create a specific scheduling discipling. > The Client can create a scheduling instance, and can over-ride any and all > of those defaults. > So far, that is just modeling with defaults. > > The idea with templates is that the Client could also say "For all the > values I don't specify, use the WFQ template" or the EF template, or ... > If the client does that, the agent would treat the values from that > template which are specified in the template and are not specified in the > request from the controller as if they had been specified by the > controller, rather than using the base defaults. > > Coupled with this, some mechanism would provide these templates. The > power here is that there might be different templates for the "EF > Scheduling template" on different boxes to reflect how each box should be > configured to achieve the policy goal. > > Conversely, clearly, all of this data can be on the client and the client > can do the inclusion. > A generic template feature would be interesting, and may not be a lot of work. If a template includes lots of data, then it could be much faster (CPU, on-the-wire) than inline edits. Templates are usually just for convenience and consistency, but consistency (even across clients) is important. In the generic sense, a YANG template would be a sub-tree without keys. Whatever nodes were missing from the client request would get merged in by the server. (Some NETCONF servers are designed to do this merge very quickly). The protocol operation would say "edit that data with this patch and template X". > Yours, > Joel > Andy > > On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: > >> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern >> wrote: >> >>> Templating is described in the archtiecture document. >>> However, as I said when i presented the material, this is a topic on >>> which >>> the authors disagree. >>> I personally do not think it should be a protocol behavior, and >>> therefore do >>> not see it as something the model needs to represent. >>> >>> The basic idea of templating is to allow the I2RS client to say to the >>> I2RS >>> agent "I want to set this instance to these values, but for all the >>> things I >>> don't specify, use this template over here to determine what values to >>> set." >>> This clearly has power. Equally clearly, it can be done at the client >>> rather than at the agent. >>> >>> >> Seems like i abused the term "template". I.e it seems to me that would >> fall under >> " Default values MUST be possible to specify" - which is described in the >> wiki. >> Shouldnt this be a model problem? >> I will fix the wiki entry and remove it from that sub-section. >> >> On the OO class/instances: >> The motivation is to be able to describe "set blah to RIB instance foo". >> The >> concept for abstracting a "factory" which is essentially a "class" vs >> an "instance" of >> that class seems to belong to the model. >> >> >> cheers, >> jamal >> >> --001a1133886ee906f304f95d49af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, May 14, 2014 at 7:28 AM, Joel M. Halpern = <jmh@joelhalper= n.com> wrote:
(Alia, correct me if I mis-represent this co= ncept.)

No, temnplating is not just "Default values must be possible to specif= y."

An example is that you might have a scheduling structure. =A0it has a set o= f defaults which create a specific scheduling discipling.
The Client can create a scheduling instance, and can over-ride any and all = of those defaults.
So far, that is just modeling with defaults.

The idea with templates is that the Client could also say "For all the= values I don't specify, use the WFQ template" or the EF template,= or ... =A0If the client does that, the agent would treat the values from t= hat template which are specified in the template and are not specified in t= he request from the controller as if they had been specified by the control= ler, rather than using the base defaults.

Coupled with this, some mechanism would provide these templates. =A0The pow= er here is that there might be different templates for the "EF Schedul= ing template" on different boxes to reflect how each box should be con= figured to achieve the policy goal.

Conversely, clearly, all of this data can be on the client and the client c= an do the inclusion.


A g= eneric template feature would be interesting, and may not be
a lot of work. If a template includes lots of data, then it
could= be much faster (CPU, on-the-wire) than inline edits.

<= div>Templates are usually just for convenience and consistency,
but consistency (even across clients) is important.

In the generic sense, a YANG template would be a sub-tree
witho= ut keys. Whatever nodes were missing from the client request
would get merged in by the server. (Some NETCONF servers are designed
=
to do this merge very quickly). =A0The protocol operation would say
"edit that data with this patch and template X".


Yours,
Joel


Andy
=A0<= /div>

On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote:
On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
Templating is described in the archtiecture document.
However, as I said when i presented the material, this is a topic on which<= br> the authors disagree.
I personally do not think it should be a protocol behavior, and therefore d= o
not see it as something the model needs to represent.

The basic idea of templating is to allow the I2RS client to say to the I2RS=
agent "I want to set this instance to these values, but for all the th= ings I
don't specify, use this template over here to determine what values to = set."
This clearly has power. =A0Equally clearly, it can be done at the client rather than at the agent.


Seems like i abused the term "template". I.e it seems to me that = would
fall under
" Default values MUST be possible to specify" - which is describe= d in the wiki.
Shouldnt this be a model problem?
I will fix the wiki entry and remove it from that sub-section.

On the OO class/instances:
The motivation is to be able to describe "set blah to RIB instance foo= ". The
concept for abstracting a "factory" which is essentially a "= class" vs
an "instance" of
that class seems to belong to the model.


cheers,
jamal


--001a1133886ee906f304f95d49af-- From nobody Wed May 14 08:22:56 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7831A00B8; Wed, 14 May 2014 08:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPLaL-MNcdES; Wed, 14 May 2014 08:03:04 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E2D851A008F; Wed, 14 May 2014 08:03:03 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 142so1667703ykq.32 for ; Wed, 14 May 2014 08:02:57 -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=W+n4KIN9NLC9wsJZXHjbC6HGgy+equlmOXu1GRnbZTc=; b=b7gmFFZXL1KLB1d3/W6TCU2VlbN64jbYh2rUiLzYKMEyWKbaTWERzS1W/33crct8eJ Q9x41BtWr3UURGSM8s+CPrUgUBFrzkdGMaIkjsQvLQxPJC/TYKQoSx8HbIYrzUQzYITN hL6Rvw86PwgD3NDDieQ6MdzzP6Mqzws1eTGj2o+TagM+zbxcomYuRBHHG3C6mjPx/Hg8 8CIzGp9Zk6WzHe0Pz5bNWR6tVDWbz/OiLpiIdCuK+CExcxqxlfiOFBONAY2NcDmcA9o7 +prvZaOKp98YSYTEbjuAJ5wcOtxTHnNRdcWLDIuFA6Dp7CzDN79iQC4k2NNuQCnFfAY1 03iA== MIME-Version: 1.0 X-Received: by 10.236.220.72 with SMTP id n68mr6224364yhp.102.1400079777163; Wed, 14 May 2014 08:02:57 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Wed, 14 May 2014 08:02:57 -0700 (PDT) In-Reply-To: <53737DAA.1040809@joelhalpern.com> References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> Date: Wed, 14 May 2014 11:02:57 -0400 Message-ID: From: Alia Atlas To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/l2PHKwbPQqfdr4kTbNoOphvtHv0 X-Mailman-Approved-At: Wed, 14 May 2014 08:22:52 -0700 Cc: "i2rs@ietf.org" , Edward Crabbe , Dean Bogdanovic , Andy Bierman , Jeffrey Haas , "forces@ietf.org" Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 15:03:06 -0000 Hi Joel, Just quickly, the key point is to avoid having the client need to understand all the different ways of making the desired behavior happen or specifying all the details when there's only a small set that need to change. A use-case is something like assigning traffic into a particular queue or configuring that queue where there aren't good and common abstractions. Alia On Wed, May 14, 2014 at 10:28 AM, Joel M. Halpern wrote: > (Alia, correct me if I mis-represent this concept.) > > No, temnplating is not just "Default values must be possible to specify." > > An example is that you might have a scheduling structure. it has a set of > defaults which create a specific scheduling discipling. > The Client can create a scheduling instance, and can over-ride any and all > of those defaults. > So far, that is just modeling with defaults. > > The idea with templates is that the Client could also say "For all the > values I don't specify, use the WFQ template" or the EF template, or ... If > the client does that, the agent would treat the values from that template > which are specified in the template and are not specified in the request > from the controller as if they had been specified by the controller, rather > than using the base defaults. > > Coupled with this, some mechanism would provide these templates. The power > here is that there might be different templates for the "EF Scheduling > template" on different boxes to reflect how each box should be configured to > achieve the policy goal. > > Conversely, clearly, all of this data can be on the client and the client > can do the inclusion. > > Yours, > Joel > > > On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: >> >> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern >> wrote: >>> >>> Templating is described in the archtiecture document. >>> However, as I said when i presented the material, this is a topic on >>> which >>> the authors disagree. >>> I personally do not think it should be a protocol behavior, and therefore >>> do >>> not see it as something the model needs to represent. >>> >>> The basic idea of templating is to allow the I2RS client to say to the >>> I2RS >>> agent "I want to set this instance to these values, but for all the >>> things I >>> don't specify, use this template over here to determine what values to >>> set." >>> This clearly has power. Equally clearly, it can be done at the client >>> rather than at the agent. >>> >> >> Seems like i abused the term "template". I.e it seems to me that would >> fall under >> " Default values MUST be possible to specify" - which is described in the >> wiki. >> Shouldnt this be a model problem? >> I will fix the wiki entry and remove it from that sub-section. >> >> On the OO class/instances: >> The motivation is to be able to describe "set blah to RIB instance foo". >> The >> concept for abstracting a "factory" which is essentially a "class" vs >> an "instance" of >> that class seems to belong to the model. >> >> >> cheers, >> jamal >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed May 14 08:22:57 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7771A00C2; Wed, 14 May 2014 08:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwxxE2DLyvGo; Wed, 14 May 2014 08:18:18 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id D3FC21A00B8; Wed, 14 May 2014 08:18:17 -0700 (PDT) Received: from [172.21.2.104] (unknown [74.174.42.172]) by lucidvision.com (Postfix) with ESMTP id 38E1B27A7F4E; Wed, 14 May 2014 11:18:01 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_EB315656-BE63-4712-879F-75B93B138555"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: <53737DAA.1040809@joelhalpern.com> Date: Wed, 14 May 2014 11:18:00 -0400 Message-Id: References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/forces/4vC3LRwyntfyFQ3Y7n3gYJ4QHRU X-Mailman-Approved-At: Wed, 14 May 2014 08:22:51 -0700 Cc: "i2rs@ietf.org" , Crabbe Edward , Dean Bogdanovic , Andy Bierman , Jeffrey Haas , "forces@ietf.org" Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 15:18:20 -0000 --Apple-Mail=_EB315656-BE63-4712-879F-75B93B138555 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Its not just default values; its more like a set of = preconfigured values for a set of objects.=20 --Tom On May 14, 2014:10:28 AM, at 10:28 AM, Joel M. Halpern = wrote: > (Alia, correct me if I mis-represent this concept.) >=20 > No, temnplating is not just "Default values must be possible to = specify." >=20 > An example is that you might have a scheduling structure. it has a = set of defaults which create a specific scheduling discipling. > The Client can create a scheduling instance, and can over-ride any and = all of those defaults. > So far, that is just modeling with defaults. >=20 > The idea with templates is that the Client could also say "For all the = values I don't specify, use the WFQ template" or the EF template, or ... = If the client does that, the agent would treat the values from that = template which are specified in the template and are not specified in = the request from the controller as if they had been specified by the = controller, rather than using the base defaults. >=20 > Coupled with this, some mechanism would provide these templates. The = power here is that there might be different templates for the "EF = Scheduling template" on different boxes to reflect how each box should = be configured to achieve the policy goal. >=20 > Conversely, clearly, all of this data can be on the client and the = client can do the inclusion. >=20 > Yours, > Joel >=20 > On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: >> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern = wrote: >>> Templating is described in the archtiecture document. >>> However, as I said when i presented the material, this is a topic on = which >>> the authors disagree. >>> I personally do not think it should be a protocol behavior, and = therefore do >>> not see it as something the model needs to represent. >>>=20 >>> The basic idea of templating is to allow the I2RS client to say to = the I2RS >>> agent "I want to set this instance to these values, but for all the = things I >>> don't specify, use this template over here to determine what values = to set." >>> This clearly has power. Equally clearly, it can be done at the = client >>> rather than at the agent. >>>=20 >>=20 >> Seems like i abused the term "template". I.e it seems to me that = would >> fall under >> " Default values MUST be possible to specify" - which is described in = the wiki. >> Shouldnt this be a model problem? >> I will fix the wiki entry and remove it from that sub-section. >>=20 >> On the OO class/instances: >> The motivation is to be able to describe "set blah to RIB instance = foo". The >> concept for abstracting a "factory" which is essentially a "class" vs >> an "instance" of >> that class seems to belong to the model. >>=20 >>=20 >> cheers, >> jamal >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_EB315656-BE63-4712-879F-75B93B138555 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTc4koAAoJEPcO+I7eiUJZ21EP/3wlHxi6hyv0TkhVltUCijAm viHuuK6D7GngmXdwvXnWCqmAgIiMfUhQNsuQmZJKUnexHMfvJZTODA4C1s4s5Ijw mjsXHb8CA9j+wFyKwCwPMrhn89q0fGvUL1+K+HEMfJYc4slrkyTqKkJX4sbjInju JKpy6G059UAB0k3v+ZazagZoVf7H6r8jK03jlKGEmfFdqJxCWhztQKJaijVjQeuF WRTfCXPfu1aBAhr4A6ebRIHhCTmnek9KSzJUfYrabhfoEHYj0RulHksaPl909PJP +co71YoESxNlFfgJAxu1ZmkURGo4Og0wnIkEreJxu0frEWkJYitPegSUeKwjAeEI y6n2qFu2BCco6wtn9ivMWEThsw9ItsKuaHZb4w/f9AI/qfxPfO9xH2hZVaqLz4hP dYWYQzdRTmGeGfZRuHyCunU+ftKIVZCu/+tWxAuugEi//C8mjeBnqEwPlnuTLJ6I s5AtlGGfYgPTlz25/S9DaW9tnO1XvR4PrRoEERRDAbdum/zqpOaqDll0UV+5Dcnz YGrQjwAYk+eq92CcnZ54+pVseN08ataaFrwVMPyocQMmCw0TsD0cMRMPWsUcqK5S poMDKH4k2O3oKN2Ysu9DM6yHRK56wcPo+WDYbyYB4WfxGhJWGrlGqZjA7AdIWNFn h5SpG+eu2lUXBWj+wE9y =jA8R -----END PGP SIGNATURE----- --Apple-Mail=_EB315656-BE63-4712-879F-75B93B138555-- From nobody Wed May 14 08:29:53 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFF71A00A6 for ; Wed, 14 May 2014 08:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggiA_OtaYwh5 for ; Wed, 14 May 2014 08:29:47 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCAA1A00CD for ; Wed, 14 May 2014 08:29:47 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id pa12so2572935veb.26 for ; Wed, 14 May 2014 08:29:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Ylgt/FBlvxIecPKS+WeNkQg5QvfyIKuCm2REKJFyDeU=; b=miS/7QFCgk9RMjI+8hPlrCjTU0NLj0MP3W8nLxLMR2QxmVEMF1qSQEDcZe9Zwct1Jd G4sgC2y6W0AnUiRCpvU2LbFPUI5N5j8X1FGsv9z9SPqm5CMhI85BS0m1MTSExf3/w90e atWHSrthSmwf6Aw4ogt6dK/BlQSsg+PcHJuv/XKckJ3YblNYCjHdE6hU73ifQs/193By 0ahAely3HLiO4rL5gdlgmLCcG5hLB+lYal/z2YsYxCJzm2F5y1EM5LykRiFmCtNpObTF 8zb3TzramkRYDJ4VdBJOSfFuc4gcHYwR0gMu0LetZBvbajXEb0vYQsghZdoHGRGgm6O+ M7cQ== X-Gm-Message-State: ALoCoQlxaGZ8Xbq2QLWVS/rBMwDQsx6cwugoID98tgsjIYsIurG4w+UQaym+MWB6b+Hhs/H16Rqc X-Received: by 10.52.117.237 with SMTP id kh13mr154038vdb.96.1400081380658; Wed, 14 May 2014 08:29:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.201.164 with HTTP; Wed, 14 May 2014 08:29:20 -0700 (PDT) In-Reply-To: References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> From: Jamal Hadi Salim Date: Wed, 14 May 2014 11:29:20 -0400 Message-ID: To: Thomas Nadeau Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/forces/vX3SeWEQHWdTPggvdirBSd-Ggao Cc: "i2rs@ietf.org" , "forces@ietf.org" , Crabbe Edward , Andy Bierman , Dean Bogdanovic , Jeffrey Haas , "Joel M. Halpern" Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 15:29:50 -0000 Ok, I think i get then what Joel was saying. Is this then an implementation issue? cheers, jamal On Wed, May 14, 2014 at 11:18 AM, Thomas Nadeau w= rote: > > Its not just default values; its more like a set of preconfigured= values for a set of objects. > > --Tom > > > On May 14, 2014:10:28 AM, at 10:28 AM, Joel M. Halpern wrote: > >> (Alia, correct me if I mis-represent this concept.) >> >> No, temnplating is not just "Default values must be possible to specify.= " >> >> An example is that you might have a scheduling structure. it has a set = of defaults which create a specific scheduling discipling. >> The Client can create a scheduling instance, and can over-ride any and a= ll of those defaults. >> So far, that is just modeling with defaults. >> >> The idea with templates is that the Client could also say "For all the v= alues I don't specify, use the WFQ template" or the EF template, or ... If= the client does that, the agent would treat the values from that template = which are specified in the template and are not specified in the request fr= om the controller as if they had been specified by the controller, rather t= han using the base defaults. >> >> Coupled with this, some mechanism would provide these templates. The po= wer here is that there might be different templates for the "EF Scheduling = template" on different boxes to reflect how each box should be configured t= o achieve the policy goal. >> >> Conversely, clearly, all of this data can be on the client and the clien= t can do the inclusion. >> >> Yours, >> Joel >> >> On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: >>> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern = wrote: >>>> Templating is described in the archtiecture document. >>>> However, as I said when i presented the material, this is a topic on w= hich >>>> the authors disagree. >>>> I personally do not think it should be a protocol behavior, and theref= ore do >>>> not see it as something the model needs to represent. >>>> >>>> The basic idea of templating is to allow the I2RS client to say to the= I2RS >>>> agent "I want to set this instance to these values, but for all the th= ings I >>>> don't specify, use this template over here to determine what values to= set." >>>> This clearly has power. Equally clearly, it can be done at the client >>>> rather than at the agent. >>>> >>> >>> Seems like i abused the term "template". I.e it seems to me that would >>> fall under >>> " Default values MUST be possible to specify" - which is described in t= he wiki. >>> Shouldnt this be a model problem? >>> I will fix the wiki entry and remove it from that sub-section. >>> >>> On the OO class/instances: >>> The motivation is to be able to describe "set blah to RIB instance foo"= . The >>> concept for abstracting a "factory" which is essentially a "class" vs >>> an "instance" of >>> that class seems to belong to the model. >>> >>> >>> cheers, >>> jamal >>> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > From nobody Wed May 14 09:11:03 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37CB1A0301; Wed, 14 May 2014 08:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VU5QMhiawguy; Wed, 14 May 2014 08:35:35 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 05DBB1A02EA; Wed, 14 May 2014 08:35:09 -0700 (PDT) Received: from [172.21.2.104] (unknown [74.174.42.172]) by lucidvision.com (Postfix) with ESMTP id 36EA727A804A; Wed, 14 May 2014 11:34:57 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_DCB21DB4-C1C1-4A0C-A5DB-944B75C0B91B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Thomas Nadeau In-Reply-To: Date: Wed, 14 May 2014 11:34:51 -0400 Message-Id: References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> To: Jamal Hadi Salim X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/forces/zD-WHDAJKBsMy97BK3unGQWa-eY X-Mailman-Approved-At: Wed, 14 May 2014 09:11:01 -0700 Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Crabbe Edward , Andy Bierman , Dean Bogdanovic , Jeffrey Haas , "forces@ietf.org" Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 15:35:36 -0000 --Apple-Mail=_DCB21DB4-C1C1-4A0C-A5DB-944B75C0B91B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Maybe. I think that was the point though. Operationally you = specify these things, so as long as you can specify them we are good.=20 --Tom > Ok, I think i get then what Joel was saying. Is this then an > implementation issue? >=20 > cheers, > jamal >=20 > On Wed, May 14, 2014 at 11:18 AM, Thomas Nadeau = wrote: >>=20 >> Its not just default values; its more like a set of = preconfigured values for a set of objects. >>=20 >> --Tom >>=20 >>=20 >> On May 14, 2014:10:28 AM, at 10:28 AM, Joel M. Halpern = wrote: >>=20 >>> (Alia, correct me if I mis-represent this concept.) >>>=20 >>> No, temnplating is not just "Default values must be possible to = specify." >>>=20 >>> An example is that you might have a scheduling structure. it has a = set of defaults which create a specific scheduling discipling. >>> The Client can create a scheduling instance, and can over-ride any = and all of those defaults. >>> So far, that is just modeling with defaults. >>>=20 >>> The idea with templates is that the Client could also say "For all = the values I don't specify, use the WFQ template" or the EF template, or = ... If the client does that, the agent would treat the values from that = template which are specified in the template and are not specified in = the request from the controller as if they had been specified by the = controller, rather than using the base defaults. >>>=20 >>> Coupled with this, some mechanism would provide these templates. = The power here is that there might be different templates for the "EF = Scheduling template" on different boxes to reflect how each box should = be configured to achieve the policy goal. >>>=20 >>> Conversely, clearly, all of this data can be on the client and the = client can do the inclusion. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: >>>> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern = wrote: >>>>> Templating is described in the archtiecture document. >>>>> However, as I said when i presented the material, this is a topic = on which >>>>> the authors disagree. >>>>> I personally do not think it should be a protocol behavior, and = therefore do >>>>> not see it as something the model needs to represent. >>>>>=20 >>>>> The basic idea of templating is to allow the I2RS client to say to = the I2RS >>>>> agent "I want to set this instance to these values, but for all = the things I >>>>> don't specify, use this template over here to determine what = values to set." >>>>> This clearly has power. Equally clearly, it can be done at the = client >>>>> rather than at the agent. >>>>>=20 >>>>=20 >>>> Seems like i abused the term "template". I.e it seems to me that = would >>>> fall under >>>> " Default values MUST be possible to specify" - which is described = in the wiki. >>>> Shouldnt this be a model problem? >>>> I will fix the wiki entry and remove it from that sub-section. >>>>=20 >>>> On the OO class/instances: >>>> The motivation is to be able to describe "set blah to RIB instance = foo". The >>>> concept for abstracting a "factory" which is essentially a "class" = vs >>>> an "instance" of >>>> that class seems to belong to the model. >>>>=20 >>>>=20 >>>> cheers, >>>> jamal >>>>=20 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_DCB21DB4-C1C1-4A0C-A5DB-944B75C0B91B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTc40bAAoJEPcO+I7eiUJZlGgP/ReMj6wRvicbf2Sf0Fav3iQz q7JPfSu75FU+hqXUcC7q5If6JA2EhCR2Ekayf+bK36pv3gMmxvPwfwcTgL7b+C7T KCs7tn3giWEALGpqOwP9QkjHnwa6Z/0pUvb48oi6/+hYyeirLcLd4K4reVuoLCyw /XqaqwJ6Q+L5ZH65HjSQhICjzmeyBC0SMCMn1z2H7fT0wmHjBFAExdc8XyTkw1/e nUG/L4XECdER58orLhzJ3BmH0BNHVQX5Mw5ycILHmMi3ClCEO+dm3VCuUZe+FQqx fqWAGGpnzDBTrOuaJEKpZkTAd/ZO5zxToTTcRQeZyDyXdd/boFoVNyg8KaShP13E 9nfqMIF396NPoer8Sa3PHofiFX0XXr2NEergel00t3At0zfAK59atdD0p7QDZ29p 2H3YzO/V61jxeV4VXpBrAi2UXL3O4OHfij2XsJVq1NLJ/q3QlBLT7lf0BHuIrfdc 70uI50WM2ARpjxq3pd2JSt9OpKpD+B2mnykN9NOuR/wkVJ5Cx/vQ11axW5h6icqO r9gsxgtJ4KlivzU01JIYlz0P9j2t7ZjCl2Qcv4lIGMQF+IhRe7PLdHJnl97VhIe3 1H//v5/6VcLc/bpMr8tIpIjqkJeFjUpMUR6ancebFVeIsLVZHUiVW65tPZtCg5NO +Ke1zik8eDmyDR6RXKDs =DU9J -----END PGP SIGNATURE----- --Apple-Mail=_DCB21DB4-C1C1-4A0C-A5DB-944B75C0B91B-- From nobody Wed May 14 09:28:56 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1371A02D5; Wed, 14 May 2014 09:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yee0inWnzQfO; Wed, 14 May 2014 09:28:54 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id E848B1A00D5; Wed, 14 May 2014 09:28:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 7041C3E1AFC; Wed, 14 May 2014 09:28:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-10.clppva.east.verizon.net [70.106.135.10]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E017B3E1AFB; Wed, 14 May 2014 09:28:45 -0700 (PDT) Message-ID: <537399BC.4080008@joelhalpern.com> Date: Wed, 14 May 2014 12:28:44 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jamal Hadi Salim , Thomas Nadeau References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/forces/daqxCCoWmBhMnjaB6Gq_OGm_vng Cc: "i2rs@ietf.org" , Crabbe Edward , Andy Bierman , Dean Bogdanovic , Jeffrey Haas , "forces@ietf.org" Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 16:28:55 -0000 I wish it were just an implementation issue. If we are going to support this in the protocol then: 1) We need a mechanism explicitly in the protocol to say "use this template". 2) We need to include templates in the set of things we model. Yours, Joel On 5/14/14, 11:29 AM, Jamal Hadi Salim wrote: > Ok, I think i get then what Joel was saying. Is this then an > implementation issue? > > cheers, > jamal > > On Wed, May 14, 2014 at 11:18 AM, Thomas Nadeau wrote: >> >> Its not just default values; its more like a set of preconfigured values for a set of objects. >> >> --Tom >> >> >> On May 14, 2014:10:28 AM, at 10:28 AM, Joel M. Halpern wrote: >> >>> (Alia, correct me if I mis-represent this concept.) >>> >>> No, temnplating is not just "Default values must be possible to specify." >>> >>> An example is that you might have a scheduling structure. it has a set of defaults which create a specific scheduling discipling. >>> The Client can create a scheduling instance, and can over-ride any and all of those defaults. >>> So far, that is just modeling with defaults. >>> >>> The idea with templates is that the Client could also say "For all the values I don't specify, use the WFQ template" or the EF template, or ... If the client does that, the agent would treat the values from that template which are specified in the template and are not specified in the request from the controller as if they had been specified by the controller, rather than using the base defaults. >>> >>> Coupled with this, some mechanism would provide these templates. The power here is that there might be different templates for the "EF Scheduling template" on different boxes to reflect how each box should be configured to achieve the policy goal. >>> >>> Conversely, clearly, all of this data can be on the client and the client can do the inclusion. >>> >>> Yours, >>> Joel >>> >>> On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: >>>> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern wrote: >>>>> Templating is described in the archtiecture document. >>>>> However, as I said when i presented the material, this is a topic on which >>>>> the authors disagree. >>>>> I personally do not think it should be a protocol behavior, and therefore do >>>>> not see it as something the model needs to represent. >>>>> >>>>> The basic idea of templating is to allow the I2RS client to say to the I2RS >>>>> agent "I want to set this instance to these values, but for all the things I >>>>> don't specify, use this template over here to determine what values to set." >>>>> This clearly has power. Equally clearly, it can be done at the client >>>>> rather than at the agent. >>>>> >>>> >>>> Seems like i abused the term "template". I.e it seems to me that would >>>> fall under >>>> " Default values MUST be possible to specify" - which is described in the wiki. >>>> Shouldnt this be a model problem? >>>> I will fix the wiki entry and remove it from that sub-section. >>>> >>>> On the OO class/instances: >>>> The motivation is to be able to describe "set blah to RIB instance foo". The >>>> concept for abstracting a "factory" which is essentially a "class" vs >>>> an "instance" of >>>> that class seems to belong to the model. >>>> >>>> >>>> cheers, >>>> jamal >>>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> > From nobody Wed May 14 09:33:22 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29D41A0133; Wed, 14 May 2014 09:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgS_lfEpNJ4U; Wed, 14 May 2014 09:33:18 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2061D1A00D5; Wed, 14 May 2014 09:33:18 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6A8C6C26A; Wed, 14 May 2014 12:33:11 -0400 (EDT) Date: Wed, 14 May 2014 12:33:11 -0400 From: Jeffrey Haas To: "Joel M. Halpern" Message-ID: <20140514163311.GB17907@pfrc> References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> <537399BC.4080008@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <537399BC.4080008@joelhalpern.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/forces/HGRm93p2Kt4Zhj1EvCAGVNGxlQk Cc: Thomas Nadeau , Crabbe Edward , "i2rs@ietf.org" , Dean Bogdanovic , Andy Bierman , Jeffrey Haas , "forces@ietf.org" Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 16:33:19 -0000 On Wed, May 14, 2014 at 12:28:44PM -0400, Joel M. Halpern wrote: > I wish it were just an implementation issue. > If we are going to support this in the protocol then: > 1) We need a mechanism explicitly in the protocol to say "use this > template". > 2) We need to include templates in the set of things we model. +1 One of the cases in the pending architecture doc refresh (don't recall if it's in the existing version) is effectively "copy constructor" behavior for templates. If we had the equivalent of configured state that was scoped to not commit (yes, obviously ugly but potentially another one of those side data stores we have been talking about), then you have identified objects that are "committed" somewhere (not impacting running state) that can be referenced for such a copy constructor. Effectively, a form of template. -- Jeff From nobody Wed May 14 12:30:05 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B591A1A02B5; Wed, 14 May 2014 12:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fA-h1yL7oSWC; Wed, 14 May 2014 12:30:01 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE411A00DD; Wed, 14 May 2014 12:30:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E7CCC3E277D; Wed, 14 May 2014 12:29:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-10.clppva.east.verizon.net [70.106.135.10]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 88F5D3E26D3; Wed, 14 May 2014 12:29:53 -0700 (PDT) Message-ID: <5373C42F.9040407@joelhalpern.com> Date: Wed, 14 May 2014 15:29:51 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jeffrey Haas References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> <537399BC.4080008@joelhalpern.com> <20140514163311.GB17907@pfrc> In-Reply-To: <20140514163311.GB17907@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/forces/fPcYQ3Jinwcb9IqiQxJpAx5fbF8 Cc: Thomas Nadeau , Crabbe Edward , Andy Bierman , Dean Bogdanovic , "i2rs@ietf.org" , "forces@ietf.org" Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 19:30:02 -0000 So, having gone down this rabiit hole, let me explain my primary objection to this feature. The idea of the feature is that the I2RS client does not ahve to set up these templates, but simply uses them. And that by having different templates on different devices it can get the "right result" in different places. Which means that the client does not actually know what its request is going to do. the template may or may not actually do what it wants, because the client did not establish the template. For CLI operation, this kind of template operation seems very useful. For automated operation, I am concerned by the loss of information at the client. Yours, Joel On 5/14/14, 12:33 PM, Jeffrey Haas wrote: > On Wed, May 14, 2014 at 12:28:44PM -0400, Joel M. Halpern wrote: >> I wish it were just an implementation issue. >> If we are going to support this in the protocol then: >> 1) We need a mechanism explicitly in the protocol to say "use this >> template". >> 2) We need to include templates in the set of things we model. > > +1 > > One of the cases in the pending architecture doc refresh (don't recall if > it's in the existing version) is effectively "copy constructor" behavior for > templates. > > If we had the equivalent of configured state that was scoped to not commit > (yes, obviously ugly but potentially another one of those side data stores > we have been talking about), then you have identified objects that are > "committed" somewhere (not impacting running state) that can be referenced > for such a copy constructor. Effectively, a form of template. > > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed May 14 13:08:57 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD091A017A; Wed, 14 May 2014 12:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WC2qdoj35ZUa; Wed, 14 May 2014 12:24:10 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id AB7D61A0157; Wed, 14 May 2014 12:24:10 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB428.namprd05.prod.outlook.com (10.141.74.15) with Microsoft SMTP Server (TLS) id 15.0.939.12; Wed, 14 May 2014 19:24:02 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.51]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.51]) with mapi id 15.00.0944.000; Wed, 14 May 2014 19:24:01 +0000 From: Kent Watsen To: "Joel M. Halpern" , Jamal Hadi Salim Thread-Topic: [i2rs] Update to Wiki (ForCES for I2RS) Thread-Index: AQHPahBnjoa7vUfkeEGsG/dJCztYz5s9AdMAgAJUOICAAESbAIAAdRyAgAAVVwCAAAh1AIAAD2SA Date: Wed, 14 May 2014 19:24:01 +0000 Message-ID: References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> In-Reply-To: <53737DAA.1040809@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.13] x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(979002)(6009001)(428001)(24454002)(479174003)(377454003)(51704005)(189002)(199002)(21056001)(46102001)(77982001)(85852003)(83072002)(99286001)(15975445006)(76482001)(2656002)(80022001)(101416001)(76176999)(66066001)(99396002)(15202345003)(79102001)(86362001)(83506001)(19580395003)(31966008)(87936001)(74502001)(54356999)(74662001)(20776003)(64706001)(83322001)(81542001)(92566001)(92726001)(50986999)(81342001)(4396001)(36756003)(19580405001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB428; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: <67B33AB4A8DF164DAFC0D188FB037A55@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/forces/KLarpIOIgEo1PrI8Zer3d74YlQ4 X-Mailman-Approved-At: Wed, 14 May 2014 13:08:54 -0700 Cc: "i2rs@ietf.org" , Edward Crabbe , Andy Bierman , Dean Bogdanovic , Jeffrey Haas , "forces@ietf.org" Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 19:24:13 -0000 Joel's "templates" sound like apply-groups in Junos: http://www.juniper.net/techpubs/en_US/junos13.3/topics/example/routing-matr ix-tx-matrix-plus-using-configuration-groups-for-components-solutions.html K. On 5/14/14, 10:28 AM, "Joel M. Halpern" wrote: >(Alia, correct me if I mis-represent this concept.) > >No, temnplating is not just "Default values must be possible to specify." > >An example is that you might have a scheduling structure. it has a set >of defaults which create a specific scheduling discipling. >The Client can create a scheduling instance, and can over-ride any and >all of those defaults. >So far, that is just modeling with defaults. > >The idea with templates is that the Client could also say "For all the >values I don't specify, use the WFQ template" or the EF template, or ... > If the client does that, the agent would treat the values from that >template which are specified in the template and are not specified in >the request from the controller as if they had been specified by the >controller, rather than using the base defaults. > >Coupled with this, some mechanism would provide these templates. The >power here is that there might be different templates for the "EF >Scheduling template" on different boxes to reflect how each box should >be configured to achieve the policy goal. > >Conversely, clearly, all of this data can be on the client and the >client can do the inclusion. > >Yours, >Joel > >On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: >> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern >>wrote: >>> Templating is described in the archtiecture document. >>> However, as I said when i presented the material, this is a topic on >>>which >>> the authors disagree. >>> I personally do not think it should be a protocol behavior, and >>>therefore do >>> not see it as something the model needs to represent. >>> >>> The basic idea of templating is to allow the I2RS client to say to the >>>I2RS >>> agent "I want to set this instance to these values, but for all the >>>things I >>> don't specify, use this template over here to determine what values to >>>set." >>> This clearly has power. Equally clearly, it can be done at the client >>> rather than at the agent. >>> >> >> Seems like i abused the term "template". I.e it seems to me that would >> fall under >> " Default values MUST be possible to specify" - which is described in >>the wiki. >> Shouldnt this be a model problem? >> I will fix the wiki entry and remove it from that sub-section. >> >> On the OO class/instances: >> The motivation is to be able to describe "set blah to RIB instance >>foo". The >> concept for abstracting a "factory" which is essentially a "class" vs >> an "instance" of >> that class seems to belong to the model. >> >> >> cheers, >> jamal >> > >_______________________________________________ >i2rs mailing list >i2rs@ietf.org >https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed May 14 13:47:35 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741311A01DD; Wed, 14 May 2014 13:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_y_NT2bHx5I; Wed, 14 May 2014 13:47:29 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id E6D5A1A0129; Wed, 14 May 2014 13:47:28 -0700 (PDT) Received: from [10.4.188.39] (unknown [166.205.66.4]) by lucidvision.com (Postfix) with ESMTP id 9893127A8CE9; Wed, 14 May 2014 16:47:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (11D201) In-Reply-To: Date: Wed, 14 May 2014 16:47:20 -0400 Content-Transfer-Encoding: 7bit Message-Id: <56C79F88-092E-4904-B58D-AD096E0BE993@lucidvision.com> References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> To: Kent Watsen Archived-At: http://mailarchive.ietf.org/arch/msg/forces/gMod5suPkCrQWdRU4w9EgsRqTfg Cc: "i2rs@ietf.org" , "forces@ietf.org" , Edward Crabbe , Dean Bogdanovic , Andy Bierman , Jeffrey Haas , "Joel M. Halpern" Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 20:47:33 -0000 Yep. Tom > On May 14, 2014, at 3:24 PM, Kent Watsen wrote: > > > > Joel's "templates" sound like apply-groups in Junos: > > http://www.juniper.net/techpubs/en_US/junos13.3/topics/example/routing-matr > ix-tx-matrix-plus-using-configuration-groups-for-components-solutions.html > > K. > > > >> On 5/14/14, 10:28 AM, "Joel M. Halpern" wrote: >> >> (Alia, correct me if I mis-represent this concept.) >> >> No, temnplating is not just "Default values must be possible to specify." >> >> An example is that you might have a scheduling structure. it has a set >> of defaults which create a specific scheduling discipling. >> The Client can create a scheduling instance, and can over-ride any and >> all of those defaults. >> So far, that is just modeling with defaults. >> >> The idea with templates is that the Client could also say "For all the >> values I don't specify, use the WFQ template" or the EF template, or ... >> If the client does that, the agent would treat the values from that >> template which are specified in the template and are not specified in >> the request from the controller as if they had been specified by the >> controller, rather than using the base defaults. >> >> Coupled with this, some mechanism would provide these templates. The >> power here is that there might be different templates for the "EF >> Scheduling template" on different boxes to reflect how each box should >> be configured to achieve the policy goal. >> >> Conversely, clearly, all of this data can be on the client and the >> client can do the inclusion. >> >> Yours, >> Joel >> >>> On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: >>> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern >>> wrote: >>>> Templating is described in the archtiecture document. >>>> However, as I said when i presented the material, this is a topic on >>>> which >>>> the authors disagree. >>>> I personally do not think it should be a protocol behavior, and >>>> therefore do >>>> not see it as something the model needs to represent. >>>> >>>> The basic idea of templating is to allow the I2RS client to say to the >>>> I2RS >>>> agent "I want to set this instance to these values, but for all the >>>> things I >>>> don't specify, use this template over here to determine what values to >>>> set." >>>> This clearly has power. Equally clearly, it can be done at the client >>>> rather than at the agent. >>> >>> Seems like i abused the term "template". I.e it seems to me that would >>> fall under >>> " Default values MUST be possible to specify" - which is described in >>> the wiki. >>> Shouldnt this be a model problem? >>> I will fix the wiki entry and remove it from that sub-section. >>> >>> On the OO class/instances: >>> The motivation is to be able to describe "set blah to RIB instance >>> foo". The >>> concept for abstracting a "factory" which is essentially a "class" vs >>> an "instance" of >>> that class seems to belong to the model. >>> >>> >>> cheers, >>> jamal >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed May 14 15:54:46 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA79F1A031D for ; Wed, 14 May 2014 15:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1w4YSX9ERmu for ; Wed, 14 May 2014 15:54:44 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D301A0334 for ; Wed, 14 May 2014 15:54:43 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id sa20so305101veb.41 for ; Wed, 14 May 2014 15:54:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UbpK8Nrsj4CraHasq7z0e2eY+9r8ppcp62xmd6+1i0E=; b=MN7eJv2tSfGkx91WTayVyeXi+87GAjhc3ttV7w4JP2raRI8PNBTXW9rlefuJd8Jnn6 0FBBhlh1FTHUKx9Pk6BsO2AQ59EPljm4Y5Qt2uZKfl5w3VDCyRWUkTz6b3v8jswhoLsE kioZ2j/aUBRBRHzLWPIXA9icojjX6OcMTS90dstdnJx9iET1zTIspF0+RH6jkduY5EA1 2PXoSdG64KNlwODACe+axWlwC9DhJC1LMI8jYHi/GAEq4Rcg1vIhYrzQen4cfFKXMSsF kTJVql/nwSxmlvEtQbn6t8PbhXEya0iOmmaiuZ793fy4WgZZAv5k/SpdyoEX7Tt1tPCU MKyQ== X-Gm-Message-State: ALoCoQl+HPQ7NuMdT+K39FHhcKCHz1Cl6OItLNMJADY6UrUgaySupHQE+eVVuocHOLEUR+zl05gA X-Received: by 10.58.126.4 with SMTP id mu4mr5334247veb.0.1400108076057; Wed, 14 May 2014 15:54:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.201.164 with HTTP; Wed, 14 May 2014 15:54:15 -0700 (PDT) In-Reply-To: <5373C42F.9040407@joelhalpern.com> References: <20140514013737.GB13387@pfrc> <20140514054310.GA90970@elstar.jacobs.jacobs-university.de> <537364AB.5040702@joelhalpern.com> <53737DAA.1040809@joelhalpern.com> <537399BC.4080008@joelhalpern.com> <20140514163311.GB17907@pfrc> <5373C42F.9040407@joelhalpern.com> From: Jamal Hadi Salim Date: Wed, 14 May 2014 18:54:15 -0400 Message-ID: To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/_L_e_Dr4wBNI7qM-jtuqrLM6nQE Cc: Thomas Nadeau , Crabbe Edward , "i2rs@ietf.org" , Dean Bogdanovic , Andy Bierman , Jeffrey Haas , "forces@ietf.org" Subject: Re: [forces] [i2rs] Update to Wiki (ForCES for I2RS) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 22:54:44 -0000 On Wed, May 14, 2014 at 3:29 PM, Joel M. Halpern wrote: > For CLI operation, this kind of template operation seems very useful. > For automated operation, I am concerned by the loss of information at the > client. I am still struggling on why this is not "implementation specific". ex: the client should be able to pick a template specified (through some auxillary method), datafill whatever params needed and pass via the protocol to the agent. Is there is a good reason it has to be the agent that resolves what the template is? cheers, jamal From nobody Tue May 20 10:59:06 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5676E1A0280; Tue, 20 May 2014 10:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEA_BIZImZv5; Tue, 20 May 2014 10:59:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDA21A0090; Tue, 20 May 2014 10:59:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140520175901.18319.47060.idtracker@ietfa.amsl.com> Date: Tue, 20 May 2014 10:59:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/d6CwCNZEJn-ek2E0WwH6noiJxmI Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-model-extension-02.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 17:59:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : ForCES Model Extension Author : Evangelos Haleplidis Filename : draft-ietf-forces-model-extension-02.txt Pages : 28 Date : 2014-05-20 Abstract: Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC5812 has defined the ForCES Model provides a formal way to represent the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. RFC5812 has been around for two years and experience in its use has shown room for small extensions without a need to alter the protocol while retaining backward compatibility with older xml libraries. This document extends the model to allow complex datatypes for metadata, optional default values for datatypes, optional access types for structures and fixes an issue with LFB inheritance. The document also introduces two new features a new event condition BecomesEqualTo and LFB properties. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-model-extension/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-model-extension-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-forces-model-extension-02 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 nobody Mon May 26 06:36:54 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979281A0159 for ; Mon, 26 May 2014 06:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbxyO3IkNQhl for ; Mon, 26 May 2014 06:36:49 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4D01A0157 for ; Mon, 26 May 2014 06:36:49 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id pa12so9186870veb.4 for ; Mon, 26 May 2014 06:36:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9z4H0HYr4ojzcOTdpbjGwldtWM0NEA97kkpf4NVqlqQ=; b=nMWFX4RRY3gJ462azylx3LV1m2U9COZnsw0n6176rqlXX2VA9cszxfXBVgrbxs27Yd HpkRbNQ1TFvuBf6U/OtDAd19U4nlKHh8MEcSOruaF7wloe+YOKisdcXw7pwTylUIMZCr 6IKmPF8vahHGPKMfFxDKJLlZwdpCrkmmSJazOvxvdWwSStDkHIC3sIiNRFfnShLi5KtM lcQJhep3itmqvT1BtdI7xGx1IDAo+pYVBHf1s5LWjOgNJyLRpyAYxPMCZnT0rHWlcRw8 u6AIeKPacbrmwGwi9VFtwRUl9UNPWTWlfxVakIEyMt6+5Y/df6Ob9IDtLlYChFDNXOjA FWfw== X-Gm-Message-State: ALoCoQnZ5boP11HXrYOc+i1V5SdxIeUTd2azG9v2p9o2lYWTyGOzRI1zMLeq8iPVEoZTwEMVRp/S X-Received: by 10.220.133.197 with SMTP id g5mr21631071vct.20.1401111406381; Mon, 26 May 2014 06:36:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.244.66 with HTTP; Mon, 26 May 2014 06:36:26 -0700 (PDT) In-Reply-To: <20140520175901.18319.47060.idtracker@ietfa.amsl.com> References: <20140520175901.18319.47060.idtracker@ietfa.amsl.com> From: Jamal Hadi Salim Date: Mon, 26 May 2014 09:36:26 -0400 Message-ID: To: Evangelos Haleplidis Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/MZ-AN33Nz5g_aWVnHvfl73Z_YyQ Cc: "forces@ietf.org" Subject: Re: [forces] I-D Action: draft-ietf-forces-model-extension-02.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 13:36:51 -0000 Evangelos, My main comment is in regards to the examples: If you could add some more flesh around them, it will make the doc more readable. Example, between figure 8 and 9, if you could have a sentence or two to describe figure 9. I havent looked closely at details but i think this document is ready for WG last call... cheers, jamal On Tue, May 20, 2014 at 1:59 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. > > Title : ForCES Model Extension > Author : Evangelos Haleplidis > Filename : draft-ietf-forces-model-extension-02.txt > Pages : 28 > Date : 2014-05-20 > > Abstract: > Forwarding and Control Element Separation (ForCES) defines an > architectural framework and associated protocols to standardize > information exchange between the control plane and the forwarding > plane in a ForCES Network Element (ForCES NE). RFC5812 has defined > the ForCES Model provides a formal way to represent the capabilities, > state, and configuration of forwarding elements within the context of > the ForCES protocol, so that control elements (CEs) can control the > FEs accordingly. More specifically, the model describes the logical > functions that are present in an FE, what capabilities these > functions support, and how these functions are or can be > interconnected. > > RFC5812 has been around for two years and experience in its use has > shown room for small extensions without a need to alter the protocol > while retaining backward compatibility with older xml libraries. > This document extends the model to allow complex datatypes for > metadata, optional default values for datatypes, optional access > types for structures and fixes an issue with LFB inheritance. The > document also introduces two new features a new event condition > BecomesEqualTo and LFB properties. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-forces-model-extension/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-forces-model-extension-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-forces-model-extension-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon May 26 06:41:08 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44791A0157 for ; Mon, 26 May 2014 06:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vlfka3t1rQnO for ; Mon, 26 May 2014 06:41:04 -0700 (PDT) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826D01A0154 for ; Mon, 26 May 2014 06:41:04 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lf12so9243971vcb.29 for ; Mon, 26 May 2014 06:41:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=RlPtDmAoOZEyHu3QyIJUXivIWR1dE1GknLiNB5uDv0M=; b=DfmgpPmbS5MWRJfLdPrjvPIxT7mjur+8fjxrZzA2hiL/hux6ju8gQ5DrD/owNTDYmA gSIam0z7txFQ1tU1fO3exZXpK2zir1dYqzfqWI7J3CTY4uVtI25eJZnHhMK19PEcbbuA YI5bQe9y/nJ1VFmclpCUH5N4xhq+e6Vz7dK10++zn72rw4ws4NhBpVSSXelrxNvmEi72 gZlwZQA2Yi63QzvC+SYmqNrAGizEUNZkf7mBqzdNDWbLfuF25nvaV4KfP/S7LHnLMc5k KZIewy4y3eH9O3ZC4NO8HMwR1orYRWtvq/7D9fTN0LaSk3CcIC9+qUH2tSi8VrwZ3Xfu B2+w== X-Gm-Message-State: ALoCoQlrLcyEi4EoktitWdU8XnHcnXeQnJev7zRDQX/MeNYcEqG3iYsPHvMDw+VVpmAtIV6Slt6W X-Received: by 10.52.97.202 with SMTP id ec10mr5717734vdb.55.1401111661200; Mon, 26 May 2014 06:41:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.244.66 with HTTP; Mon, 26 May 2014 06:40:40 -0700 (PDT) From: Jamal Hadi Salim Date: Mon, 26 May 2014 09:40:40 -0400 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/KcOzNabTHOo6sSY6njKODPvfNAs Subject: [forces] WG last call: draft-ietf-forces-model-extension X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 13:41:06 -0000 Salutations, DJ and I would like to start the two week working group last call for draft-ietf-forces-model-extension. The document may be found here: http://tools.ietf.org/html/draft-ietf-forces-model-extension-02 The author is advised to try to resolve as many of the comments as possible (on the mailing list) as they come in, but not to post the new version of the draft until the wglc is closed and the comments are resolved. This working group last call will end on Monday, 7th of June. cheers, jamal