From nobody Fri Oct 10 13:31:30 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 80F401ACF8F; Fri, 10 Oct 2014 13:31:27 -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 2QA5qzJNS6_o; Fri, 10 Oct 2014 13:31:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC82A1ACFE7; Fri, 10 Oct 2014 13:31:23 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010203123.10352.94033.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 13:31:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/VpEvpRb--BN9-rxNpUAA1fT1djM Cc: forces mailing list , forces chair , RFC Editor Subject: [forces] Document Action: 'ForCES Packet Parallelization' to Experimental RFC (draft-ietf-forces-packet-parallelization-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: Fri, 10 Oct 2014 20:31:27 -0000 The IESG has approved the following document: - 'ForCES Packet Parallelization' (draft-ietf-forces-packet-parallelization-02.txt) as Experimental RFC This document is the product of the Forwarding and Control Element Separation Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-forces-packet-parallelization/ Technical Summary 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 (RFC 5810), 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. Many network devices support parallel packet processing. This document describes how ForCES can model a network device's parallelization datapath. Working Group Summary The document has had a number of iterations based on comments and discussions both in meetings and the mailing list. The LFB definitions and descriptions have been reviewed and are straightforward. We believe the working group is solidly behind this document. Document Quality At least one implementation has validated some of the features described in the document. Personnel The document shepherd is Damascene Joachimpillai The responsible Area Director is Adrian Farrel RFC Editor Note Please change all instances of "Cilc" to "Cilk" including the citation. From nobody Fri Oct 10 14:43:55 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 3A2421AD446; Fri, 10 Oct 2014 14:43:55 -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 nobR8JKWbIkO; Fri, 10 Oct 2014 14:43:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D07B71A87ED; Fri, 10 Oct 2014 14:43:53 -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.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010214353.15637.48857.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 14:43:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/mn3XOuSqSsyt4ajLOy_GVO-9LZU Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-packet-parallelization-03.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: Fri, 10 Oct 2014 21:43:55 -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 Packet Parallelization Authors : Evangelos Haleplidis Joel Halpern Filename : draft-ietf-forces-packet-parallelization-03.txt Pages : 26 Date : 2014-10-10 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 (RFC 5810), so that Control Elements (CEs) can control the Forwarding Elements (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. Many network devices support parallel packet processing. This document describes how ForCES can model a network device's parallelization datapath. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-packet-parallelization/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-packet-parallelization-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-forces-packet-parallelization-03 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 Oct 22 01:59:23 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 110C81A8AD2 for ; Wed, 22 Oct 2014 00:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.793 X-Spam-Level: X-Spam-Status: No, score=-0.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 Np5Ni0uueusj for ; Wed, 22 Oct 2014 00:07:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16AC61A897B for ; Wed, 22 Oct 2014 00:07:36 -0700 (PDT) Received: from [192.168.2.160] ([84.187.40.143]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MXZ4Q-1XajMN1EcI-00WTxl; Wed, 22 Oct 2014 09:07:05 +0200 Message-ID: <54475790.7000609@gmx.de> Date: Wed, 22 Oct 2014 09:06:56 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: draft-ietf-forces-model-extension@tools.ietf.org, forces@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:VoiaxlheJtjAeDwjyBDdCLs4aZHOLwR4JLTsTPVW6k8GyhTim/B nG/zzXinSxvXL3qTO/fFdha0cOjlusNSzhW/MgfYZVd/PyI0FjieyTsJlJWbAV6bIn9j6pu N+VmJyo3/Oiu8THvj+tCU8bcvleNRQqgLfu+lPuWC1V81oNoLdliAGD/Y4uIhmz/3VPk4di etCIckTt3EYYAzlaYNDwg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/forces/PEJvjFsEBwC2ZzD-zvGa3rOqq48 X-Mailman-Approved-At: Wed, 22 Oct 2014 01:59:21 -0700 Cc: Amanda Baber , Graham Klyne Subject: [forces] 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: Wed, 22 Oct 2014 07:07:41 -0000 Hi there. I was reviewing the namespace registration and have one question. The draft says "The changes introduced in this memo do not alter the protocol and retain backward compatibility with older LFB models." If this is the case, why is a new XML namespace even desirable? (Other than that, I'm sort of ok with the registration, but it strikes me that assigning a new namespace is a very bad idea). Best regards, Julian From nobody Wed Oct 22 01:59:24 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 6B8111A8A7F for ; Wed, 22 Oct 2014 00:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.793 X-Spam-Level: X-Spam-Status: No, score=-0.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 hwCN2IvIeqhz for ; Wed, 22 Oct 2014 00:34:16 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EEE31A0368 for ; Wed, 22 Oct 2014 00:34:16 -0700 (PDT) Received: from [192.168.2.160] ([84.187.40.143]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LjIel-1YGRUl099z-00dZbX; Wed, 22 Oct 2014 09:33:36 +0200 Message-ID: <54475DC7.4040402@gmx.de> Date: Wed, 22 Oct 2014 09:33:27 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: draft-ietf-forces-model-extension@tools.ietf.org, forces@ietf.org References: <54475790.7000609@gmx.de> In-Reply-To: <54475790.7000609@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:1hmGeBQtciLBi/dW1lNU8CC/0m8rMtg20P3dxvGXIgFwmw9f2k5 MJ950nG8wkD68m0/tdzwXNIFAK9Dv/Th6g3flUqczkXAeOgYF5k0tc72OFR3x+UXsnast0g NY9VOBYD7sEp2UIk2hzb2Qbu9WI2vwJx3bg4Er+bKUFq85JL+wKoV1EU3OqOlNrozYEcfdA ozNriuCbmJP7t8spnNkCg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/forces/hEWTT71wnYSiJv_-zWN2H22fnTM X-Mailman-Approved-At: Wed, 22 Oct 2014 01:59:21 -0700 Cc: Amanda Baber , Graham Klyne Subject: Re: [forces] 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: Wed, 22 Oct 2014 07:34:17 -0000 On 2014-10-22 09:06, Julian Reschke wrote: > Hi there. > > I was reviewing the namespace registration and have one question. > > The draft says > > "The changes introduced in this memo do not alter the protocol and > retain backward compatibility with older LFB models." > > If this is the case, why is a new XML namespace even desirable? > > (Other than that, I'm sort of ok with the registration, but it strikes > me that assigning a new namespace is a very bad idea). > > Best regards, Julian Thinking about that some more: if a new XML namespace is used, the format definitively is *not* backwards compatible anymore (every piece of software that understood the old format will have to be rewritten). Best regards, Julian From nobody Wed Oct 22 05:54: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 4E9FD1A90F3 for ; Wed, 22 Oct 2014 05:54:52 -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 kuQW-b-DRqqT for ; Wed, 22 Oct 2014 05:54:50 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462FB1A8BC4 for ; Wed, 22 Oct 2014 05:54:50 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id y10so3625457wgg.3 for ; Wed, 22 Oct 2014 05:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=8soaDj3cU3gdYlGeZIaVtJEPzMrexwxvGGVPreYPtow=; b=r84N0iyHrqkmXQazlblWfxyPuW/pSakh1GiNg8hNuGnPSHGytpyadxZJZp/KQ3InlS Z+LqVUEb97EfZybDIRfIj4NVPyIHGEwi24Tg8DYZPTm2SvTBSUo2/ow+Nbmx2xAedX2j k9GWJgJYHlWCTL3Ol4yj8Ld3zOO6jWYLEAZB+E5kA3J20tJWZ0Dipq6UI0eP1V4l9hGm 9CmdNhmDo90jdSdBNu03PouqDmwnmJYxyi7xdITW82QlDTKdqdFKGw5nmhXTdrDCgPAg hQKcW+Vynzxw9Fo/ZFAh9FJ8o7xdHafjttQcLtBZI16bFhF+NaWw/SZWcvWpDni7VL92 WxNw== X-Received: by 10.180.210.167 with SMTP id mv7mr5420100wic.15.1413982488959; Wed, 22 Oct 2014 05:54:48 -0700 (PDT) Received: from EhalepXPS (ppp079166008118.access.hol.gr. [79.166.8.118]) by mx.google.com with ESMTPSA id lp8sm1839167wic.17.2014.10.22.05.54.47 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 22 Oct 2014 05:54:48 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Julian Reschke'" , , References: <54475790.7000609@gmx.de> <54475DC7.4040402@gmx.de> In-Reply-To: <54475DC7.4040402@gmx.de> Date: Wed, 22 Oct 2014 15:54:46 +0300 Message-ID: <00e301cfedf7$5d323430$17969c90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/t1nsIJ4ebQda2Scy67x3Hx1QbdAAHmXUw Content-Language: el Archived-At: http://mailarchive.ietf.org/arch/msg/forces/CUvq2hcV6NGXX8s77Bt1aIcGhZ4 Cc: 'Amanda Baber' , 'Graham Klyne' Subject: Re: [forces] 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: Wed, 22 Oct 2014 12:54:52 -0000 Greetings Julian, I'm a little confused on why you think there is no backwards compatibility. LFB definitions that use the 1.0 namespace are valid in the 1.1 namespace. LFB definitions that use the 1.1 namespace are not always valid with the 1.0 namespace. That means that a software that understands LFBs in the 1.1 namespace can, without any change, understand older LFBs. That was the end goal. Software that understand the 1.0 namespace (even if we didn't change the namespace) will, of course, have trouble parsing the new xml if the extensions are used. This document did not change any LFB definitions developed with the 1.0 namespace. As there was no reason for that as 1.1 is backwards compatible with 1.0 The namespace is a way to distinguish the different versions and notify that in the 1.1 namespace these extensions apply. Thus, I don't understand why old software will be needed to change in order to understand the old format. For the new format, of course you'll have to change it. But for the new format you'd definitely had to update the software if you want to be compatible with the 1.1 namespace, so I don't see the issue. Is something I miss? Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces [mailto:forces-bounces@ietf.org] On Behalf Of Julian > Reschke > Sent: Wednesday, October 22, 2014 10:33 AM > To: draft-ietf-forces-model-extension@tools.ietf.org; forces@ietf.org > Cc: Amanda Baber; Graham Klyne > Subject: Re: [forces] draft-ietf-forces-model-extension > > On 2014-10-22 09:06, Julian Reschke wrote: > > Hi there. > > > > I was reviewing the namespace registration and have one question. > > > > The draft says > > > > "The changes introduced in this memo do not alter the protocol and > > retain backward compatibility with older LFB models." > > > > If this is the case, why is a new XML namespace even desirable? > > > > (Other than that, I'm sort of ok with the registration, but it > strikes > > me that assigning a new namespace is a very bad idea). > > > > Best regards, Julian > > Thinking about that some more: if a new XML namespace is used, the > format definitively is *not* backwards compatible anymore (every piece > of software that understood the old format will have to be rewritten). > > Best regards, Julian > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From nobody Wed Oct 22 07:03: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 C400E1A9109 for ; Wed, 22 Oct 2014 06:10:42 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 GSfYNyVxPxk3 for ; Wed, 22 Oct 2014 06:10:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60CFB1A9100 for ; Wed, 22 Oct 2014 06:10:40 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LvQkh-1Y6Ozr02K3-010f8e; Wed, 22 Oct 2014 15:10:32 +0200 Message-ID: <5447ACC0.80904@gmx.de> Date: Wed, 22 Oct 2014 15:10:24 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Haleplidis Evangelos , draft-ietf-forces-model-extension@tools.ietf.org, forces@ietf.org References: <54475790.7000609@gmx.de> <54475DC7.4040402@gmx.de> <00e301cfedf7$5d323430$17969c90$@com> In-Reply-To: <00e301cfedf7$5d323430$17969c90$@com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Bmw67NeVhtdbPCFcaonON10ulFNFkK9DKQHhkyXYh5JEHd0l1IR EwaqzdjczB0Wzsy3/+XN6QnemxOvsdl7Hz3rrCgU6CTCvz0y/WxG7S8cjxm9LePcAfoMwUp 0F5AWbjASTmhcJyPgVp4/5WTQVIRC/bERmeHt1kd/PKbGOV36vyQ85bc7OXi/iIeb7a2G3t CGkmFE9NruMmxhaZbBSmA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/forces/kbvPyxcGbJJqwlD1OuHht0Xam_Y X-Mailman-Approved-At: Wed, 22 Oct 2014 07:03:54 -0700 Cc: 'Amanda Baber' , 'Graham Klyne' Subject: Re: [forces] 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: Wed, 22 Oct 2014 13:10:42 -0000 On 2014-10-22 14:54, Haleplidis Evangelos wrote: > Greetings Julian, > > I'm a little confused on why you think there is no backwards compatibility. > > LFB definitions that use the 1.0 namespace are valid in the 1.1 namespace. Unless I'm missing something: no, they are not. Can you provide a 1.0 example, and show how it is valid according to the 1.1 schema? > LFB definitions that use the 1.1 namespace are not always valid with the 1.0 > namespace. They are never, because they use elements from a different namespace. > That means that a software that understands LFBs in the 1.1 namespace can, > without any change, understand older LFBs. That was the end goal. No. Unless I'm missing something it'll have to support both namespaces, thus both schemas. > Software that understand the 1.0 namespace (even if we didn't change the > namespace) will, of course, have trouble parsing the new xml if the > extensions are used. ...well, unless you have a sane extensibility model to start with. > This document did not change any LFB definitions developed with the 1.0 > namespace. As there was no reason for that as 1.1 is backwards compatible > with 1.0 > The namespace is a way to distinguish the different versions and notify that > in the 1.1 namespace these extensions apply. Changing the XML namespace name essentially means you have a new vocabulary. No existing code (unless it was buggy enough to ignore namespace declarations) will recognize elements from the new namespace. > Thus, I don't understand why old software will be needed to change in order > to understand the old format. > For the new format, of course you'll have to change it. But for the new > format you'd definitely had to update the software if you want to be > compatible with the 1.1 namespace, so I don't see the issue. > > Is something I miss? At least one of us does :-) Best regards, Julian From nobody Thu Oct 23 04:51: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 000181A8F3D for ; Thu, 23 Oct 2014 04:51:28 -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 viqXb29SQc-y for ; Thu, 23 Oct 2014 04:51:27 -0700 (PDT) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26D81A9029 for ; Thu, 23 Oct 2014 04:51:25 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id wp4so587495obc.38 for ; Thu, 23 Oct 2014 04:51:25 -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=MOMVnmKZ87Zi1joc/xzV8gxQBVpJWU7FPt8Wc1p99bE=; b=WwCeJMSJ6Vq1HTZr4Ea6lNK3pFJSrb2O7YTGKgE4lokluma4AirSsk6x170CMr51MC s9c02RaUHfE4mk+HWFPtIzBg6+jmCPgHni2zrpu1J1FolMF4ECcW3MzkvkmsQ2bWym7Y CV0QCH9AB47XsZLbwxgAFfjFyCABl0dm3kyFXsMwu9srWSurELEWfLj/b+hY55oOInn/ jXuGPVknKla7WIbyfWCC5463GrJF+7ARM5su7RDg7v7hvxMyHHz1tnGRfHpeZsRNd/S4 eHIGsmhHkAJQyrRd7WLwwXxZDVqqutrEA+fpaANhyd7MFaMyJ0v0RV95B4KPfo0PU37k kpPg== X-Gm-Message-State: ALoCoQmpxzmdFeRaaTAbIh0rK2bN9tuTBDzncPIAIfUS9fM3lRn3DvFREcMdesiczL3kohXGmbZL X-Received: by 10.182.65.105 with SMTP id w9mr1030097obs.60.1414065085192; Thu, 23 Oct 2014 04:51:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.199.7 with HTTP; Thu, 23 Oct 2014 04:51:05 -0700 (PDT) In-Reply-To: <5447ACC0.80904@gmx.de> References: <54475790.7000609@gmx.de> <54475DC7.4040402@gmx.de> <00e301cfedf7$5d323430$17969c90$@com> <5447ACC0.80904@gmx.de> From: Jamal Hadi Salim Date: Thu, 23 Oct 2014 07:51:05 -0400 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/DmrrZ9Pqooco8u5RBfm0svAofig Cc: Amanda Baber , Graham Klyne , "forces@ietf.org" , draft-ietf-forces-model-extension@tools.ietf.org Subject: Re: [forces] 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: Thu, 23 Oct 2014 11:51:29 -0000 On Wed, Oct 22, 2014 at 9:10 AM, Julian Reschke wrote: > On 2014-10-22 14:54, Haleplidis Evangelos wrote: >> >> Greetings Julian, >> >> I'm a little confused on why you think there is no backwards >> compatibility. >> >> LFB definitions that use the 1.0 namespace are valid in the 1.1 namespace. > > > Unless I'm missing something: no, they are not. > > Can you provide a 1.0 example, and show how it is valid according to the 1.1 > schema? > I am trying to understand the issue. There is no namespace version carried in the protocol. And there is no changes in the protocol encoding as the result of the new namespace. IOW, it does not affect anything from the protocol perspective. I can see a challenge with toolkits that look at the new namespace vs old. Old toolkits wont be able to understand the semantics of the new namespace. New toolkits should be able to understand the semantics of both old and new extensions - if the author chooses to. If i understood Evangelos correctly: He is saying the content inside the new namespace is basically backward compatible. If i understood you correctly, you are saying the moment you say it is version 1.1 you cant talk about the content inside and compare it with 1.0. All the new extensions introduced are optional. And correctly written s/ware will log/ignore/bailout on extensions it doesnt support. Are you suggesting we keep the version at 1.0? How does one detect there's new extensions? cheers, jamal From nobody Thu Oct 23 05:43:31 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 8B2921A9060 for ; Thu, 23 Oct 2014 05:43:28 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Aq5b3N70lUbX for ; Thu, 23 Oct 2014 05:43:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DFA91A904F for ; Thu, 23 Oct 2014 05:43:26 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LoVOE-1YJ5G203pq-00gX6U; Thu, 23 Oct 2014 14:42:44 +0200 Message-ID: <5448F7BA.7010607@gmx.de> Date: Thu, 23 Oct 2014 14:42:34 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jamal Hadi Salim References: <54475790.7000609@gmx.de> <54475DC7.4040402@gmx.de> <00e301cfedf7$5d323430$17969c90$@com> <5447ACC0.80904@gmx.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Gs/ao2DKOP5XP4LnZqkDRwDyo0AVJoHXpKhJ0hts9zsVxz2cdWK 0zqlSxOh93t4tvaDdvr6b8P1U7n0OBWTfzVIjkuUc3h53Ojjckyl5CSkCv2c/keybaozDmN NHnhrvgHA82P2kOxRrOUjIAxUg05UMJusH8YcnT2VLJCiMV1uc0cX/vNYtsg25U6jlOitLm ZcAm6AHbgDrI8TndGP3iA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/forces/Up6HYexY67aljMhUaNVwRPqOydE Cc: Amanda Baber , Graham Klyne , "forces@ietf.org" , draft-ietf-forces-model-extension@tools.ietf.org Subject: Re: [forces] 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: Thu, 23 Oct 2014 12:43:28 -0000 On 2014-10-23 13:51, Jamal Hadi Salim wrote: > On Wed, Oct 22, 2014 at 9:10 AM, Julian Reschke wrote: >> On 2014-10-22 14:54, Haleplidis Evangelos wrote: >>> >>> Greetings Julian, >>> >>> I'm a little confused on why you think there is no backwards >>> compatibility. >>> >>> LFB definitions that use the 1.0 namespace are valid in the 1.1 namespace. >> >> >> Unless I'm missing something: no, they are not. >> >> Can you provide a 1.0 example, and show how it is valid according to the 1.1 >> schema? >> > > I am trying to understand the issue. > There is no namespace version carried in the protocol. And there is no > changes in the protocol encoding as the result of the new namespace. > IOW, it does not affect anything from the protocol perspective. Now I'm very confused. The XML defined by the draft is not carried over the wire? > I can see a challenge with toolkits that look at the new namespace vs old. > Old toolkits wont be able to understand the semantics of the new namespace. Right. So this is *not* backwards compatible. A message using the 1.1 namespace will not be processable by a recipient that expects the 1.0 namespace. > New toolkits should be able to understand the semantics of both old and > new extensions - if the author chooses to. If i understood Evangelos > correctly: He is saying the content inside the new namespace is basically > backward compatible. If i understood you correctly, you are saying the > moment you say it is version 1.1 you cant talk about the content inside > and compare it with 1.0. You could, but it simply means that you need to write code that knows about both namespaces. (I understand that it's not hard to do, but it is very different from having nothing to do). > All the new extensions introduced are optional. And correctly written > s/ware will log/ignore/bailout on extensions it doesnt support. > Are you suggesting we keep the version at 1.0? If the rule for the 1.0 namespace is to ignore unknown elements then indeed it doesn't make any sense to define a new namespace. > How does one detect there's new extensions? By inspecting the element name and see whether it's known? Best regards, Julian From nobody Thu Oct 23 06:31:50 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 51D721A90C2 for ; Thu, 23 Oct 2014 06:31:49 -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 e4KoYEFeXgcX for ; Thu, 23 Oct 2014 06:31:44 -0700 (PDT) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218DF1A1A72 for ; Thu, 23 Oct 2014 06:31:44 -0700 (PDT) Received: by mail-oi0-f51.google.com with SMTP id h136so706716oig.38 for ; Thu, 23 Oct 2014 06:31:43 -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=H8R0hG7zAWsFGgqipz++6t1cUqHNxp1ISEHd6M9YXPY=; b=YRSDNPECb8jdyRsME9E1HS1+4jU8+8/IT6BKt3ZrTMk4CFm7UVgljVPKj+1Ag8pKG9 UPJ+dfSTkWFc75jhOw09Czs6mdAXY2AmpOqxeYEEuBcYu2cESBd3B8if1cqgAvPr1G23 YIjM1PGsYFPA/ThqzgISbB9FUJXuGhRTo+JWQXfbHcPy27j16D8VJP0d9mmatRh+LkEy nY+U4F4JOf+KbDDFWzA9IOXw19wcBrLS2mJJjbCQ5ljNA3nLulCXMBWoFcD996R3YYkz R6a4qaSdZoFgdMFt8ip6G+xyYxim7VoxTBPw8Ho4QrbqJgeDRMaBWl09hhbuXVYi5GNs /Xjg== X-Gm-Message-State: ALoCoQk6xYjC9o59y0Tni/VVqTgP2u9GOMqq//DzHd027p6tgDIDuWos0CszKTvRSDv05u3fG8Rx X-Received: by 10.202.67.135 with SMTP id q129mr1382939oia.75.1414071103578; Thu, 23 Oct 2014 06:31:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.199.7 with HTTP; Thu, 23 Oct 2014 06:31:23 -0700 (PDT) In-Reply-To: <5448F7BA.7010607@gmx.de> References: <54475790.7000609@gmx.de> <54475DC7.4040402@gmx.de> <00e301cfedf7$5d323430$17969c90$@com> <5447ACC0.80904@gmx.de> <5448F7BA.7010607@gmx.de> From: Jamal Hadi Salim Date: Thu, 23 Oct 2014 09:31:23 -0400 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/wIB8sC3Dr-2G-sci57OJJZXKW9Q Cc: Amanda Baber , Graham Klyne , "forces@ietf.org" , draft-ietf-forces-model-extension@tools.ietf.org Subject: Re: [forces] 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: Thu, 23 Oct 2014 13:31:49 -0000 On Thu, Oct 23, 2014 at 8:42 AM, Julian Reschke wrote: > On 2014-10-23 13:51, Jamal Hadi Salim wrote: >> >> I am trying to understand the issue. >> There is no namespace version carried in the protocol. And there is no >> changes in the protocol encoding as the result of the new namespace. >> IOW, it does not affect anything from the protocol perspective. > > > Now I'm very confused. The XML defined by the draft is not carried over the > wire? > Never. Binary encodings of what is formally described by the XML goes over the wire. We are optimizing for high performance (think updating 1M table rows using XML ;->). In essence, think of it as a modelling language. > > You could, but it simply means that you need to write code that knows about > both namespaces. (I understand that it's not hard to do, but it is very > different from having nothing to do). > So the assumption is it is *not* hard to do. >> All the new extensions introduced are optional. And correctly written >> s/ware will log/ignore/bailout on extensions it doesnt support. >> Are you suggesting we keep the version at 1.0? > > > If the rule for the 1.0 namespace is to ignore unknown elements then indeed > it doesn't make any sense to define a new namespace. > Need to think about it. >> How does one detect there's new extensions? > > > By inspecting the element name and see whether it's known? > So you suck in the XML and notice these new fields? I guess since there is no need for "discovery" across to a controller that may work. Note for LFBs (the OO classes we use to describe resources), the controller needs to ask the resource owner what versions it supports so it can address it appropriately (since the XML doesnt go on the wire). cheers, jamal > Best regards, Julian From nobody Thu Oct 23 07:05:14 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 775421A9104 for ; Thu, 23 Oct 2014 07:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 BdEbndQZJxyn for ; Thu, 23 Oct 2014 07:05:11 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 041B01A90B3 for ; Thu, 23 Oct 2014 07:05:10 -0700 (PDT) Received: from dummy.name; Thu, 23 Oct 2014 14:05:10 +0000 Message-ID: <54490B04.2000701@stevecrocker.com> Date: Thu, 23 Oct 2014 10:04:52 -0400 From: Joel User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Julian Reschke , Jamal Hadi Salim References: <54475790.7000609@gmx.de> <54475DC7.4040402@gmx.de> <00e301cfedf7$5d323430$17969c90$@com> <5447ACC0.80904@gmx.de> <5448F7BA.7010607@gmx.de> In-Reply-To: <5448F7BA.7010607@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/forces/cLyEOlj4ljdvUjt5Qj2DEz5a9dU Cc: Amanda Baber , "forces@ietf.org" , Graham Klyne , draft-ietf-forces-model-extension@tools.ietf.org Subject: Re: [forces] 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: Thu, 23 Oct 2014 14:05:12 -0000 The XML in the draft is NOT carried over the wire. It is a definition of structures which is referenced by the protocol carried over the wire. Yours, Joel On 10/23/14, 8:42 AM, Julian Reschke wrote: > On 2014-10-23 13:51, Jamal Hadi Salim wrote: >> On Wed, Oct 22, 2014 at 9:10 AM, Julian Reschke >> wrote: >>> On 2014-10-22 14:54, Haleplidis Evangelos wrote: >>>> >>>> Greetings Julian, >>>> >>>> I'm a little confused on why you think there is no backwards >>>> compatibility. >>>> >>>> LFB definitions that use the 1.0 namespace are valid in the 1.1 >>>> namespace. >>> >>> >>> Unless I'm missing something: no, they are not. >>> >>> Can you provide a 1.0 example, and show how it is valid according to >>> the 1.1 >>> schema? >>> >> >> I am trying to understand the issue. >> There is no namespace version carried in the protocol. And there is no >> changes in the protocol encoding as the result of the new namespace. >> IOW, it does not affect anything from the protocol perspective. > > Now I'm very confused. The XML defined by the draft is not carried over > the wire? > >> I can see a challenge with toolkits that look at the new namespace vs >> old. >> Old toolkits wont be able to understand the semantics of the new >> namespace. > > Right. So this is *not* backwards compatible. A message using the 1.1 > namespace will not be processable by a recipient that expects the 1.0 > namespace. > >> New toolkits should be able to understand the semantics of both old and >> new extensions - if the author chooses to. If i understood Evangelos >> correctly: He is saying the content inside the new namespace is basically >> backward compatible. If i understood you correctly, you are saying the >> moment you say it is version 1.1 you cant talk about the content inside >> and compare it with 1.0. > > You could, but it simply means that you need to write code that knows > about both namespaces. (I understand that it's not hard to do, but it is > very different from having nothing to do). > >> All the new extensions introduced are optional. And correctly written >> s/ware will log/ignore/bailout on extensions it doesnt support. >> Are you suggesting we keep the version at 1.0? > > If the rule for the 1.0 namespace is to ignore unknown elements then > indeed it doesn't make any sense to define a new namespace. > >> How does one detect there's new extensions? > > By inspecting the element name and see whether it's known? > > Best regards, Julian > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From nobody Mon Oct 27 13:00:27 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 4355D1AD3C0 for ; Mon, 27 Oct 2014 12:59:58 -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 x1qiGY1cOhDP for ; Mon, 27 Oct 2014 12:59:53 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98B01A0386 for ; Mon, 27 Oct 2014 12:59:38 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id x13so2161590wgg.17 for ; Mon, 27 Oct 2014 12:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=8PA8Hcta+7D6yaiAQ4d/UWdwTrk0xq7Z//Z7yA0Cgu4=; b=t24c0BnyuZd1wH/Nj612Z9o/1ydx/mO+PAF5wygHkOkxLGeeJiEXGis8xlyfCfasYT IZ9Stkucw4YZfRAEBSBf9lNVNG9bSfRhjxO2gqyotobtdUNipr1f0tcUOGvSRu0JFU4o ajP7fafp92DzY1O5nDO13zCLQ2d0i//Rz6HRzprvldzz3WrqujuqnmW0SLf3zBQ6TLsp 6iCzCFQg7e/VTp1VehD6kllhvEapbVxjzRtv5p/UIYTXY75V8pN9MKOG7fLB3PyfLjP7 GtYS13QJzAsq3QYFO7avC7btVvgFZ83/grxIC/4bpp8qO5vTHrNLKm/Rb0gUHp2+xcDT 0Lyg== X-Received: by 10.194.191.163 with SMTP id gz3mr4744245wjc.114.1414439977259; Mon, 27 Oct 2014 12:59:37 -0700 (PDT) Received: from EhalepXPS (ppp046177024168.access.hol.gr. [46.177.24.168]) by mx.google.com with ESMTPSA id fx2sm16681171wjb.37.2014.10.27.12.59.34 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Oct 2014 12:59:35 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Joel'" , "'Julian Reschke'" , "'Jamal Hadi Salim'" References: <54475790.7000609@gmx.de> <54475DC7.4040402@gmx.de> <00e301cfedf7$5d323430$17969c90$@com> <5447ACC0.80904@gmx.de> <5448F7BA.7010607@gmx.de> <54490B04.2000701@stevecrocker.com> In-Reply-To: <54490B04.2000701@stevecrocker.com> Date: Mon, 27 Oct 2014 21:59:31 +0200 Message-ID: <016101cff220$87c93720$975ba560$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/uyl7m3uHRmR0tSJKTqgMIwHpGxwDVJQWA Content-Language: el Archived-At: http://mailarchive.ietf.org/arch/msg/forces/nVf2zgPEvfK5aVpJH5GqLUx4XpU Cc: 'Amanda Baber' , forces@ietf.org, 'Graham Klyne' , draft-ietf-forces-model-extension@tools.ietf.org Subject: Re: [forces] 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, 27 Oct 2014 19:59:58 -0000 Greetings Julian, Apologies for the late reply. As Jamal and Joel both noted, the model does not affect the protocol at all. The change of the namespace was suggested by Adrian during his AD review (https://www.ietf.org/mail-archive/web/forces/current/msg04837.html) which I agreed to. I am more comfortable with keeping the new namespace as that will clearly specify that extensions are expected. Now, how about if we added the following text in the document. Would that address your concerns? "The extensions described in this document, are backwards compatible in terms of the operation of the ForCES protocol. In terms of the XML, any definitions that were valid under the old name space are valid under the new namespace. It is to be noted that any auxiliary tools that are processing xml definitions written under both namespaces will need to be able to understand both." Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces [mailto:forces-bounces@ietf.org] On Behalf Of Joel > Sent: Thursday, October 23, 2014 5:05 PM > To: Julian Reschke; Jamal Hadi Salim > Cc: Amanda Baber; forces@ietf.org; Graham Klyne; draft-ietf-forces- > model-extension@tools.ietf.org > Subject: Re: [forces] draft-ietf-forces-model-extension > > The XML in the draft is NOT carried over the wire. It is a definition > of structures which is referenced by the protocol carried over the > wire. > > Yours, > Joel > > On 10/23/14, 8:42 AM, Julian Reschke wrote: > > On 2014-10-23 13:51, Jamal Hadi Salim wrote: > >> On Wed, Oct 22, 2014 at 9:10 AM, Julian Reschke > >> wrote: > >>> On 2014-10-22 14:54, Haleplidis Evangelos wrote: > >>>> > >>>> Greetings Julian, > >>>> > >>>> I'm a little confused on why you think there is no backwards > >>>> compatibility. > >>>> > >>>> LFB definitions that use the 1.0 namespace are valid in the 1.1 > >>>> namespace. > >>> > >>> > >>> Unless I'm missing something: no, they are not. > >>> > >>> Can you provide a 1.0 example, and show how it is valid according > to > >>> the 1.1 schema? > >>> > >> > >> I am trying to understand the issue. > >> There is no namespace version carried in the protocol. And there is > no > >> changes in the protocol encoding as the result of the new namespace. > >> IOW, it does not affect anything from the protocol perspective. > > > > Now I'm very confused. The XML defined by the draft is not carried > over > > the wire? > > > >> I can see a challenge with toolkits that look at the new namespace > vs > >> old. > >> Old toolkits wont be able to understand the semantics of the new > >> namespace. > > > > Right. So this is *not* backwards compatible. A message using the 1.1 > > namespace will not be processable by a recipient that expects the 1.0 > > namespace. > > > >> New toolkits should be able to understand the semantics of both old > and > >> new extensions - if the author chooses to. If i understood Evangelos > >> correctly: He is saying the content inside the new namespace is > basically > >> backward compatible. If i understood you correctly, you are saying > the > >> moment you say it is version 1.1 you cant talk about the content > inside > >> and compare it with 1.0. > > > > You could, but it simply means that you need to write code that knows > > about both namespaces. (I understand that it's not hard to do, but it > is > > very different from having nothing to do). > > > >> All the new extensions introduced are optional. And correctly > written > >> s/ware will log/ignore/bailout on extensions it doesnt support. > >> Are you suggesting we keep the version at 1.0? > > > > If the rule for the 1.0 namespace is to ignore unknown elements then > > indeed it doesn't make any sense to define a new namespace. > > > >> How does one detect there's new extensions? > > > > By inspecting the element name and see whether it's known? > > > > Best regards, Julian > > > > _______________________________________________ > > forces mailing list > > forces@ietf.org > > https://www.ietf.org/mailman/listinfo/forces > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From nobody Mon Oct 27 13:06:09 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 52A3F1AD3D7 for ; Mon, 27 Oct 2014 13:05:52 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 2_hyq8Q6qCM5 for ; Mon, 27 Oct 2014 13:05:49 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C531AD3F2 for ; Mon, 27 Oct 2014 13:05:49 -0700 (PDT) Received: from [192.168.2.160] ([93.217.112.240]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lpspj-1YKweS2dvz-00fhGA; Mon, 27 Oct 2014 21:05:23 +0100 Message-ID: <544EA57F.3020906@gmx.de> Date: Mon, 27 Oct 2014 21:05:19 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Haleplidis Evangelos , 'Joel' , 'Jamal Hadi Salim' References: <54475790.7000609@gmx.de> <54475DC7.4040402@gmx.de> <00e301cfedf7$5d323430$17969c90$@com> <5447ACC0.80904@gmx.de> <5448F7BA.7010607@gmx.de> <54490B04.2000701@stevecrocker.com> <016101cff220$87c93720$975ba560$@com> In-Reply-To: <016101cff220$87c93720$975ba560$@com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:itnRH3P1fJYEiMrR+mNHjx0zaRbbUD594wHjHbe9cVITU14XryW YDt2YeL1qYodHUPpWqhPTgKHWnWbZEDIskqXvwBSy/+TOkV0pZCcz/EheFfP7Po1t6o1Iq5 dplAP7mYySB5pfHti3x3AaXJMEcVczvTnn4KIB1Hwq1N8fDo0wzfnUH6IMDVOR6lylyty80 syOBB4fEPVONQFeCx6Gqw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/forces/QTx5r-n4QesxORxhEJ0idqi5OQA Cc: 'Amanda Baber' , forces@ietf.org, 'Graham Klyne' , draft-ietf-forces-model-extension@tools.ietf.org Subject: Re: [forces] 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, 27 Oct 2014 20:05:52 -0000 On 2014-10-27 20:59, Haleplidis Evangelos wrote: > Greetings Julian, > > Apologies for the late reply. > > As Jamal and Joel both noted, the model does not affect the protocol at all. > > The change of the namespace was suggested by Adrian during his AD review > (https://www.ietf.org/mail-archive/web/forces/current/msg04837.html) which I > agreed to. I am more comfortable with keeping the new namespace as that will > clearly specify that extensions are expected. > > Now, how about if we added the following text in the document. Would that > address your concerns? > > "The extensions described in this document, are backwards compatible in > terms of the operation of the ForCES protocol. In terms of the XML, any > definitions that were valid under the old name space are valid under the new > namespace. It is to be noted that any auxiliary tools that are processing > xml definitions written under both namespaces will need to be able to > understand both." > > Regards, > Evangelos Haleplidis. Hi, that's indeed an improvement. Go ahead! Best regards, Julian From nobody Wed Oct 29 15:12:51 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 7E2B41A9123 for ; Wed, 29 Oct 2014 15:12:49 -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 uqKImLMzNSgN for ; Wed, 29 Oct 2014 15:12:47 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9980E1A9116 for ; Wed, 29 Oct 2014 15:12:47 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so2967406wiv.1 for ; Wed, 29 Oct 2014 15:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=0FHOX8lbkR6tM2H428lMSqUFpXRgltNSS3eZEDKYJ1E=; b=Pde+ovOL2E+kScAvQMCrxl/7/R3rfyC5SadhtcXzQB0CY/3dKMSGm3J2Pkae+6YrKE J1uH5K+QrR5NdU7HMCi9iaQCvBgs0kbcXYZaTFSy929mUPcUFtJWvl3xNOQHnbFiKi1O SsUb2I9pHJq3KctdXrpGIV8vaB5DfrzFL4aEZWaAhCDsf4jBAThPNpveBpsSNu844t0G Dfinu4gpiIabQNP+DZQ/LcgPmJwFe53NFdzUBuQP6W4yuZqVwsrSTCzdZTqlOPKCNoZv jP+fw7JGxoXVFRMYYuXG1PRfGvqXcvh0LSHLre/jloX9FkD67WVUzSYAWFPPHGuZPaPR ODVg== X-Received: by 10.180.108.13 with SMTP id hg13mr31413888wib.27.1414620766299; Wed, 29 Oct 2014 15:12:46 -0700 (PDT) Received: from EhalepXPS (ppp079166030106.access.hol.gr. [79.166.30.106]) by mx.google.com with ESMTPSA id 10sm6585902wjs.21.2014.10.29.15.12.44 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 29 Oct 2014 15:12:45 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Julian Reschke'" , "'Joel'" , "'Jamal Hadi Salim'" References: <54475790.7000609@gmx.de> <54475DC7.4040402@gmx.de> <00e301cfedf7$5d323430$17969c90$@com> <5447ACC0.80904@gmx.de> <5448F7BA.7010607@gmx.de> <54490B04.2000701@stevecrocker.com> <016101cff220$87c93720$975ba560$@com> <544EA57F.3020906@gmx.de> In-Reply-To: <544EA57F.3020906@gmx.de> Date: Thu, 30 Oct 2014 00:12:43 +0200 Message-ID: <018e01cff3c5$77c5c3b0$67514b10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/yIWIOVVkvgmS/R9aZI6KdUzrWigBo6DYA Content-Language: el Archived-At: http://mailarchive.ietf.org/arch/msg/forces/_G_18R43WBhT9qswNur-Opi9qEo Cc: 'Amanda Baber' , forces@ietf.org, 'Graham Klyne' , draft-ietf-forces-model-extension@tools.ietf.org Subject: Re: [forces] 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: Wed, 29 Oct 2014 22:12:49 -0000 Greetings Julian, Thanks for agreeing with the text. The text was actually a suggestion by Joel. So, just a quick question. I guess that I shouldn't update the draft as it is after RFC editor editing and into IANA hands. In order to move forward with the document, do you mind if I add the text at the AUTH48 state? Or should I ping the RFC editor (or the one holding the pen right now) to add it? Regards, Evangelos. > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, October 27, 2014 10:05 PM > To: Haleplidis Evangelos; 'Joel'; 'Jamal Hadi Salim' > Cc: 'Amanda Baber'; forces@ietf.org; 'Graham Klyne'; draft-ietf-forces- > model-extension@tools.ietf.org > Subject: Re: [forces] draft-ietf-forces-model-extension > > On 2014-10-27 20:59, Haleplidis Evangelos wrote: > > Greetings Julian, > > > > Apologies for the late reply. > > > > As Jamal and Joel both noted, the model does not affect the protocol > at all. > > > > The change of the namespace was suggested by Adrian during his AD > > review > > (https://www.ietf.org/mail-archive/web/forces/current/msg04837.html) > > which I agreed to. I am more comfortable with keeping the new > > namespace as that will clearly specify that extensions are expected. > > > > Now, how about if we added the following text in the document. Would > > that address your concerns? > > > > "The extensions described in this document, are backwards compatible > > in terms of the operation of the ForCES protocol. In terms of the > > XML, any definitions that were valid under the old name space are > > valid under the new namespace. It is to be noted that any auxiliary > > tools that are processing xml definitions written under both > > namespaces will need to be able to understand both." > > > > Regards, > > Evangelos Haleplidis. > > Hi, > > that's indeed an improvement. Go ahead! > > Best regards, Julian From nobody Wed Oct 29 15:31: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 B10BE1AC3AB for ; Wed, 29 Oct 2014 15:31: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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 K2bvx-tquLy3 for ; Wed, 29 Oct 2014 15:31:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08FE61AC3AA for ; Wed, 29 Oct 2014 15:31:01 -0700 (PDT) Received: from [192.168.178.36] ([93.217.69.104]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MQMBU-1Xe05b49Ua-00Tke5; Wed, 29 Oct 2014 23:30:00 +0100 Message-ID: <54516A5F.4050502@gmx.de> Date: Wed, 29 Oct 2014 23:29:51 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Haleplidis Evangelos , 'Joel' , 'Jamal Hadi Salim' References: <54475790.7000609@gmx.de> <54475DC7.4040402@gmx.de> <00e301cfedf7$5d323430$17969c90$@com> <5447ACC0.80904@gmx.de> <5448F7BA.7010607@gmx.de> <54490B04.2000701@stevecrocker.com> <016101cff220$87c93720$975ba560$@com> <544EA57F.3020906@gmx.de> <018e01cff3c5$77c5c3b0$67514b10$@com> In-Reply-To: <018e01cff3c5$77c5c3b0$67514b10$@com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:i9Km2lPTnYLdp0+jkLR17QSWIE9LfjDrTHpqlzFT9GX51CiCfLg X+Ro4h/oupcZb8JWvgHGze9jOmHlD1ZXC7O6K1ZLVMXvLqqYSiGRBq4q/cwdyENr0uV00CE 94NE744NfG6lvUk4LHWlV9pZ1b+clXvVPhlcTssvY8o90h6KmVuIaoAOcxVtYuNQmQwn05o ijmWXlHY3j38DT4R1Kfzw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/forces/hp76jwMk8aD1AKOPlrsQf-NLHgA Cc: 'Amanda Baber' , forces@ietf.org, 'Graham Klyne' , draft-ietf-forces-model-extension@tools.ietf.org Subject: Re: [forces] 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: Wed, 29 Oct 2014 22:31:03 -0000 On 2014-10-29 23:12, Haleplidis Evangelos wrote: > Greetings Julian, > > Thanks for agreeing with the text. The text was actually a suggestion by > Joel. > So, just a quick question. I guess that I shouldn't update the draft as it > is after RFC editor editing and into IANA hands. > In order to move forward with the document, do you mind if I add the text at > the AUTH48 state? Or should I ping the RFC editor (or the one holding the > pen right now) to add it? > > Regards, > Evangelos. Adding it in AUTH48 is fine, as long as your AD and the WG are in the loop. Best regards, Julian From nobody Thu Oct 30 04:59: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 71C2D1AD0A9 for ; Thu, 30 Oct 2014 04:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 CNo7wSlDIZtr for ; Thu, 30 Oct 2014 04:59:31 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9E01A0007 for ; Thu, 30 Oct 2014 04:59:31 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id a13so3135316igq.11 for ; Thu, 30 Oct 2014 04:59:30 -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=IaXuyVefImLcUKIWykf6LuUqlNI2OSCnEB3Yj2geheQ=; b=f4iJIcpeGCQ+16z4aU3pdsUtN/GwdnWxl25RUf3KcQI2iMudPLS+3Gkql3XCX3qG40 j5U8YT1sThv778gCcxFhWUOYyxEIt1zQ3epx9ojKkSe7e8zjB/Gaz0HXPjF8FjdP2ONV Qy6p36DA/O6Ts7MJCQ0gxsTgNI2r8o199oMPz2czRvsFzl/LFa58+GopaYJ/bFgcl6gL obxN9VKO2VBKtVzqLXwpSr2MIexewHaRVjoDgeB5wzrTYFWQK2WYliA7++01bzJKUsU7 n4uJJL8aDsC35Fkz4+J/HywtwDkXhyJh540JESAULYINfOBfxyr+V7GIjQ0pkuNm52UX IlSQ== MIME-Version: 1.0 X-Received: by 10.107.36.141 with SMTP id k135mr19634410iok.14.1414670370824; Thu, 30 Oct 2014 04:59:30 -0700 (PDT) Received: by 10.107.135.219 with HTTP; Thu, 30 Oct 2014 04:59:30 -0700 (PDT) Received: by 10.107.135.219 with HTTP; Thu, 30 Oct 2014 04:59:30 -0700 (PDT) In-Reply-To: <54516A5F.4050502@gmx.de> References: <54475790.7000609@gmx.de> <54475DC7.4040402@gmx.de> <00e301cfedf7$5d323430$17969c90$@com> <5447ACC0.80904@gmx.de> <5448F7BA.7010607@gmx.de> <54490B04.2000701@stevecrocker.com> <016101cff220$87c93720$975ba560$@com> <544EA57F.3020906@gmx.de> <018e01cff3c5$77c5c3b0$67514b10$@com> <54516A5F.4050502@gmx.de> Date: Thu, 30 Oct 2014 13:59:30 +0200 Message-ID: From: Evangelos Haleplidis To: Julian Reschke Content-Type: multipart/alternative; boundary=001a1141b5b0ed6ab60506a29cf3 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/GapodYgmSi4NsS0Rzs3diBxqMZw Cc: Amanda Baber , draft-ietf-forces-model-extension@tools.ietf.org, Graham Klyne , forces@ietf.org Subject: Re: [forces] 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: Thu, 30 Oct 2014 11:59:33 -0000 --001a1141b5b0ed6ab60506a29cf3 Content-Type: text/plain; charset=UTF-8 Greetings Julian, Great, thanks! I'll add it at the AUTH48 and cc the wg and Adrian. Regards, Evangelos Haleplidis On Oct 30, 2014 12:30 AM, "Julian Reschke" wrote: > On 2014-10-29 23:12, Haleplidis Evangelos wrote: > >> Greetings Julian, >> >> Thanks for agreeing with the text. The text was actually a suggestion by >> Joel. >> So, just a quick question. I guess that I shouldn't update the draft as it >> is after RFC editor editing and into IANA hands. >> In order to move forward with the document, do you mind if I add the text >> at >> the AUTH48 state? Or should I ping the RFC editor (or the one holding the >> pen right now) to add it? >> >> Regards, >> Evangelos. >> > > Adding it in AUTH48 is fine, as long as your AD and the WG are in the loop. > > Best regards, Julian > > --001a1141b5b0ed6ab60506a29cf3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Greetings Julian,

Great, thanks! I'll add it at the AUTH48 and cc the wg a= nd Adrian.

Regards,
Evangelos Haleplidis

On Oct 30, 2014 12:30 AM, "Julian Reschke&q= uot; <julian.reschke@gmx.de= > wrote:
On 2014-= 10-29 23:12, Haleplidis Evangelos wrote:
Greetings Julian,

Thanks for agreeing with the text. The text was actually a suggestion by Joel.
So, just a quick question. I guess that I shouldn't update the draft as= it
is after RFC editor editing and into IANA hands.
In order to move forward with the document, do you mind if I add the text a= t
the AUTH48 state? Or should I ping the RFC editor (or the one holding the pen right now) to add it?

Regards,
Evangelos.

Adding it in AUTH48 is fine, as long as your AD and the WG are in the loop.=

Best regards, Julian

--001a1141b5b0ed6ab60506a29cf3-- From nobody Thu Oct 30 10:11:01 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 442701A0AF1 for ; Thu, 30 Oct 2014 10:10:51 -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 r2IxaeJcre4x for ; Thu, 30 Oct 2014 10:10:44 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A821A1A24 for ; Thu, 30 Oct 2014 10:04:39 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so6183356wgg.4 for ; Thu, 30 Oct 2014 10:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=XKVRuTf7h0Q35JQhdcep11BrY5ZciYpHgQ22lVkZSQQ=; b=NFCw9Zuvxc/InztnwjfE2T7YZLp3ExK07CxWKp0H9vlltMNNUN41MKLGzW/xThcdXK XEzPH/5qhlHkXp28eFr7GWpv9dwNAOACpH7qwF7XkN5llHpz4BgjDJZ4KXt23dou+pSP 0p9bnPOAJWn1QRjOdQx6iVgaWOSQL1V7y9k/kRdwtQGr+PfQCLPrUSbqUWgEqDGWNir0 +4QgWdCvHcXVOSnFR6PT3I+zNtt6dEtgYg7l4gIolyZ+L68VT4nIVoAhoF/Ezo2EG5P8 Kc3oOerqPrSnnXkeJoZD8NCRiM7CQDrg0W363FdYl1YbrkTBt6UVARBCW9mMVEkMXM3M pcYA== X-Received: by 10.194.48.84 with SMTP id j20mr21744916wjn.35.1414688677570; Thu, 30 Oct 2014 10:04:37 -0700 (PDT) Received: from EhalepXPS (ppp079166038212.access.hol.gr. [79.166.38.212]) by mx.google.com with ESMTPSA id cu9sm9332835wjc.3.2014.10.30.10.04.36 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Oct 2014 10:04:36 -0700 (PDT) From: "Haleplidis Evangelos" To: Date: Thu, 30 Oct 2014 19:04:37 +0200 Message-ID: <012b01cff463$974cb4c0$c5e61e40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/yQoA4TyjQ6Id0S4ayRG1aHCcm/gCIIZnA Content-Language: el Archived-At: http://mailarchive.ietf.org/arch/msg/forces/MOQqv6F_QTYC2s_CeTF18xL95mc Subject: [forces] FW: New Version Notification for draft-khs-forces-lfb-subsidiary-management-04.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: Thu, 30 Oct 2014 17:10:51 -0000 Greetings to the list, Apologies for the late posting. We have updated the subsidiary draft. There is a lot of cleaning up on = the document to make it more clear and focused on the charter item work. Regards, Evangelos. > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, October 28, 2014 1:57 AM > To: Evangelos Haleplidis; Jamal Hadi Salim; Evangelos Haleplidis; = Jamal > Hadi Salim; Bhumip Khasnabish; Bhumip Khasnabish > Subject: New Version Notification for draft-khs-forces-lfb-subsidiary- > management-04.txt >=20 >=20 > A new version of I-D, = draft-khs-forces-lfb-subsidiary-management-04.txt > has been successfully submitted by Evangelos Haleplidis and posted to > the IETF repository. >=20 > Name: draft-khs-forces-lfb-subsidiary-management > Revision: 04 > Title: IETF ForCES Logical Function Block (LFB) Subsidiary > Management > Document date: 2014-10-27 > Group: Individual Submission > Pages: 19 > URL: = http://www.ietf.org/internet-drafts/draft-khs-forces-lfb-subsidiary-manag= ement-04.txt > Status: = https://datatracker.ietf.org/doc/draft-khs-forces-lfb-subsidiary-manageme= nt/ > Htmlized: = http://tools.ietf.org/html/draft-khs-forces-lfb-subsidiary-management-04 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-khs-forces-lfb-subsidiary-manage= ment-04 >=20 > Abstract: > Deployment experience has demonstrated the value of using the > Forwarding and Control Element Separation (ForCES) protocol to > control the Forwarding Element Manager (FEM) by creating a Logical > Functional Block (LFB) to represent its functionality, the FE > Configuration (FEC) LFB . A Control Element (CE) that controls a > Forwarding Element's (FE) resources can also manage its > configuration > via the FEC LFB. On a running FE, the CE may update the FE's > runtime > configuration via an FEC LFB e.g., by adding a new CE and its > associated IP address). Additionally, in the case where we have a > resource pool of FEs, the FEC may be used to initiate an FE into = the > Network Element cluster. This document introduces the FEC LFB, an > LFB that specifies the configuration parameters of an FE. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat From nobody Fri Oct 31 16:31:52 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 F0F131A874D; Fri, 31 Oct 2014 16:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 PYxAKE7SXa4H; Fri, 31 Oct 2014 16:31:48 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id C7F401A874A; Fri, 31 Oct 2014 16:31:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 66133181C91; Fri, 31 Oct 2014 16:30:56 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20141031233056.66133181C91@rfc-editor.org> Date: Fri, 31 Oct 2014 16:30:56 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/forces/ocnDFjLUmphJlWgBf-K254D3alE Cc: forces@ietf.org, rfc-editor@rfc-editor.org Subject: [forces] RFC 7391 on Forwarding and Control Element Separation (ForCES) Protocol Extensions 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: Fri, 31 Oct 2014 23:31:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7391 Title: Forwarding and Control Element Separation (ForCES) Protocol Extensions Author: J. Hadi Salim Status: Standards Track Stream: IETF Date: October 2014 Mailbox: hadi@mojatatu.com Pages: 23 Characters: 49481 Updates: RFC 5810, RFC 7121 I-D Tag: draft-ietf-forces-protoextension-06.txt URL: https://www.rfc-editor.org/rfc/rfc7391.txt Experience in implementing and deploying the Forwarding and Control Element Separation (ForCES) architecture has demonstrated the need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions. The ForCES protocol is extended with a table range operation and a new extension for error handling. This document updates the semantics in RFCs 5810 and 7121 to achieve that end goal. This document is a product of the Forwarding and Control Element Separation Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC