From internet-drafts@ietf.org Mon Sep 16 08:30:54 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C0011E829C; Mon, 16 Sep 2013 08:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0XWbn7t7Eug; Mon, 16 Sep 2013 08:30:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC9911E828C; Mon, 16 Sep 2013 08:30:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130916153052.14784.9991.idtracker@ietfa.amsl.com> Date: Mon, 16 Sep 2013 08:30:52 -0700 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-protoextension-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 15:30:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Forwarding and Control Element Separation= Working Group of the IETF. Title : ForCES Protocol Extensions Author(s) : Jamal Hadi Salim Filename : draft-ietf-forces-protoextension-00.txt Pages : 9 Date : 2013-09-16 Abstract: Experience in implementing and deploying ForCES architecture has demonstrated need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions. This document describes a few extensions to the ForCES Protocol Specification [RFC5810] semantics to achieve that end goal. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-protoextension There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-protoextension-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 hadi@mojatatu.com Mon Sep 16 10:52:20 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFDA11E82DB for ; Mon, 16 Sep 2013 10:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxO4lb3Usrmj for ; Mon, 16 Sep 2013 10:52:16 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id BA3D711E8135 for ; Mon, 16 Sep 2013 10:52:15 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lf11so3085474vcb.21 for ; Mon, 16 Sep 2013 10:52:13 -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 :content-type; bh=uJpRJw/o2SJuI5iyMPsBYBppNA/rhloQaXtitHGOwGc=; b=PE6j88e5h+A8jGc3rR2ao9TgABoGkXvS8x3+jh5ZOnG6ycvU9r4DIZmdijTZKNHPX+ 9nILi6OfepYNLT6GBFnncHLKp1JXPUkOXYVgfqyityaAvCVtWPKyNRL2FVJWQpGlNQ1K 6VYJbs/wpqo6BONS+OMOdlyDwdmQgPTWW2EQM2oEpDQYu4AW6THzPxPeLgRS5u/TBKbv /y7ORD4EiQbCktDcY3RDVxK+ccDxPe+honCaSak0hwC8cCgL9SxgcmKxZPdwKCeqMdhA m9a/DawIzX8r746rJ3J5XRWfwTXEk8lHDmtCstUKxRpwCOqdqQqTnF2IdNHMQTw1TKpJ xPyg== X-Gm-Message-State: ALoCoQkjKgeRtLs8bHtOVpiv2Cc/JVbOLgxBC8P9l0tiGb7zl/2xAd2N4WLRAC5AnE8fwnl6W8Zy X-Received: by 10.220.10.194 with SMTP id q2mr27740930vcq.2.1379353933290; Mon, 16 Sep 2013 10:52:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.23.33 with HTTP; Mon, 16 Sep 2013 10:51:53 -0700 (PDT) From: Jamal Hadi Salim Date: Mon, 16 Sep 2013 13:51:53 -0400 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [forces] Updated Protocol draft X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 17:52:20 -0000 Folks, A new draft has been uploaded for the protocol extensions. Its small - please read and comment. What has changed since last time? a) As agreed at the meeting this draft (and the model extension one) is adopted by the WG b) The APPEND work item did not get consensus at the meeting and has therefore been removed. c) The Bitmap work item did not get consensus at the meeting and has therefore been removed. d) The idea of a new extended Result TLV has been dropped as well. Instead we recommend to use the current RESULT TLV and make use of some of the reserved fields. It will be helpful to get any comments on the sanity of this suggestion. We are planning to implement in the next few days. #b is done for expediency because the WG has to deliver the document. We are already late. I do plan in the future to submit another draft to argue for that and other things - but for now it may be counter-productive for progress. cheers, jamal ---------- Forwarded message ---------- From: Date: Mon, Sep 16, 2013 at 11:30 AM Subject: [forces] I-D Action: draft-ietf-forces-protoextension-00.txt To: i-d-announce@ietf.org Cc: forces@ietf.org 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 Protocol Extensions Author(s) : Jamal Hadi Salim Filename : draft-ietf-forces-protoextension-00.txt Pages : 9 Date : 2013-09-16 Abstract: Experience in implementing and deploying ForCES architecture has demonstrated need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions. This document describes a few extensions to the ForCES Protocol Specification [RFC5810] semantics to achieve that end goal. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-protoextension There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-protoextension-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/ _______________________________________________ forces mailing list forces@ietf.org https://www.ietf.org/mailman/listinfo/forces From hadi@mojatatu.com Tue Sep 17 06:56:18 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E33911E823D for ; Tue, 17 Sep 2013 06:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KdwM41AdZ0n for ; Tue, 17 Sep 2013 06:56:12 -0700 (PDT) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id 266A811E8237 for ; Tue, 17 Sep 2013 06:56:12 -0700 (PDT) Received: by mail-vb0-f43.google.com with SMTP id h11so4159833vbh.30 for ; Tue, 17 Sep 2013 06:56:08 -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=usFwU68l6CrhXF1BdYJ0XJipUZ0pQ0EGwyMj7BopdUc=; b=lzDi+VWUqQkok94w+gqflEx9BL5bEv0XlL8NfLCOF8k5fHkp4wMqN5h100YjbyU4VJ aoLX/dMtZTJSq356XbhUU828X2VCfHRxtMaB1A66GZC2vYROmvhqvBbkZQj4GF6nDKkQ QOGdktxJCqGoPIQyarf19p5WLSNXSB+EHrWdx3wH9fC1zEaxBEoOR1TrftVtXFV2j9XE 6Bv11Fn/W0ZGY7LMQ9Ctqnhnml7rqtSUphDPTqVJToFsPDiQ/O0iT7JdK7AXkN4d7mJe oVmevP+53BNHsZpNR1meN2CA+XeC91iLFb1gT5QNbowjwYkYLyg3lrcD5etfjEk36hsd GoUQ== X-Gm-Message-State: ALoCoQlkuc6dkOmYns7EE3CFFFVDzNN265YAw6aYeVznSOI1AL04SCZKD6ehE9Pm0Ysdf8o9AmCm X-Received: by 10.52.34.40 with SMTP id w8mr27521140vdi.7.1379426168778; Tue, 17 Sep 2013 06:56:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.23.33 with HTTP; Tue, 17 Sep 2013 06:55:48 -0700 (PDT) In-Reply-To: <043d01ce9c38$d4470990$7cd51cb0$@olddog.co.uk> References: <02b001ce884a$a1585040$e408f0c0$@olddog.co.uk> <000001ce896e$719cc370$54d64a50$@olddog.co.uk> <005401ce91d8$cebba310$6c32e930$@com> <043d01ce9c38$d4470990$7cd51cb0$@olddog.co.uk> From: Jamal Hadi Salim Date: Tue, 17 Sep 2013 09:55:48 -0400 Message-ID: To: Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" , draft-ietf-forces-ceha.all@tools.ietf.org Subject: Re: [forces] AD Review of draft-ietf-forces-ceha X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 13:56:18 -0000 Hi, I am sorry I missed this - Evangelos reminded me while i was trying to figure out where the publication path is. My take on this is we should use new rows for each version. But we also need a new column to identify the version. IMO, that would be the best way to scale in the future if we keep adding new versions. So if folks agree we would need to ask IANA for the new version column. The reference column will continue to be identifying which RFC/docs are utilized and which are obsoleted. cheers, jamal On Sun, Aug 18, 2013 at 1:31 PM, Adrian Farrel wrote: > Hello, > >> > Section 5 needs to give clear and unambiguous instructions to the IANA. >> > It seems that the text in Section 5 is currently a placeholder for the >> > correct text. >> >> Looking on the IANA considerations I am not exactly sure how to address the >> issue. >> >> In my mind there are two possibilities. >> >> 1. Update the "Logical Functional Block (LFB) Class Names and Class >> Identifiers" https://www.iana.org/assignments/forces/forces.xml by adding >> one more column "LFB Version" after (or before) the LFB Class Name. Value of >> 1.0 for all existing LFBs and then add a new row for Version 1.1 after the >> FE Protocol Object for version 1.1. >> >> 2. Update the FEPO reference with [RFC5810] v1.0, [CEHA RFC] v.1.1. >> >> I'm more inclined to go for the first one but that would require >> restructuring of the IANA page. >> What should be the proper way forward? > > I was hoping that Jamal would know what needed to be done here. > I think you are saying that the LFB class identifier in the registry points to > XML present in the referenced document. > Thus, previously, when you saw LFB Class Identifier 2, you knew to look in RFC > 5810 for the XML for the LFB. > > Now you have confusion. Does LFB Class Identifier 2 refer to the FEPO LFB v1.0 > in RFC 5810, the FEPO LFB v1.1 in this I-D, or both? > > I can't answer that question for you! > > However, since I see the version number embedded in the XML, I am relatively > sure that this document: > - updates RFC 5810 by replacing the XML > - should be referenced alongside RFC 5810 in the registry > > Note that updating 5810 requires a little work to: > - mention it in the meta-data > - note it in the Introduction "This document updates foo by doing bah." > - explain it in a short paragraph in the introduction. > >> > Section 3.1.1 >> > >> > "CEID" is used without expansion. Although sometimes I find "CE ID" for >> example in 3.1.2. >> >> The CEID refers to a component in the FE Protocol Object. The CE ID refers >> to the ID of the CE. There were a few discrepancies but have been fixed. The >> CEID is now followed by the word "component" while the CE ID is not. Will >> that be sufficient to remove the confusion? > > It would be nice if the first usage of each expanded it into English. > > Cheers, > Adrian > From internet-drafts@ietf.org Wed Sep 25 08:53:40 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD4021F9DE1; Wed, 25 Sep 2013 08:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgprQBMPrZGE; Wed, 25 Sep 2013 08:53:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2364121F99FD; Wed, 25 Sep 2013 08:53:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130925155340.29986.32361.idtracker@ietfa.amsl.com> Date: Wed, 25 Sep 2013 08:53:40 -0700 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-model-extension-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 15:53:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Forwarding and Control Element Separation= Working Group of the IETF. Title : ForCES Model Extension Author(s) : Evangelos Haleplidis Filename : draft-ietf-forces-model-extension-00.txt Pages : 27 Date : 2013-09-25 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 and optional access types for structures. The document also introduces three new features, bitmap as a new datatype, 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-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 ehalep@gmail.com Wed Sep 25 10:22:20 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F2021F9F21 for ; Wed, 25 Sep 2013 10:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MCunfq+jSJY for ; Wed, 25 Sep 2013 10:22:20 -0700 (PDT) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DA70321F9E77 for ; Wed, 25 Sep 2013 10:22:17 -0700 (PDT) Received: by mail-ee0-f45.google.com with SMTP id c50so3350829eek.32 for ; Wed, 25 Sep 2013 10:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=g4z68eqPac0ADt01MMCOOghbRj7is36MA548lf1IpEo=; b=sQnFh8Q2SQWQ3A9X8FU+cimNbLdEXbqPgW4QBlCtC91whZ7ug1GKifn9eGwGYlgu/F rNctgJQta7piB9ZlnsC86gqPHwetWJKcRXqctkPvY4V7i+b9V7FasWHXeGJYLMauv0BF SdF5xwG8F/YVWHe1D+kXUsHjLoAnP43RsE5//rufqyO8yPsJUm0WQzVbSr9fz9byK6yM W1EX7g/dPHI2TO0yMHV41aGQQw8LJ/FHrR0utmO+FL/RcemmaFdVSPr2RBGj/XdnMinE 4TVLnbr8pA+epeBf741jrsY1sC1L9BDPM6I0V3oJyXvI4lUiiHRJsPdkx2ANI64lUVqs ijyQ== X-Received: by 10.15.45.8 with SMTP id a8mr56962527eew.1.1380129735627; Wed, 25 Sep 2013 10:22:15 -0700 (PDT) Received: from EhalepXPS (ppp079166135164.access.hol.gr. [79.166.135.164]) by mx.google.com with ESMTPSA id h52sm67769301eez.3.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 25 Sep 2013 10:22:14 -0700 (PDT) From: "Haleplidis Evangelos" To: References: <20130925155340.29986.32361.idtracker@ietfa.amsl.com> In-Reply-To: <20130925155340.29986.32361.idtracker@ietfa.amsl.com> Date: Wed, 25 Sep 2013 20:22:10 +0300 Message-ID: <00ee01ceba13$c62aed10$5280c730$@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: Ac66B2mgvkOfN4YuQLaVETUDr3teQAABp+1w Content-Language: el Subject: Re: [forces] I-D Action: draft-ietf-forces-model-extension-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 17:22:20 -0000 Greetings to the list, Just submitted the new version of the model extension. After the discussion in the Berlin meeting there are two outstanding issues to complete the draft. Namely bitmap and LFB properties. Based on the excellent meeting minutes I'll recap the discussion and point the issues. 1. LFB properties. There are two issues in regards to the LFB properties. A. Is there a need for such an LFB properties definition? I can see the need and it's useful for having these specific LFB properties and a way to retrieve such properties. Also as Joel suggested to look for which LFB properties are needed, please let me know if you require these or any other LFB properties. B. The ambiguity of path selection using the GET property. GET property /LFBClass/LFBInstance/IDx, what should it return - property IDx of the LFB or the whole struct of properties of component with ID x? A simple solution for this issue would be to explicitly define that the path data refers to the LFB instead of a component as a path flag in the path data. 2. Bitmap datatype. There is a fundamental question whether we actually need a bitmap datatype. As Joel suggested, it is possible to simulate bitmaps of size up until 64 bits by using the base datatypes. For larger sizes the alternatives are a struct of basic datatypes to reach the required bits or a table of booleans. However there is now other way to set/get a single or a set of bits without having the bitmap datatype. An additional issue arises with having to define the data packing rule of transporting the bitmap by the protocol. I would like the opinion of the working group on these issues to resolve them. I think that the LFB properties are a nice addition. Bitmap are useful but not necessary and as they can be simulated, but cannot be explicitly defined with the model. Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Wednesday, September 25, 2013 6:54 PM > To: i-d-announce@ietf.org > Cc: forces@ietf.org > Subject: [forces] I-D Action: draft-ietf-forces-model-extension-00.txt > > > 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(s) : Evangelos Haleplidis > Filename : draft-ietf-forces-model-extension-00.txt > Pages : 27 > Date : 2013-09-25 > > 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 and optional access > types for structures. The document also introduces three new > features, bitmap as a new datatype, 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-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/ > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From hadi@mojatatu.com Thu Sep 26 08:55:24 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145C521F9FB6 for ; Thu, 26 Sep 2013 08:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBIdCkqWKvEI for ; Thu, 26 Sep 2013 08:55:17 -0700 (PDT) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 47F9221F9F2D for ; Thu, 26 Sep 2013 08:55:17 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id db12so1052301veb.36 for ; Thu, 26 Sep 2013 08:55:15 -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=6XjPqK9uUJPFpAs4bB3/2x5kC3hAAv8THPqOJl3meGk=; b=dkcfJdvuS71O3m/X6uV1F8le699jHMKDiKYXbXEkcWNzpbOMOrfF/vpeyi1rOlwNuu AxvyqZq6O9gRnzHu0+pZFZJgEZiznXjWqPbwqVH1RPa39JGeTVts96TluzFkExpClo+G PGWBIbPX6dvGFZOnSB0FBXYDnP7GXGSZCduVdNaUcYK7QTB9UO25QxK0bNpaonbngLDD PjBmDlBthGDwE5HZnhTWV+BP1fdmhL1Vq1x1tZwIQqTTS50A9X+adPRjBO5xE1bUW7QX iqF14mc7VcAlODl5tEenXHRfa5QPTcfRxfNFr9Is9DNoDqSDyURUTeTpxDNK4eClq/qn Jl7w== X-Gm-Message-State: ALoCoQk8Lw48UKWQuT1hTkmjNOPD+0kVecSZAMNhZ4N5oLlBDmRhi0Xy/a+zHDXIiVq++tA2FiC8 X-Received: by 10.58.108.74 with SMTP id hi10mr1308526veb.14.1380210915552; Thu, 26 Sep 2013 08:55:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.23.33 with HTTP; Thu, 26 Sep 2013 08:54:55 -0700 (PDT) In-Reply-To: <00ee01ceba13$c62aed10$5280c730$@com> References: <20130925155340.29986.32361.idtracker@ietfa.amsl.com> <00ee01ceba13$c62aed10$5280c730$@com> From: Jamal Hadi Salim Date: Thu, 26 Sep 2013 11:54:55 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: Re: [forces] I-D Action: draft-ietf-forces-model-extension-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 15:55:24 -0000 Greetings Evangelos, Comments below: On Wed, Sep 25, 2013 at 1:22 PM, Haleplidis Evangelos wrote: > 1. LFB properties. > There are two issues in regards to the LFB properties. > A. Is there a need for such an LFB properties definition? > I can see the need and it's useful for having these specific LFB properties > and a way to retrieve such properties. > Also as Joel suggested to look for which LFB properties are needed, please > let me know if you require these or any other LFB properties. > In my implementation experience it ends up boiling down to having to implement stats for _almost every_ LFB I have come across. As you mention in the draft, in the minimal, the need is for debugability. In other words, there is a work around today. But if this is such a common need, I would argue we need it. > B. The ambiguity of path selection using the GET property. GET property > /LFBClass/LFBInstance/IDx, what should it return - property IDx of the LFB > or the whole struct of properties of component with ID x? > A simple solution for this issue would be to explicitly define that the path > data refers to the LFB instead of a component as a path flag in the path > data. > With "dont change the protocol" approach: Could we not reserve certain property ids? Actually come to think of it: Component ID 0 is not used today. Could we not have "Set/GetPropetyLFBClass/LFBInstance/0/IDx" kind of semantics to imply we are referring to the property with IDx? > 2. Bitmap datatype. > There is a fundamental question whether we actually need a bitmap datatype. > As Joel suggested, it is possible to simulate bitmaps of size up until 64 > bits by using the base datatypes. For larger sizes the alternatives are a > struct of basic datatypes to reach the required bits or a table of booleans. > However there is now other way to set/get a single or a set of bits without > having the bitmap datatype. > An additional issue arises with having to define the data packing rule of > transporting the bitmap by the protocol. > > I would like the opinion of the working group on these issues to resolve > them. I think that the LFB properties are a nice addition. Bitmap are useful > but not necessary and as they can be simulated, but cannot be explicitly > defined with the model. > To answer Joel's and your question: I think these are again commonly used types, so we may need to define them somehow. Even if it turns out elsewhere in an informational draft. One implementation approach i have found Linux uses is by defining two fields. Lets say i want to define a 32 bit map (in which i wish to specify "bits to un/set"). Then two 32 bit fields suffice. Call the first 32 bit the "selector". If you set a bit in the selector you are indicating that the bit is to be un/set. Then call the second 32 bit field the "value". As an example, is selector bit 3 is set then when value bit field 3 is set, it means I want to set bit 3. If value bit 3 is 0, it means I want to unset bit 3. Off the top of my head i cant come up with the right term for the logical function that would describe the operation between "selector" and "value"; (xor or nor seem wrong). So in the worst case where you want to communicate one bit you waste one 32 bit value compared to boolean. In the best case you are 30 times better in terms of bit-on-the wire preservation. You can use the approach for 64 bit(map) etc. I think Joel's view of bitmap is in a desire not to send all the bits one is not interested in setting, but i would argue you cant beat the above in terms of bit optimization ;-> cheers, jamal PS:- I am reading the draft and will provide more comments. From hadi@mojatatu.com Thu Sep 26 09:12:33 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CBD11E8102 for ; Thu, 26 Sep 2013 09:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFmJxIpTTfm6 for ; Thu, 26 Sep 2013 09:12:28 -0700 (PDT) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id A577F11E814F for ; Thu, 26 Sep 2013 09:11:03 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id db12so1060960veb.8 for ; Thu, 26 Sep 2013 09:11:03 -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=117nDCy/N+scI+sr7yn89QWqHgQ0AGaGsldIMro8ywg=; b=YuwvasCfv7aSyh2uKUhO/c5r96Th99MiULoqhmdIc8JkXEaQzzyAI2pv96N0ycDUN1 L7xGhC3BCrn0ITuTmcaraVOPeKD0hjJOfQ3YKyflZ1GrBfCRMxrKMVgsn48dn52y2yqE DHz+2gRQx0H1ARKW78iu53+fUAo789tXwyvzL//wie8zxdbFkVRimjdFuqIzMS+ZCwxB nCAGGi826uvqhxqjKWhDdqOmLtVeBflmReWLmCF7sPMoQ4pKF4oLRAnGkP0BJp6UobTE SVo1hg4hDS/P2JNPegTwEhBP78Tnnfm7jOPFwR4dva5wsvtSjFyabIfJbYrMSevQkATl 1TCw== X-Gm-Message-State: ALoCoQniGcHzoA2bVnHzXRBYnweEtrW0NBkhMeVWWfKKr1y2VqDvHbayRo8y1hbPwRA/uqvQ+1G6 X-Received: by 10.52.116.74 with SMTP id ju10mr1141555vdb.20.1380211863091; Thu, 26 Sep 2013 09:11:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.23.33 with HTTP; Thu, 26 Sep 2013 09:10:42 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 26 Sep 2013 12:10:42 -0400 Message-ID: To: Evangelos Haleplidis Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: [forces] Comments model extension: BecomesEqualTo event condition X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 16:12:33 -0000 This is in section 3.5 I think we discussed this but my memory fails me. Would it not be useful to instead to allow for logical OR AND filter for conditions? Then "== x" becomes [<"x+1" AND >"x-1"] I am faced with a condition where i have to specify in the xml multiple events just so i can report separately a table row has been created, updated deleted. I would have preffered, one event called table event with condition [eventCreated OR eventChanged OR eventDeleted] cheers, jamal PS: I do realise we want to keep the FE side as dumb as possible and the above adds complexity of checks if we have many event subscribers for a subset of things; but you are also adding additional state to be checked against. From hadi@mojatatu.com Thu Sep 26 09:28:36 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9784D21F9CC8 for ; Thu, 26 Sep 2013 09:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7dPKdkC+n9N for ; Thu, 26 Sep 2013 09:28:31 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id B033211E811A for ; Thu, 26 Sep 2013 09:26:58 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id cz12so1086400veb.18 for ; Thu, 26 Sep 2013 09:26:56 -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=elj7q1nDEdw0UAR8b+dTGdwz7pvZ1ZvzfdjhXyqDxcg=; b=S5B4v7SnkuYsimmc5JeVsmceB3vjY5aDKRskNsaRmSOTUsCPhJpZEv86qaT1JwHOu7 xlaHzbSl8yR+cC0qXvuQ6C+54LYIxadhA1Ktw9QWocwrY+fK2aGW8h31najr+gr1hiQX CR8CcedrnDRWJz39YC3MXlaNUTRYXATldiMsOGTBOaRuz26Rg98i5tywKkfkez1XFw7x iUXsu11DKRH2cDiSW0eZSPcju0D/nCA1uLYfaywyhFHyKKh2N/6JeUcJvHGErc5xQLe0 rFJglEUv3WNpItsfHWSSy2SlzEX0JBEgBXW2VQr5WqqAqnAfQ7RPrviHo2AfKpl2Dyea Di0g== X-Gm-Message-State: ALoCoQk0SSPkdVgLaJ/ZvUIIFNbZQ8YdNxaRFmNTyGz7B5vpxJAIKG0/Sjuooh0ruF7WjonwAl7G X-Received: by 10.52.116.74 with SMTP id ju10mr1193294vdb.20.1380212816133; Thu, 26 Sep 2013 09:26:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.23.33 with HTTP; Thu, 26 Sep 2013 09:26:35 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 26 Sep 2013 12:26:35 -0400 Message-ID: To: Evangelos Haleplidis Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: [forces] On optional ACL for structs X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 16:28:36 -0000 Giving this some thought; i think we should make the choice of ACL for the struct at the component level separate NOT override the default defined value in the struct definition. i.e We should, as we already do, allow the the children to inherit the ACL of the parent when the childs ACL is not defined but not when it is defined. Example: datatype def foobar struct { uint32 foo read only; uint 32 bar; } ..... ...... myfoobar component id 1, read-write { typeref foobar; } In such a case if i do: SET /FE/2/LFBX/InstanceY/myfoobar {1, 2} I should fail with E_READ_ONLY If i do: SET /FE/2/LFBX/InstanceY/myfoobar/bar {2} it should succeed. Otherwise you need to specify at myfoobar level what the different fields ACLs should be which could be very complex for deeply nested components. Thoughts? cheers, jamal From hadi@mojatatu.com Thu Sep 26 09:30:50 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2217E21F9AE7 for ; Thu, 26 Sep 2013 09:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njl+NIodXN0b for ; Thu, 26 Sep 2013 09:30:44 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id EA0CA21F90CF for ; Thu, 26 Sep 2013 09:30:40 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id oy12so1135276veb.27 for ; Thu, 26 Sep 2013 09:30: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:from:date:message-id:subject:to:cc :content-type; bh=5NzBqhhgfZ/k48RdD7T2EcwZB4p5A+y0oJQX1cofNdE=; b=Cft+BS4dQ9vHQ/FrjTV9A4r/hYzomgTc4IKgiKhh1Jo6WCa7q7vCrFls+JcA3dBxZh jECX4mioOOlPB6RPFibnGMt6d26hEftUTtzYllqzstU9rKvV/6CXOTL3VO5Bc7KgvZ6F 6C7B1lZhfdHEFoSuf35aa7jyEh5R9KMN6NsqhqaQi3/ykhlATJYe6HzkuhD62qcBRqPG JWC8nT0mx/qSSlFQLxzCMNWsDRbTE3/+D78+yDqmOfpJvmd4+CMsmWNIL9b7xfv8SUa7 C6J4BUo90kJk0orwg00PF0pznsFcDZY1adnbpp9wypB/Ca7BDQmgzYfOaMebicXg44EK ysSQ== X-Gm-Message-State: ALoCoQk575zgatojQzfGV6C+AqOVR8d5/S7mGvF5vCjNOj1NDsmft+3v94rtZSlMRNglibwVF0xF X-Received: by 10.52.26.69 with SMTP id j5mr1177409vdg.21.1380213040421; Thu, 26 Sep 2013 09:30:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.23.33 with HTTP; Thu, 26 Sep 2013 09:30:20 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 26 Sep 2013 12:30:20 -0400 Message-ID: To: Evangelos Haleplidis Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: [forces] general comments X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 16:30:50 -0000 One last thing Evangelos - Can you add xml examples for each section where you are proposing changes? It makes it easier to visualize - run spell checker - section 3.1 I got lost in the need for a content key. Can you give me an example of where this is useful? - I think your schema at the end of the doc is valid, but for example fig 4 and 5 use of "D/defaultValue" do not imply to the same thing. In general if, as we normally do, you validate the schema then we would be fine. - For the stats properties you enumerate in section 3.6; could you remove from the name "From/ToCE" for future-proofness? You can just say the stats are from a point of view of a CE (in which case "received" would imply "received from CE") cheers, jamal From ehalep@gmail.com Thu Sep 26 13:41:03 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3667821E80AB for ; Thu, 26 Sep 2013 13:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X1iArKUcTiq for ; Thu, 26 Sep 2013 13:40:58 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5990711E80DE for ; Thu, 26 Sep 2013 13:40:58 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id b15so815931eek.12 for ; Thu, 26 Sep 2013 13:40:50 -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=FkXlpYF1b9AwIMUqW3hF/DCSVBHL75paNsnqfR9lrHw=; b=gWYmdMxodpaHqAaNp8Vp6PYD4uoK93YcCUzfyP+ptdq3vFcMY88sfnqmowRzGuk0Ru INkfndV3jQ+NaEeJoe6DlItT6fFFkDHHXU/+zn9iCju1dsK6CpQh4/V2XW7JZaqz5bwI 36pEFjehOusL6+1miIKLWJHtq9CD/8TCfLl2kEGmiuSnajxSIG8lofCw8fu60vzawXu+ 3qKEtfT230p37/phxrfoiDb6pZmFyJZk5bIqES7PUHqHyrQNU8OteHJVCSPDx6y68/kP B0MEyylK9sepc/blGpjZQEnqYQiBpduYXJF/4scYQyOahwmnk6S0CMxyvpkyoHxgXBRS VEqw== X-Received: by 10.15.94.201 with SMTP id bb49mr4230225eeb.23.1380228050353; Thu, 26 Sep 2013 13:40:50 -0700 (PDT) Received: from EhalepXPS (ppp141237063164.access.hol.gr. [141.237.63.164]) by mx.google.com with ESMTPSA id m54sm8093870eex.2.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Sep 2013 13:40:49 -0700 (PDT) From: "Haleplidis Evangelos" To: Date: Thu, 26 Sep 2013 23:40:45 +0300 Message-ID: <00ec01cebaf8$ae1a7bb0$0a4f7310$@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: Ac66+GDbOolOg6RLRC6pWSmQANEWkwAAIu+A Content-Language: el Subject: [forces] FW: New Version Notification for draft-haleplidis-forces-packet-parallelization-03.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 20:41:03 -0000 Greetings to the list, =09 We just submitted an update for the packet parallelization draft. There is one outstanding issue with this document and it regards nested = parallel paths. The issue has been raised by Dave Hood and arises with the merger, when = multiple metadata arrive how would the merger distinguish which belong = to the current parallel path and which for the outer parallel path. There a number of ways to address the issue using the current defined = Metadata Set (MS): 1. One current MS and a table of MSs (tunneled metadata, namely a stack) = followed by a depth index. The merger will use only the current MS and get the top most from the MS = stack and remove it and use it as current MS for the next round. 2. Have a table with the current MS being the top most followed by a = depth index. 3. Add one additional field to the MS, namely a depth, and allow = multiple MSs as structs that are being passed around and the merger uses = only the highest number of depth and ignores the rest. 4. Or we could simply not allow parallel paths. We have discussed the issue and we were initially leaning towards the = second option. However that would increase the complexity of the = metadata that is passed around (a table with a structure per row). Therefore we are currently leaning towards the fourth option opting for = a simpler approach. However we would like the opinion of the working group for resolving the = issue. Text in the document corresponding for nesting is prefixed by the words: = =E2=80=9CEdit. NPP:=E2=80=9D Regards, Evangelos Haleplidis. > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, September 26, 2013 11:33 PM > To: Joel Halpern; Evangelos Haleplidis > Subject: New Version Notification for draft-haleplidis-forces-packet- > parallelization-03.txt >=20 >=20 > A new version of I-D, draft-haleplidis-forces-packet-parallelization- > 03.txt > has been successfully submitted by Evangelos Haleplidis and posted to > the IETF repository. >=20 > Filename: draft-haleplidis-forces-packet-parallelization > Revision: 03 > Title: ForCES Packet Parallelization > Creation date: 2013-09-26 > Group: Individual Submission > Number of pages: 21 > URL: = http://www.ietf.org/internet-drafts/draft-haleplidis-forces-packet-parall= elization-03.txt > Status: = http://datatracker.ietf.org/doc/draft-haleplidis-forces-packet-paralleliz= ation > Htmlized: = http://tools.ietf.org/html/draft-haleplidis-forces-packet-parallelization= -03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-haleplidis-forces-packet-paralle= lization-03 >=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. >=20 > Many network devices support parallel packet processing. This > document describes how ForCES can model a network device's > parallelization datapath. >=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 ehalep@gmail.com Thu Sep 26 15:01:10 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B136C21E80BE for ; Thu, 26 Sep 2013 15:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX03pZIFAkrH for ; Thu, 26 Sep 2013 15:01:10 -0700 (PDT) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D122F21F9C42 for ; Thu, 26 Sep 2013 15:01:06 -0700 (PDT) Received: by mail-ea0-f175.google.com with SMTP id m14so834353eaj.20 for ; Thu, 26 Sep 2013 15:01:00 -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=ztE6B7Rk01OqHixad/vJMJF5GbA1xCCkK59CYjcGNZM=; b=BBgKLTvnC8Gbux/LRht/LA/QPi5tx+a4FCDHHrYvYk6r40Zc6yaCkXJu2aBArBWwQy Kbou2w+HcMACEdptZr2BzDDVcEp0xWf1rMz7P1l3Ggigk//lehNDze/vLrtAzaYVJQ2T DTEB8RD8IQIEfhNLhQuMvVxS/jgkftLkLO3fZYwgV0VymYO9YBzGKau2L5oFur2gfNbO /3VyIKz7QXiCRbFChiYn21XGCA9RAHLTy1Fsp0wLB5ICQGFrXZXsS7u83pdfG2MIbytW YHf699EWW1CONsoPprd5ZsxasC9CifAKSW7rYE/9UVjoegDZsTOhWOcru2L5z8beJmyP tHKQ== X-Received: by 10.15.100.198 with SMTP id bn46mr4643208eeb.11.1380232860581; Thu, 26 Sep 2013 15:01:00 -0700 (PDT) Received: from EhalepXPS (ppp141237063164.access.hol.gr. [141.237.63.164]) by mx.google.com with ESMTPSA id b45sm8705456eef.4.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Sep 2013 15:00:59 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Jamal Hadi Salim'" References: <20130925155340.29986.32361.idtracker@ietfa.amsl.com> <00ee01ceba13$c62aed10$5280c730$@com> In-Reply-To: Date: Fri, 27 Sep 2013 01:00:55 +0300 Message-ID: <00f901cebb03$e130f0a0$a392d1e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac660ZRXjWcHTJYMT1+KsjkM9tsjpwAMOqhA Content-Language: el Cc: forces@ietf.org Subject: Re: [forces] I-D Action: draft-ietf-forces-model-extension-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 22:01:10 -0000 Greetings Jamal, Thanks for the response. Please see inline. Regards, Evangelos Haleplidis. > > B. The ambiguity of path selection using the GET property. GET > > property /LFBClass/LFBInstance/IDx, what should it return - property > > IDx of the LFB or the whole struct of properties of component with = ID > x? > > A simple solution for this issue would be to explicitly define that > > the path data refers to the LFB instead of a component as a path = flag > > in the path data. > > >=20 > With "dont change the protocol" approach: > Could we not reserve certain property ids? > Actually come to think of it: Component ID 0 is not used today. > Could we not have "Set/GetPropetyLFBClass/LFBInstance/0/IDx" > kind of semantics to imply we are referring to the property with IDx? [=C5=C7] I guess we could mandate from this document that Component ID 0 = is reserved. That would certainly solve the issue. >=20 > > 2. Bitmap datatype. > > There is a fundamental question whether we actually need a bitmap > datatype. > > As Joel suggested, it is possible to simulate bitmaps of size up > until > > 64 bits by using the base datatypes. For larger sizes the > alternatives > > are a struct of basic datatypes to reach the required bits or a = table > of booleans. > > However there is now other way to set/get a single or a set of bits > > without having the bitmap datatype. > > An additional issue arises with having to define the data packing > rule > > of transporting the bitmap by the protocol. > > > > I would like the opinion of the working group on these issues to > > resolve them. I think that the LFB properties are a nice addition. > > Bitmap are useful but not necessary and as they can be simulated, = but > > cannot be explicitly defined with the model. > > >=20 > To answer Joel's and your question: I think these are again commonly > used types, so we may need to define them somehow. Even if it turns = out > elsewhere in an informational draft. >=20 > One implementation approach i have found Linux uses is by defining two > fields. > Lets say i want to define a 32 bit map (in which i wish to specify > "bits to un/set"). > Then two 32 bit fields suffice. Call the first 32 bit the "selector". > If you set a bit > in the selector you are indicating that the bit is to be un/set. Then > call the second > 32 bit field the "value". As an example, is selector bit 3 is set then > when value bit field 3 is set, it means I want to set bit 3. If value > bit 3 is 0, it means I want to unset bit 3. Off the top of my head i > cant come up with the right term for the logical function that would > describe the operation between "selector" > and "value"; > (xor or nor seem wrong). > So in the worst case where you want to communicate one bit you waste > one > 32 bit value compared to boolean. In the best case you are 30 times > better in terms of bit-on-the wire preservation. > You can use the approach for 64 bit(map) etc. > I think Joel's view of bitmap is in a desire not to send all the bits > one is not interested in setting, but i would argue you cant beat the > above in terms of bit optimization ;-> [=C5=C7] I agree that this is more optimal but it's not a clean bitmap = solution. However having such a solution that is only 2 times more than the cost = of sending one bitmap, instead of a multiple of 32bits*number of bits may = be preferable than creating a new data packing rule. From ehalep@gmail.com Thu Sep 26 15:10:01 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C8821E80CA for ; Thu, 26 Sep 2013 15:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RibHEnto4IMd for ; Thu, 26 Sep 2013 15:10:00 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2771121E80C5 for ; Thu, 26 Sep 2013 15:09:59 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id o10so837368eaj.13 for ; Thu, 26 Sep 2013 15:09:59 -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=8MBTcOWw4Lgot2EyDpmE96MeaP/huUaAXMLv/NTW8h4=; b=rPGNxtbS2GMGIPLuw+dQWloHmH8c/1tQeDmZvhe/xRYyAigfO1lWBOBmmpCwoV7ukS 44M2P3OcQQILrNJKCSSL4KdEIbP9m9E+PhJi242iJuE2G+qnE8xFc2sf+LAwaxXFlmpE OnECqHymvwqmWFKgi4rm2vI2+itLeHvlZVVQi9yzw8f5RZiwulUu38rGZAEadI0VGSLa yi6PZtWR+a2lvKVY9aPNDvmLkbYEBHhcwb2oitnApMF8HEnm/BcCqo/MYBKQnM1zINc/ gHuR0NaOnIuis5QHwv5qxLTU/+1h/iYkVJrVLo7yNHUY6sFGRhbNVeGg4eQQ2cdxnMT0 0SFw== X-Received: by 10.14.210.8 with SMTP id t8mr4716649eeo.39.1380233399295; Thu, 26 Sep 2013 15:09:59 -0700 (PDT) Received: from EhalepXPS (ppp141237063164.access.hol.gr. [141.237.63.164]) by mx.google.com with ESMTPSA id a43sm8735567eep.9.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Sep 2013 15:09:58 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Jamal Hadi Salim'" References: In-Reply-To: Date: Fri, 27 Sep 2013 01:09:54 +0300 Message-ID: <00fa01cebb05$224dd5c0$66e98140$@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: Ac660v9VvqfDB1HtSoCEpTZGZIOLXgAMQ9Ww Content-Language: el Cc: forces@ietf.org Subject: Re: [forces] Comments model extension: BecomesEqualTo event condition X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 22:10:01 -0000 Greetings Jamal, I think that having filters for conditions would be a good idea. However that would complicate the model in the following sense: 1. We would have to define and model what logical operations are needed. Additionally would you allow multiple and nested operations? E.g. x and (y or (not (z) and k)) 2. Currently you define the threshold at the event properties for the value you want to check. If you provide multiple event checks, then we would need to define a dynamic approach to define threshold values for the different conditions which would complicate matters imho. E.g. If you have the x-Y, you would need a struct that would correspond the first for the V and Y for the second. It can be done, but that would mean that the threshold property won't be static as it is today. Regards, Evangelos Haleplidis. > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] > Sent: Thursday, September 26, 2013 7:11 PM > To: Evangelos Haleplidis > Cc: forces@ietf.org > Subject: Comments model extension: BecomesEqualTo event condition > > This is in section 3.5 > > I think we discussed this but my memory fails me. > Would it not be useful to instead to allow for logical OR AND filter > for conditions? > Then "== x" becomes [<"x+1" AND >"x-1"] > > I am faced with a condition where i have to specify in the xml multiple > events just so i can report separately a table row has been created, > updated deleted. I would have preffered, one event called table event > with condition [eventCreated OR eventChanged OR eventDeleted] > > cheers, > jamal > > PS: I do realise we want to keep the FE side as dumb as possible and > the above adds complexity of checks if we have many event subscribers > for a subset of things; but you are also adding additional state to be > checked against. From ehalep@gmail.com Thu Sep 26 15:22:55 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB07021F9F3D for ; Thu, 26 Sep 2013 15:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9LhbBXtFT76 for ; Thu, 26 Sep 2013 15:22:54 -0700 (PDT) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1814021E80CD for ; Thu, 26 Sep 2013 15:22:27 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id d41so835148eek.22 for ; Thu, 26 Sep 2013 15:22:21 -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=MPe/bpxumaibiy70J4xTpRMO9LRqjvxkqhggfIgghU4=; b=ZzdaTxLv+pF0MMiFBfOl8sFt3QFSj+kXcieuu7/05ftShSQ3iSUfaexS1R48r1B3Y6 CyglAi/cxX4XcZnzXzAeommLekSTVivAUbkXtI5+vC9qugPzYSKALx9TSypo+bSmONaI Q9eqrVBXLjdvfK+INerpqWwccKDUcaCUEta5q9rkKQagrvimSHsQrILG1ntxwS5iFGGk Cw2m7VFTKJJNbHi0QCZkP32bI0EnhpZ6j6fxueMz4qkfXXFKDYCMGkBg0RxuhMqY374i nB8HmzPe/2I5NtpcFtBkvQ+4wk0Z8JSO2DiYHvEmDDMYPhnAqVK99BovTtY/pkdUcvfi m3/A== X-Received: by 10.15.36.9 with SMTP id h9mr4990146eev.30.1380234141792; Thu, 26 Sep 2013 15:22:21 -0700 (PDT) Received: from EhalepXPS (ppp141237063164.access.hol.gr. [141.237.63.164]) by mx.google.com with ESMTPSA id k7sm8792867eeg.13.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Sep 2013 15:22:20 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Jamal Hadi Salim'" References: In-Reply-To: Date: Fri, 27 Sep 2013 01:22:16 +0300 Message-ID: <00fb01cebb06$dcc46760$964d3620$@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: Ac661jXg48yQ93lNQd2mhKHJRc1ZWAAL5tmA Content-Language: el Cc: forces@ietf.org Subject: Re: [forces] On optional ACL for structs X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 22:22:55 -0000 Greetings Jamal, Unless I misunderstood you, I think that's what the document specifies as well, albeit not that good as it appears. "When the optional access type for a struct component is defined it MUST override the access type of the struct." I should have explained it better and provided an example as you did. Additionally I should have explicitly defined what happens when the ACL is not defined. Having it optional means that it's not mandatory to be present and as such the component would follow the normal pattern defined by RFC5812. The bottom line is that, when you define a component for a struct (instead of a "struct component") if you define the access type it MUST override the access type of the struct itself. If not it inherits. Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On > Behalf Of Jamal Hadi Salim > Sent: Thursday, September 26, 2013 7:27 PM > To: Evangelos Haleplidis > Cc: forces@ietf.org > Subject: [forces] On optional ACL for structs > > Giving this some thought; i think we should make the choice of ACL for > the struct at the component level separate NOT override the default > defined value in the struct definition. > i.e We should, as we already do, allow the the children to inherit the > ACL of the parent when the childs ACL is not defined but not when it is > defined. > > Example: > datatype def foobar struct { > uint32 foo read only; > uint 32 bar; > } > > ..... > ...... > > myfoobar component id 1, read-write { > typeref foobar; > } > > In such a case if i do: > SET /FE/2/LFBX/InstanceY/myfoobar {1, 2} I should fail with > E_READ_ONLY > > If i do: > SET /FE/2/LFBX/InstanceY/myfoobar/bar {2} > > it should succeed. > > Otherwise you need to specify at myfoobar level what the different > fields ACLs should be which could be very complex for deeply nested > components. > > Thoughts? > > cheers, > jamal > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From ehalep@gmail.com Thu Sep 26 15:31:09 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D2321E80C5 for ; Thu, 26 Sep 2013 15:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMuUHr9-iXSl for ; Thu, 26 Sep 2013 15:31:09 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2953221F98EE for ; Thu, 26 Sep 2013 15:31:08 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id h14so851107eak.29 for ; Thu, 26 Sep 2013 15:31:08 -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=7ApUAqkCa9+rv+Fzwb3A79BiS/bmXxHt4zcuR0Vrb+I=; b=djPPIZnjIPE1lnjUh/zPPZnwH1rhQ4adTXZ+yqgTKiE9LXYBpO1wlCEtHS/sqhjNRg Sv3gzNjLhlBqCwqSY9+iucgTkZtlVZS5mPij9T9djv0CzJQpMYvoz64vhetGUsqODLpI alds/HtktLr3cslg0prOvpY6p12wqKQAACYEJjug5G24x5b6K4zqZZT62wiim31yJvuU uW50L9N8WpCxs3uiSCQPWKPZP/JDBCVEuIoVxgV6LG2diW4O+WnIrnlFOMA4fwOxZ2A8 +5k7nKqaSM6YID8HgnZ/0ft2A6v6Nzjvu1GzdNYmXLmx1pzraxAKxbXZwCMGkeZToBEz Efng== X-Received: by 10.14.225.199 with SMTP id z47mr5060165eep.24.1380234667944; Thu, 26 Sep 2013 15:31:07 -0700 (PDT) Received: from EhalepXPS (ppp141237063164.access.hol.gr. [141.237.63.164]) by mx.google.com with ESMTPSA id j7sm8842808eeo.15.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Sep 2013 15:31:07 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Jamal Hadi Salim'" References: In-Reply-To: Date: Fri, 27 Sep 2013 01:31:02 +0300 Message-ID: <00fc01cebb08$1672d540$43587fc0$@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: Ac661oZXtx+0HbWKTXutnQmRy+UrEAAMG0dw Content-Language: el Cc: forces@ietf.org Subject: Re: [forces] general comments X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 22:31:10 -0000 Greetings Jamal, Thank you very much for all the comments (for this and the other emails), I will incorporate required changes for the next version. In regards to the keys, they are only there for XML validation purposes using the schema. Not for writing the LFB Library itself. Therefore since we now allow arrays, the first key specifies that you won't have two equal values for content keys for the array and the second will not allow the same component ID for struct components. I borrowed the array definition from the previous XML schema. Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On > Behalf Of Jamal Hadi Salim > Sent: Thursday, September 26, 2013 7:30 PM > To: Evangelos Haleplidis > Cc: forces@ietf.org > Subject: [forces] general comments > > One last thing Evangelos > > - Can you add xml examples for each section where you are proposing > changes? It makes it easier to visualize > - run spell checker > - section 3.1 I got lost in the need for a content key. Can you give me > an example of where this is useful? > - I think your schema at the end of the doc is valid, but for example > fig 4 and 5 use of "D/defaultValue" do not imply to the same thing. > In general if, as we normally do, you validate the schema then we would > be fine. > - For the stats properties you enumerate in section 3.6; could you > remove from the name "From/ToCE" for future-proofness? You can just say > the stats are from a point of view of a CE (in which case "received" > would imply "received from CE") > > cheers, > jamal > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From joel@stevecrocker.com Fri Sep 27 01:41:24 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAC621F9808 for ; Fri, 27 Sep 2013 01:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkhXlwskjX68 for ; Fri, 27 Sep 2013 01:41:20 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 29D0F11E8139 for ; Fri, 27 Sep 2013 01:41:19 -0700 (PDT) Received: from dummy.name; Fri, 27 Sep 2013 08:41:18 +0000 Message-ID: <524544AE.1060805@stevecrocker.com> Date: Fri, 27 Sep 2013 04:41:18 -0400 From: Joel User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Haleplidis Evangelos References: <00fa01cebb05$224dd5c0$66e98140$@com> In-Reply-To: <00fa01cebb05$224dd5c0$66e98140$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: forces@ietf.org Subject: Re: [forces] Comments model extension: BecomesEqualTo event condition X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 08:41:24 -0000 I really do not want to create the complexity in either the protocol or the FE implementation of arbitrary expression logic for event conditions. In fact, having separate XML for creation, updating, and deletion events on rows seems to me to be a very GOOD idea, even if it makes the model writing a bit more complex. It makes the event processing MUCH cleaner, as you know exactly what case you are handling. As a general rule, I am happy to have more complexity in the XML to keep the wire exchanges and the FE logic simpler. Yours, Joel On 9/26/13 6:09 PM, Haleplidis Evangelos wrote: > Greetings Jamal, > > I think that having filters for conditions would be a good idea. > However that would complicate the model in the following sense: > > 1. We would have to define and model what logical operations are needed. > Additionally would you allow multiple and nested operations? E.g. x and (y > or (not (z) and k)) > 2. Currently you define the threshold at the event properties for the value > you want to check. If you provide multiple event checks, then we would need > to define a dynamic approach to define threshold values for the different > conditions which would complicate matters imho. E.g. If you have the and >x-Y, you would need a struct that would correspond the first for the V > and Y for the second. It can be done, but that would mean that the threshold > property won't be static as it is today. > > Regards, > Evangelos Haleplidis. > >> -----Original Message----- >> From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] >> Sent: Thursday, September 26, 2013 7:11 PM >> To: Evangelos Haleplidis >> Cc: forces@ietf.org >> Subject: Comments model extension: BecomesEqualTo event condition >> >> This is in section 3.5 >> >> I think we discussed this but my memory fails me. >> Would it not be useful to instead to allow for logical OR AND filter >> for conditions? >> Then "== x" becomes [<"x+1" AND >"x-1"] >> >> I am faced with a condition where i have to specify in the xml multiple >> events just so i can report separately a table row has been created, >> updated deleted. I would have preffered, one event called table event >> with condition [eventCreated OR eventChanged OR eventDeleted] >> >> cheers, >> jamal >> >> PS: I do realise we want to keep the FE side as dumb as possible and >> the above adds complexity of checks if we have many event subscribers >> for a subset of things; but you are also adding additional state to be >> checked against. > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From joel@stevecrocker.com Fri Sep 27 01:43:50 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735F121F9994 for ; Fri, 27 Sep 2013 01:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEzlYpwiFrkj for ; Fri, 27 Sep 2013 01:43:46 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 45A1011E8136 for ; Fri, 27 Sep 2013 01:43:46 -0700 (PDT) Received: from dummy.name; Fri, 27 Sep 2013 08:43:45 +0000 Message-ID: <52454542.5060203@stevecrocker.com> Date: Fri, 27 Sep 2013 04:43:46 -0400 From: Joel User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Haleplidis Evangelos References: <20130925155340.29986.32361.idtracker@ietfa.amsl.com> <00ee01ceba13$c62aed10$5280c730$@com> <00f901cebb03$e130f0a0$a392d1e0$@com> In-Reply-To: <00f901cebb03$e130f0a0$a392d1e0$@com> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 8bit Cc: forces@ietf.org Subject: Re: [forces] I-D Action: draft-ietf-forces-model-extension-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 08:43:50 -0000 I rather like the idea of taking component 0 and using it to mean "this", and that things following that move to the properties side. So an LFB ID with a path starting with 0 means the properties of the LFB, and a path to a structure with a following component of 0 means that the following components reference the properties of the structure. Yours, Joel On 9/26/13 6:00 PM, Haleplidis Evangelos wrote: > Greetings Jamal, > > Thanks for the response. Please see inline. > > Regards, > Evangelos Haleplidis. > >>> B. The ambiguity of path selection using the GET property. GET >>> property /LFBClass/LFBInstance/IDx, what should it return - property >>> IDx of the LFB or the whole struct of properties of component with ID >> x? >>> A simple solution for this issue would be to explicitly define that >>> the path data refers to the LFB instead of a component as a path flag >>> in the path data. >>> >> >> With "dont change the protocol" approach: >> Could we not reserve certain property ids? >> Actually come to think of it: Component ID 0 is not used today. >> Could we not have "Set/GetPropetyLFBClass/LFBInstance/0/IDx" >> kind of semantics to imply we are referring to the property with IDx? > > [ลว] I guess we could mandate from this document that Component ID 0 is > reserved. That would certainly solve the issue. > >> >>> 2. Bitmap datatype. >>> There is a fundamental question whether we actually need a bitmap >> datatype. >>> As Joel suggested, it is possible to simulate bitmaps of size up >> until >>> 64 bits by using the base datatypes. For larger sizes the >> alternatives >>> are a struct of basic datatypes to reach the required bits or a table >> of booleans. >>> However there is now other way to set/get a single or a set of bits >>> without having the bitmap datatype. >>> An additional issue arises with having to define the data packing >> rule >>> of transporting the bitmap by the protocol. >>> >>> I would like the opinion of the working group on these issues to >>> resolve them. I think that the LFB properties are a nice addition. >>> Bitmap are useful but not necessary and as they can be simulated, but >>> cannot be explicitly defined with the model. >>> >> >> To answer Joel's and your question: I think these are again commonly >> used types, so we may need to define them somehow. Even if it turns out >> elsewhere in an informational draft. >> >> One implementation approach i have found Linux uses is by defining two >> fields. >> Lets say i want to define a 32 bit map (in which i wish to specify >> "bits to un/set"). >> Then two 32 bit fields suffice. Call the first 32 bit the "selector". >> If you set a bit >> in the selector you are indicating that the bit is to be un/set. Then >> call the second >> 32 bit field the "value". As an example, is selector bit 3 is set then >> when value bit field 3 is set, it means I want to set bit 3. If value >> bit 3 is 0, it means I want to unset bit 3. Off the top of my head i >> cant come up with the right term for the logical function that would >> describe the operation between "selector" >> and "value"; >> (xor or nor seem wrong). >> So in the worst case where you want to communicate one bit you waste >> one >> 32 bit value compared to boolean. In the best case you are 30 times >> better in terms of bit-on-the wire preservation. >> You can use the approach for 64 bit(map) etc. >> I think Joel's view of bitmap is in a desire not to send all the bits >> one is not interested in setting, but i would argue you cant beat the >> above in terms of bit optimization ;-> > > [ลว] I agree that this is more optimal but it's not a clean bitmap solution. > However having such a solution that is only 2 times more than the cost of > sending one bitmap, instead of a multiple of 32bits*number of bits may be > preferable than creating a new data packing rule. > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From hadi@mojatatu.com Sat Sep 28 10:42:47 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6662921F9B91 for ; Sat, 28 Sep 2013 10:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tm0gkEI8cWaM for ; Sat, 28 Sep 2013 10:42:42 -0700 (PDT) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id B300611E813F for ; Sat, 28 Sep 2013 10:42:38 -0700 (PDT) Received: by mail-vb0-f43.google.com with SMTP id h11so2670907vbh.2 for ; Sat, 28 Sep 2013 10:42: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:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wBXJRJyv8lPGkux2ZBi6aDv2N8XiDkJqgJp2C8gOAoY=; b=hMZOOAIY3r9xX5DGn5F1edaZSy1vJROouq/NaQ6URfWvIk7aVZ0Adn5nEjC6loAwAw CqagK9yPT5W7nqg++u5YRIKhwisaSF2A1FfXqFkJQVIGrMxeH2r9D126K16aNS95DwpB vFpf8T6OSDV6FlKvSltyQtjcZK+rxAYWUVefcemDnHt4dp97eCi/f033TX3nE5DQXp6h 0S6Sy9v0wwFcBs6SeBDMHYMRU+nEQnAjyV5ISbSMPut+j6N8UWvqIP79I/gK47XzWj9J RRxrlKS5QItgqXN5ikx4yFqCpOUksXvuXBaIOH5B6Msb4z/Pv/I52jAkqfswH0wJuNBW Hq/Q== X-Gm-Message-State: ALoCoQm8ZWLsi+kcNB7unTZvIhsBaZbwFde7FZi9I6GrExcxD5UbFQXn5WuthxD2ym5VNj5/kMQk X-Received: by 10.58.133.66 with SMTP id pa2mr12754827veb.18.1380390158024; Sat, 28 Sep 2013 10:42:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.23.33 with HTTP; Sat, 28 Sep 2013 10:42:17 -0700 (PDT) In-Reply-To: <52454542.5060203@stevecrocker.com> References: <20130925155340.29986.32361.idtracker@ietfa.amsl.com> <00ee01ceba13$c62aed10$5280c730$@com> <00f901cebb03$e130f0a0$a392d1e0$@com> <52454542.5060203@stevecrocker.com> From: Jamal Hadi Salim Date: Sat, 28 Sep 2013 13:42:17 -0400 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: Re: [forces] I-D Action: draft-ietf-forces-model-extension-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 17:42:47 -0000 On Fri, Sep 27, 2013 at 4:43 AM, Joel wrote: > I rather like the idea of taking component 0 and using it to mean "this", > and that things following that move to the properties side. So an LFB ID > with a path starting with 0 means the properties of the LFB, Ok, great - so to re-iterate a GET or SETPROPERTY to: /FE/x/LFBy/0 accesses "properties of the LFB class y, all instances on FEx" /FE/x/LFBy/z where z>0 accesses "properties of the LFB class y instance z on FEx" correct? > and a path to a > structure with a following component of 0 means that the following > components reference the properties of the structure. We dont have a problem there at the moment. A GET/SET property works fine. cheers, jamal From hadi@mojatatu.com Sat Sep 28 10:44:14 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E634B21F9C28 for ; Sat, 28 Sep 2013 10:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1D10NPDI61g for ; Sat, 28 Sep 2013 10:44:09 -0700 (PDT) Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48]) by ietfa.amsl.com (Postfix) with ESMTP id 66C4521F9A97 for ; Sat, 28 Sep 2013 10:44:05 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id w16so2685905vbf.35 for ; Sat, 28 Sep 2013 10:44:04 -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=CEpKbq0Naa8f+vgO2vi2tgVl+8TL8QY3dOcGdVKicos=; b=Y/EjFh86oVm+ZU5fqzisKnm1MadSF7YUYqkaeC5b6ozvABExDdl1hb9PTwQZ3jJh7q i0IoaBx+db2NCgYK73TrgQmc2eeQ525KS2V4JBUdVBl2jhhIJZ7qJySI7MiVP8UrUGy0 iwkfavLkJElwBD1jqA9FvBg9wVMTbgnNUhkUaZq0XQdSGVxtDC0HAYPHR6qRcrB0c+Ce tF6JCoGxSwI1gc+oxv0Fb0JJdj082jQ7WNGysrQYJrUMYyhs8Bs5HbXaMLCX0oiLai/f +i8tZbScJyP4Jja2NN35cuiMk/81ieObn51jsOpUy1oUeoo3HHTR2kWWQEESyLPKhcSp wM3w== X-Gm-Message-State: ALoCoQmSMO4YX7CrFuKnptJCiZryFxPZf9aSQrjTlu8DfO8To3kCqwpAqbNLqEzuyfo4nQKjASfb X-Received: by 10.52.187.138 with SMTP id fs10mr10392760vdc.10.1380390244824; Sat, 28 Sep 2013 10:44:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.23.33 with HTTP; Sat, 28 Sep 2013 10:43:44 -0700 (PDT) In-Reply-To: <00fb01cebb06$dcc46760$964d3620$@com> References: <00fb01cebb06$dcc46760$964d3620$@com> From: Jamal Hadi Salim Date: Sat, 28 Sep 2013 13:43:44 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: Re: [forces] On optional ACL for structs X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 17:44:14 -0000 Greetings Evangelos, Ok never mind. Please provide illustrative examples (elsewhere as well per my earlier email). cheers, jamal On Thu, Sep 26, 2013 at 6:22 PM, Haleplidis Evangelos wrote: > Greetings Jamal, > > Unless I misunderstood you, I think that's what the document specifies as > well, albeit not that good as it appears. "When the optional access type for > a struct component is defined it MUST override the access type of the > struct." > I should have explained it better and provided an example as you did. > Additionally I should have explicitly defined what happens when the ACL is > not defined. > Having it optional means that it's not mandatory to be present and as such > the component would follow the normal pattern defined by RFC5812. > > The bottom line is that, when you define a component for a struct (instead > of a "struct component") if you define the access type it MUST override the > access type of the struct itself. If not it inherits. > > Regards, > Evangelos Haleplidis. > >> -----Original Message----- >> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On >> Behalf Of Jamal Hadi Salim >> Sent: Thursday, September 26, 2013 7:27 PM >> To: Evangelos Haleplidis >> Cc: forces@ietf.org >> Subject: [forces] On optional ACL for structs >> >> Giving this some thought; i think we should make the choice of ACL for >> the struct at the component level separate NOT override the default >> defined value in the struct definition. >> i.e We should, as we already do, allow the the children to inherit the >> ACL of the parent when the childs ACL is not defined but not when it is >> defined. >> >> Example: >> datatype def foobar struct { >> uint32 foo read only; >> uint 32 bar; >> } >> >> ..... >> ...... >> >> myfoobar component id 1, read-write { >> typeref foobar; >> } >> >> In such a case if i do: >> SET /FE/2/LFBX/InstanceY/myfoobar {1, 2} I should fail with >> E_READ_ONLY >> >> If i do: >> SET /FE/2/LFBX/InstanceY/myfoobar/bar {2} >> >> it should succeed. >> >> Otherwise you need to specify at myfoobar level what the different >> fields ACLs should be which could be very complex for deeply nested >> components. >> >> Thoughts? >> >> cheers, >> jamal >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces > From hadi@mojatatu.com Sat Sep 28 10:44:51 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31FD11E8146 for ; Sat, 28 Sep 2013 10:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 414Poj477xon for ; Sat, 28 Sep 2013 10:44:47 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7BC21F83E0 for ; Sat, 28 Sep 2013 10:44:47 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lf11so2712617vcb.35 for ; Sat, 28 Sep 2013 10:44: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=HIXChSB223gHgK8kJ2Ns1JBoNy6AwvE7ZfK9iCY1TkM=; b=Qswiyg7Z26gp7wdfUbQoc/+qc29d6O03AgGs5MkgYsjEzGnNVt+0EzE/x+3v9RRFTt 99U98ddcg/ezBEVz9yNn9gQJ4u3Gf/HP9gGMhF3CuO4lRq5ezL8zikpXog6cvjtk7SFw 2llD2QE2uwKKEj/8o7fLcDD5giXccCyaGssYVu8OMlWYHFn/V1CVAtuHzHqVne7FxCkW hS+OTVLe9LdeoRRvD8wSWf/D2zBWSTqWJApsAwX20XF/j4eDZEBLh5mPSpuSDG7z0Ytk zr5muKf+ZqJ/i781c29yvAi9h4xji3kxoWCjK/yIL1E93eYSVyZHVCzIWCRkjRsNExdQ xKng== X-Gm-Message-State: ALoCoQnE3Js+mhSzUqyIJECIdYtgz/d7gilEu5K8+T3WDvotW583f/Fik97dUdi70j1aR6A0uQ9h X-Received: by 10.220.88.13 with SMTP id y13mr13046823vcl.20.1380390286882; Sat, 28 Sep 2013 10:44:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.23.33 with HTTP; Sat, 28 Sep 2013 10:44:26 -0700 (PDT) In-Reply-To: <00fc01cebb08$1672d540$43587fc0$@com> References: <00fc01cebb08$1672d540$43587fc0$@com> From: Jamal Hadi Salim Date: Sat, 28 Sep 2013 13:44:26 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: Re: [forces] general comments X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 17:44:52 -0000 Evangelos, Thanks - that clarifies it for me. cheers, jamal On Thu, Sep 26, 2013 at 6:31 PM, Haleplidis Evangelos wrote: > Greetings Jamal, > > Thank you very much for all the comments (for this and the other emails), I > will incorporate required changes for the next version. > > In regards to the keys, they are only there for XML validation purposes > using the schema. Not for writing the LFB Library itself. > Therefore since we now allow arrays, the first key specifies that you won't > have two equal values for content keys for the array and the second will not > allow the same component ID for struct components. > I borrowed the array definition from the previous XML schema. > > Regards, > Evangelos Haleplidis. > >> -----Original Message----- >> From: forces-bounces@ietf.org [mailto:forces-bounces@ietf.org] On >> Behalf Of Jamal Hadi Salim >> Sent: Thursday, September 26, 2013 7:30 PM >> To: Evangelos Haleplidis >> Cc: forces@ietf.org >> Subject: [forces] general comments >> >> One last thing Evangelos >> >> - Can you add xml examples for each section where you are proposing >> changes? It makes it easier to visualize >> - run spell checker >> - section 3.1 I got lost in the need for a content key. Can you give me >> an example of where this is useful? >> - I think your schema at the end of the doc is valid, but for example >> fig 4 and 5 use of "D/defaultValue" do not imply to the same thing. >> In general if, as we normally do, you validate the schema then we would >> be fine. >> - For the stats properties you enumerate in section 3.6; could you >> remove from the name "From/ToCE" for future-proofness? You can just say >> the stats are from a point of view of a CE (in which case "received" >> would imply "received from CE") >> >> cheers, >> jamal >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces > From hadi@mojatatu.com Sat Sep 28 10:45:22 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1134A11E8144 for ; Sat, 28 Sep 2013 10:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b3gA5lCVLZZ for ; Sat, 28 Sep 2013 10:45:17 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7078E21F83E0 for ; Sat, 28 Sep 2013 10:45:14 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id e13so2693598vbg.17 for ; Sat, 28 Sep 2013 10:45:14 -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=wGPWuQlHHqfJgfdGfpcf1S0oF7SdC+Itz/yNXYUEGGQ=; b=EA0CCJIE40PM4JOauUjc+xAswhcQWZfyGLvvs3KZobrtKcZHkYAEccjIS2IUNqnhlT waqPuEaX03DmtHMlmYfABOC3ahqz3mC5kA1eVJewF/gL/RhzERTyJhgrECYBpwhpwE45 pM/PPEium5eohwwnyGbOfaX7basrxUgHe7djaMYqTm1vcL2IKencF1180IwHecDu7/9G dy0xn/euTYYAZkWikenJEgKmA6rvBvZkmj3uZCAXld4XQ8fIH0V7dkYY+vhZI7ul8wAp BnAOOOAH2AOL6iv8Dn81kBp3wUPyXCUqHnPD/CCexAJLj7Pe6Zd3iZT31ffhnjEyIPp7 zdOg== X-Gm-Message-State: ALoCoQk/c+5luQ9HOghWW533GZugcvjAsegEIVVJQPlqVIUHF3JgULXu/sv5KBzleB5nkBRjEzUf X-Received: by 10.52.98.131 with SMTP id ei3mr10750066vdb.4.1380390313940; Sat, 28 Sep 2013 10:45:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.23.33 with HTTP; Sat, 28 Sep 2013 10:44:53 -0700 (PDT) In-Reply-To: <524544AE.1060805@stevecrocker.com> References: <00fa01cebb05$224dd5c0$66e98140$@com> <524544AE.1060805@stevecrocker.com> From: Jamal Hadi Salim Date: Sat, 28 Sep 2013 13:44:53 -0400 Message-ID: To: Joel Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: Re: [forces] Comments model extension: BecomesEqualTo event condition X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 17:45:22 -0000 Ok, I am fine to keep it as is. cheers, jamal On Fri, Sep 27, 2013 at 4:41 AM, Joel wrote: > I really do not want to create the complexity in either the protocol or the > FE implementation of arbitrary expression logic for event conditions. > > In fact, having separate XML for creation, updating, and deletion events on > rows seems to me to be a very GOOD idea, even if it makes the model writing > a bit more complex. It makes the event processing MUCH cleaner, as you know > exactly what case you are handling. > > As a general rule, I am happy to have more complexity in the XML to keep the > wire exchanges and the FE logic simpler. > > Yours, > Joel > > > On 9/26/13 6:09 PM, Haleplidis Evangelos wrote: >> >> Greetings Jamal, >> >> I think that having filters for conditions would be a good idea. >> However that would complicate the model in the following sense: >> >> 1. We would have to define and model what logical operations are needed. >> Additionally would you allow multiple and nested operations? E.g. x and (y >> or (not (z) and k)) >> 2. Currently you define the threshold at the event properties for the >> value >> you want to check. If you provide multiple event checks, then we would >> need >> to define a dynamic approach to define threshold values for the different >> conditions which would complicate matters imho. E.g. If you have the > and >x-Y, you would need a struct that would correspond the first for the >> V >> and Y for the second. It can be done, but that would mean that the >> threshold >> property won't be static as it is today. >> >> Regards, >> Evangelos Haleplidis. >> >>> -----Original Message----- >>> From: Jamal Hadi Salim [mailto:hadi@mojatatu.com] >>> Sent: Thursday, September 26, 2013 7:11 PM >>> To: Evangelos Haleplidis >>> Cc: forces@ietf.org >>> Subject: Comments model extension: BecomesEqualTo event condition >>> >>> This is in section 3.5 >>> >>> I think we discussed this but my memory fails me. >>> Would it not be useful to instead to allow for logical OR AND filter >>> for conditions? >>> Then "== x" becomes [<"x+1" AND >"x-1"] >>> >>> I am faced with a condition where i have to specify in the xml multiple >>> events just so i can report separately a table row has been created, >>> updated deleted. I would have preffered, one event called table event >>> with condition [eventCreated OR eventChanged OR eventDeleted] >>> >>> cheers, >>> jamal >>> >>> PS: I do realise we want to keep the FE side as dumb as possible and >>> the above adds complexity of checks if we have many event subscribers >>> for a subset of things; but you are also adding additional state to be >>> checked against. >> >> >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> > From joel@stevecrocker.com Sat Sep 28 10:51:41 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA8911E8151 for ; Sat, 28 Sep 2013 10:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZF3A6mJlo4X for ; Sat, 28 Sep 2013 10:51:36 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA3911E8146 for ; Sat, 28 Sep 2013 10:51:36 -0700 (PDT) Received: from dummy.name; Sat, 28 Sep 2013 17:51:36 +0000 Message-ID: <52471725.7080505@stevecrocker.com> Date: Sat, 28 Sep 2013 13:51:33 -0400 From: Joel User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jamal Hadi Salim References: <20130925155340.29986.32361.idtracker@ietfa.amsl.com> <00ee01ceba13$c62aed10$5280c730$@com> <00f901cebb03$e130f0a0$a392d1e0$@com> <52454542.5060203@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "forces@ietf.org" Subject: Re: [forces] I-D Action: draft-ietf-forces-model-extension-00.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 17:51:41 -0000 Yep, that is what I was thinking. Yours, Joel On 9/28/13 1:42 PM, Jamal Hadi Salim wrote: > On Fri, Sep 27, 2013 at 4:43 AM, Joel wrote: >> I rather like the idea of taking component 0 and using it to mean "this", >> and that things following that move to the properties side. So an LFB ID >> with a path starting with 0 means the properties of the LFB, > > Ok, great - so to re-iterate a GET or SETPROPERTY to: > > /FE/x/LFBy/0 accesses "properties of the LFB class y, all instances on FEx" > /FE/x/LFBy/z where z>0 accesses "properties of the LFB class y > instance z on FEx" > > correct? > >> and a path to a >> structure with a following component of 0 means that the following >> components reference the properties of the structure. > > We dont have a problem there at the moment. A GET/SET property works fine. > > cheers, > jamal >