From nobody Tue Jun 3 09:00:30 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529C41A0309; Tue, 3 Jun 2014 09:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHMWPNn6KSGx; Tue, 3 Jun 2014 09:00:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 367C61A0319; Tue, 3 Jun 2014 09:00:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140603160028.3394.10999.idtracker@ietfa.amsl.com> Date: Tue, 03 Jun 2014 09:00:28 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/2HjqEIuQfHU66jVzs-ok2M7IzP0 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-protoextension-02.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 16:00:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : ForCES Protocol Extensions Author : Jamal Hadi Salim Filename : draft-ietf-forces-protoextension-02.txt Pages : 23 Date : 2014-06-03 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 extensions to the ForCES Protocol Specification[RFC 5810] 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-forces-protoextension-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 3 09:06:37 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF421A02AE for ; Tue, 3 Jun 2014 09:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvmsHKTSLftG for ; Tue, 3 Jun 2014 09:06:33 -0700 (PDT) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A38A31A020E for ; Tue, 3 Jun 2014 09:06:33 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id oz11so7227167veb.31 for ; Tue, 03 Jun 2014 09:06:27 -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=B/Dc3+zWZ7FGoSnWtXQbawCW+y+XxkTIKdCIEkM28Xw=; b=fq/jdWDrdnayUc4ASjRBDQZeZgbxYa+ZKDTq7ExvUfM4RCCouX2L1TwtuxMafuwh8D EebNygEphTPJ0oP8z2fcJSl2fj/njQEDdnwBV9WSC2dFuZ2VGywZB15WyYcbty0PaaG5 BnczrHZh3aTD/yVUuPBW88iI9td7ySlwgMu3YqtpLouGZacMgYA9svClTfe0Jm0Vcabx j7Br6wAl2gTJAU5/53qtOICDw+ANeB/8Ye/C2wH7OVdDnwS4tH4q0OjAXn6UcraQ7wnf 0Ia/D6UpCC1LJ90E/a7UYvmS34vSfSumopCfcvRHo635NQMPeamODKFtPeD3mCNpBddZ OQPQ== X-Gm-Message-State: ALoCoQm0xHaBPzNidQD444wt4SAvDc+QHeA7gQnW+leVsKGR4PHclzyO5I/9/WYudxzNM0q8sdjX X-Received: by 10.52.117.237 with SMTP id kh13mr1757612vdb.96.1401811587552; Tue, 03 Jun 2014 09:06:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.244.66 with HTTP; Tue, 3 Jun 2014 09:06:07 -0700 (PDT) From: Jamal Hadi Salim Date: Tue, 3 Jun 2014 12:06:07 -0400 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/aZwDxfRF7rP8GOlvF_wftz-HYg4 Subject: [forces] Feedback needed WAS(Fwd: New Version Notification for draft-ietf-forces-protoextension-02.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 16:06:35 -0000 Folks, Please provide some feedback in particular on having to deal with a CE or FE not being able to deal with result TLVs. We have not implemented what is described in this document in terms of updating FEPO. At the moment we are just assuming EXTENDEDRESULT-TLV because both sides of the implementation are ours. My thinking on this subject is: If i was to do things from scratch, given our current deployment experience I would just do EXTENDEDRESULT and totally throw out RESULT TLV. Using FEPO components and capabilities is one way to address this; it is a little cluttered and requires an update. Any other suggestions welcome. Thoughts? cheers, jamal ---------- Forwarded message ---------- From: Date: Tue, Jun 3, 2014 at 12:00 PM Subject: New Version Notification for draft-ietf-forces-protoextension-02.txt To: Jamal Hadi Salim A new version of I-D, draft-ietf-forces-protoextension-02.txt has been successfully submitted by Jamal Hadi Salim and posted to the IETF repository. Name: draft-ietf-forces-protoextension Revision: 02 Title: ForCES Protocol Extensions Document date: 2014-06-03 Group: forces Pages: 23 URL: http://www.ietf.org/internet-drafts/draft-ietf-forces-protoextension-02.txt Status: https://datatracker.ietf.org/doc/draft-ietf-forces-protoextension/ Htmlized: http://tools.ietf.org/html/draft-ietf-forces-protoextension-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-forces-protoextension-02 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 extensions to the ForCES Protocol Specification[RFC 5810] semantics to achieve that end goal. 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. The IETF Secretariat From nobody Fri Jun 6 07:34:23 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546881A0245 for ; Fri, 6 Jun 2014 07:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdZ5uIofLayh for ; Fri, 6 Jun 2014 07:34:20 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061051A0197 for ; Fri, 6 Jun 2014 07:34:19 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id cc10so1114247wib.5 for ; Fri, 06 Jun 2014 07:34:12 -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=nfRMSowwCn8lo6Iq8Pbb78l88KdKF9EWvkPY5IJUUH8=; b=Yfl8REN1T4F5EK/22v/PzWmH7zywhyDvL52FUktMOAM3NEBU07HmolmqBn6f2vd7AO IyAfLfcfLZMhL66Ji5YZf0uN+rtcAJZrcRFtymbXLWN1/o8hK3mX3U6NWev1UStJs9+r llZJLDo+r3A+gSkeJQCVS7lr7CZ9JSRxi2hNQu4sHcyhUSgiLyEQzHPAP3mrCMciMsK1 EbKKdo4pityaO5SjbT9j/aSJ6v0/mewh6ZZOefc1xTD0DhKbWiTWFGx9/pwE+3szPZuo phTlDNc5gQuwQWwViOFpYCOhs92g/g0VhDATnYvF8+jccT0zLUhJBcwJUFJrgsPG9n6f iyVA== X-Received: by 10.180.98.163 with SMTP id ej3mr8635411wib.9.1402065252059; Fri, 06 Jun 2014 07:34:12 -0700 (PDT) Received: from EhalepXPS (ppp079166104169.access.hol.gr. [79.166.104.169]) by mx.google.com with ESMTPSA id qa6sm9457078wic.5.2014.06.06.07.34.10 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 06 Jun 2014 07:34:11 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Jamal Hadi Salim'" , References: In-Reply-To: Date: Fri, 6 Jun 2014 17:34:09 +0300 Message-ID: <008801cf8194$627f8160$277e8420$@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: Ac9/ReuliO/MDyCPSEikh69YtLJECACRlUlQ Content-Language: el Archived-At: http://mailarchive.ietf.org/arch/msg/forces/Q7shXZNnq36wF47DF_XUxjxC-bc Subject: Re: [forces] Feedback needed WAS(Fwd: New Version Notification for draft-ietf-forces-protoextension-02.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 14:34:22 -0000 Greetings Jamal and to the list, I just read the protocol extension draft and have the following comments/questions: 1. Considering the table ranges, I tried to find in the original RFC 5810 as well whether we allow nested PATH-DATA when you have a KEYSELECTOR. There is no clear text (at least I didn't find any) that allows or disallows further nesting of PATH-DATA after a KEYSELECTOR. The same applies to the table ranges. Do we allow nested path-datas when a table range is present? I'm trying to think of a use case where such case. E.g. where I want from these specific rows one or more specific components (e.g. in the case of a struct) or rows in a specific array. Whatever we decide, it may make sense to explicitly define it in the text. 2. This more of a musing than a comment. Does it make sense to have more than one table ranges TLV in one path-data TLV? E.g. if you want rows 5-100 and 400-500. Agreed that this can be done with two PathDatas, and having multiple range TLVs may confuse, e.g. asking for 40-100 and 60-70. I'm mostly pro into having it as it is (only one table range). 3. Why limit the response in a table range be ONLY within a SPARSEDATA? You can use FULLDATA with the index prefixed. 4. Regarding the Extended Result Backward compatibility. You are adding knobs that change the nature of the protocol itself (e.g. Support only Extended Results) and that may complicate the FEPO unnecessary. The question is whether that consists of a protocol change. On the other hand we have only 4 bits for protocol changes and this may not constitute such a big change for a new protocol version. Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces [mailto:forces-bounces@ietf.org] On Behalf Of Jamal Hadi > Salim > Sent: Tuesday, June 03, 2014 7:06 PM > To: forces@ietf.org > Subject: [forces] Feedback needed WAS(Fwd: New Version Notification for > draft-ietf-forces-protoextension-02.txt > > Folks, > > Please provide some feedback in particular on having to deal with a CE > or FE not being able to deal with result TLVs. We have not implemented > what is described in this document in terms of updating FEPO. At the > moment we are just assuming EXTENDEDRESULT-TLV because both sides of > the implementation are ours. > > My thinking on this subject is: > If i was to do things from scratch, given our current deployment > experience I would just do EXTENDEDRESULT and totally throw out RESULT > TLV. > Using FEPO components and capabilities is one way to address this; it > is a little cluttered and requires an update. Any other suggestions > welcome. > > Thoughts? > > cheers, > jamal > > ---------- Forwarded message ---------- > From: > Date: Tue, Jun 3, 2014 at 12:00 PM > Subject: New Version Notification for draft-ietf-forces-protoextension- > 02.txt > To: Jamal Hadi Salim > > > > A new version of I-D, draft-ietf-forces-protoextension-02.txt > has been successfully submitted by Jamal Hadi Salim and posted to the > IETF repository. > > Name: draft-ietf-forces-protoextension > Revision: 02 > Title: ForCES Protocol Extensions > Document date: 2014-06-03 > Group: forces > Pages: 23 > URL: > http://www.ietf.org/internet-drafts/draft-ietf-forces-protoextension- > 02.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-forces-protoextension/ > Htmlized: http://tools.ietf.org/html/draft-ietf-forces- > protoextension-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-forces-protoextension-02 > > 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 extensions to the ForCES Protocol > Specification[RFC 5810] semantics to achieve that end goal. > > > > > 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. > > The IETF Secretariat > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From nobody Mon Jun 9 04:47:33 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11921A008D for ; Mon, 9 Jun 2014 04:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3kLCUln6GAy for ; Mon, 9 Jun 2014 04:47:27 -0700 (PDT) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A471A0085 for ; Mon, 9 Jun 2014 04:47:27 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id us18so4188737veb.34 for ; Mon, 09 Jun 2014 04:47:26 -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=v/pmr1VmeJ/fwH532KUGyk7x/SV11uRIggwrHdEhe84=; b=dRR433iabl2kzV1i84ZL+BmvRxnEAALdpBZ/20xVNREPN39dpgbREmgEtm1XW64imR 4OdGNMMZrlwCr+NzI1t9tUQdJtPQ0hmvIdT4hL4REWJ1sX4QvmMqlaE6KHvkC9vUaxPT Hkbv+46bHzZglnniE0OBbdl6tAWlVw19a6OxEGcbKWSDt1NDiyrf9Dr9oZANDVQiUBi6 aJWQFR4MuaCbCKV9B/diDwJu5FHmhjRbezCWNhEZejZdOFv0x6GdgyGJiPS5oQoHuIZe Fgn9+Wzj/xJj1Emgd74Z9FLWKU2vYFKhUJ8zquNyi6//XPHyPp+Bp7QL8ezSBmwkSdoY Nv4w== X-Gm-Message-State: ALoCoQlguqql+nIhkQsTzAX7QdUIYqrcWdK0lpmbKkffAQ4ETzAyO9jemqtQ1WMi62NGhJcbfjwQ X-Received: by 10.58.185.165 with SMTP id fd5mr23525359vec.41.1402314446430; Mon, 09 Jun 2014 04:47:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.244.66 with HTTP; Mon, 9 Jun 2014 04:47:06 -0700 (PDT) In-Reply-To: <008801cf8194$627f8160$277e8420$@com> References: <008801cf8194$627f8160$277e8420$@com> From: Jamal Hadi Salim Date: Mon, 9 Jun 2014 07:47:06 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/t3pSgjqsGX4fqN3hPxDmNp1oCYE Cc: "forces@ietf.org" Subject: Re: [forces] Feedback needed WAS(Fwd: New Version Notification for draft-ietf-forces-protoextension-02.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 11:47:29 -0000 Greetings Evangelos, On Fri, Jun 6, 2014 at 10:34 AM, Haleplidis Evangelos wrote: > Greetings Jamal and to the list, > > I just read the protocol extension draft and have the following > comments/questions: > > 1. Considering the table ranges, I tried to find in the original RFC 5810 as > well whether we allow nested PATH-DATA when you have a KEYSELECTOR. > There is no clear text (at least I didn't find any) that allows or disallows > further nesting of PATH-DATA after a KEYSELECTOR. > > The same applies to the table ranges. Do we allow nested path-datas when a > table range is present? I'm trying to think of a use case where such case. > E.g. where I want from these specific rows one or more specific components > (e.g. in the case of a struct) or rows in a specific array. > > Whatever we decide, it may make sense to explicitly define it in the text. > So we've never had need to mix both. Either we use KEYSELECTOR or RANGE or classical path. I cant think of any use case that would need at least two of those together. Joel? > 2. This more of a musing than a comment. Does it make sense to have more > than one table ranges TLV in one path-data TLV? > E.g. if you want rows 5-100 and 400-500. Agreed that this can be done with > two PathDatas, and having multiple range TLVs may confuse, e.g. asking for > 40-100 and 60-70. > I'm mostly pro into having it as it is (only one table range). > I think for starters a single range should be sufficient in my opinion. We did start with this great multi path approach, in practise with this particular approach simplicity seems to trump the efficiency. > 3. Why limit the response in a table range be ONLY within a SPARSEDATA? You > can use FULLDATA with the index prefixed. > Mostly because the response itself is SPARSE. A FULLDATA could be used; but my experience so far on usability vs efficiency - Ive almost given up on FULLDATA for a table row. People dont think through their model sometimes and it makes it hard to use FULLDATA in such a case. Joel was very much against the idea of FULLDATA in the early days and i was for it. Having gone through the experience, I would say the return on the investment is not worth the effort. In our implementation, we still will receive/process FULLDATA rows, but we never send them out. I am not sure if this document is the right place to describe this. > 4. Regarding the Extended Result Backward compatibility. You are adding > knobs that change the nature of the protocol itself (e.g. Support only > Extended Results) and that may complicate the FEPO unnecessary. > The question is whether that consists of a protocol change. On the other > hand we have only 4 bits for protocol changes and this may not constitute > such a big change for a new protocol version. > Yes, this is the biggest worry I have. You are right, we could go and define a new protocol version - but like you say, soon we will run out of protocol numbers if we have to make these changes for every little protocol extension. So what i just added is atrocious but saves us from doing that. There's probably a better way. cheers, jamal From nobody Mon Jun 9 07:03:19 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252821A017A for ; Mon, 9 Jun 2014 07:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.771 X-Spam-Level: X-Spam-Status: No, score=-0.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ydi3DQZjXxC0 for ; Mon, 9 Jun 2014 07:03:11 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id BBD801A018F for ; Mon, 9 Jun 2014 07:03:11 -0700 (PDT) Received: from dummy.name; Mon, 09 Jun 2014 14:03:09 +0000 Message-ID: <5395BE8E.1050309@stevecrocker.com> Date: Mon, 09 Jun 2014 10:02:54 -0400 From: Joel User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jamal Hadi Salim , Haleplidis Evangelos References: <008801cf8194$627f8160$277e8420$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/forces/tOoJFdm0DkmhQ6bttGBdJ9motOo Cc: "forces@ietf.org" Subject: Re: [forces] Feedback needed WAS(Fwd: New Version Notification for draft-ietf-forces-protoextension-02.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 14:03:15 -0000 I can construct use cases where you might want that information. But at least at first glance the prasing complexity seems to exceed the value gained by allowing it. Yours, Joel On 6/9/14, 7:47 AM, Jamal Hadi Salim wrote: > Greetings Evangelos, > > > On Fri, Jun 6, 2014 at 10:34 AM, Haleplidis Evangelos wrote: >> Greetings Jamal and to the list, >> >> I just read the protocol extension draft and have the following >> comments/questions: >> >> 1. Considering the table ranges, I tried to find in the original RFC 5810 as >> well whether we allow nested PATH-DATA when you have a KEYSELECTOR. >> There is no clear text (at least I didn't find any) that allows or disallows >> further nesting of PATH-DATA after a KEYSELECTOR. >> >> The same applies to the table ranges. Do we allow nested path-datas when a >> table range is present? I'm trying to think of a use case where such case. >> E.g. where I want from these specific rows one or more specific components >> (e.g. in the case of a struct) or rows in a specific array. >> >> Whatever we decide, it may make sense to explicitly define it in the text. >> > > So we've never had need to mix both. Either we use KEYSELECTOR or > RANGE or classical path. I cant think of any use case that would need at > least two of those together. Joel? > >> 2. This more of a musing than a comment. Does it make sense to have more >> than one table ranges TLV in one path-data TLV? >> E.g. if you want rows 5-100 and 400-500. Agreed that this can be done with >> two PathDatas, and having multiple range TLVs may confuse, e.g. asking for >> 40-100 and 60-70. >> I'm mostly pro into having it as it is (only one table range). >> > > I think for starters a single range should be sufficient in my opinion. > We did start with this great multi path approach, in practise with > this particular > approach simplicity seems to trump the efficiency. > >> 3. Why limit the response in a table range be ONLY within a SPARSEDATA? You >> can use FULLDATA with the index prefixed. >> > > Mostly because the response itself is SPARSE. A FULLDATA could be used; > but my experience so far on usability vs efficiency - Ive almost given up on > FULLDATA for a table row. People dont think through their model sometimes > and it makes it hard to use FULLDATA in such a case. > Joel was very much against the idea of FULLDATA in the early days and > i was for it. > Having gone through the experience, I would say the return on the investment is > not worth the effort. In our implementation, we still will > receive/process FULLDATA > rows, but we never send them out. > I am not sure if this document is the right place to describe this. > >> 4. Regarding the Extended Result Backward compatibility. You are adding >> knobs that change the nature of the protocol itself (e.g. Support only >> Extended Results) and that may complicate the FEPO unnecessary. >> The question is whether that consists of a protocol change. On the other >> hand we have only 4 bits for protocol changes and this may not constitute >> such a big change for a new protocol version. >> > > Yes, this is the biggest worry I have. You are right, we could go and > define a new protocol > version - but like you say, soon we will run out of protocol numbers if we have > to make these changes for every little protocol extension. > So what i just added is atrocious but saves us from doing that. > There's probably a better way. > > cheers, > jamal > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From nobody Wed Jun 11 09:58:54 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E511A0213 for ; Wed, 11 Jun 2014 09:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDSEZIY_aS-Q for ; Wed, 11 Jun 2014 09:58:49 -0700 (PDT) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B7C61A01F9 for ; Wed, 11 Jun 2014 09:58:49 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jz11so44271veb.16 for ; Wed, 11 Jun 2014 09:58:48 -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:content-type; bh=ch28p5Z+rf66D71g6BgLLsr2yxJstGUC2E7/3bgBR+c=; b=Nb+kzisfFegPJzqF4oPzjtqCeXq3aIhYvg3hQhQ1ALlMgacWUgDq+3cQOeNL4x6z/D wMmBxRLDOxfRluAeLW1dRiHjoCrGdSZiu6B6t8cu+whMvdkmFv22xAx7SRfTGPj59Zu8 1nh65jM/JGMQai3IHaPHgdgMfxzqwWeCJRPf3+sWGwT/3iYqXAcj/H8uz7NpxQTTTKIV 3WvWSeNJZ/aXiusvXETWGegZTJkUy9w/+Ms/cradDzTmS/W3neYz7oYj8CgkOc6hGpob +nU7iGCttt3qDHDy4bfI83eOWECcuFitlD38GfYfEhytk3ckx5mok+CgNOjSCAujI28i 8ljQ== X-Gm-Message-State: ALoCoQncny74n/tp7LWOzZi/QiAZ3Tya1IMUHsKXv3BBa3T0eJi0tSzCCo9d9qH9NvLhVJ1/GeMF X-Received: by 10.220.161.8 with SMTP id p8mr39415258vcx.4.1402505928467; Wed, 11 Jun 2014 09:58:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.244.66 with HTTP; Wed, 11 Jun 2014 09:58:28 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Wed, 11 Jun 2014 12:58:28 -0400 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/-FKFKrXWIPs-wEFGOXeHpOn-n0s Subject: [forces] Fwd: Improving and Restructuring the Routing Area X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:58:53 -0000 Interesting discussion going on routing-discussion mailing list (details below). Please join and express ---------- Forwarded message ---------- From: Alia Atlas Date: Tue, Jun 10, 2014 at 4:14 PM Subject: Fwd: Improving and Restructuring the Routing Area To: "rtg-chairs@ietf.org" Could you please forward to your working groups for those not on routing-discussion? Thanks, Alia ---------- Forwarded message ---------- From: Alia Atlas Date: Tue, Jun 10, 2014 at 3:57 PM Subject: Improving and Restructuring the Routing Area To: routing-discussion@ietf.org To all participants in the Routing Area, Adrian and I are working on improving the quality, speed, and experience of getting work done in the IETF Routing Area. There are three initiatives that we are working: WG Draft QA, Routing Area specific WG chair training, and reorganizing the working groups in the area. First, we intend to use our Routing Directorate more proactively by introducing a Working Group Draft Quality Assurance (WG Draft QA) process where the same selected routing directorate member will review a draft during WG draft adoption and during WG last call. The process will be documented on the Routing Area wiki (http://trac.tools.ietf.org/area/rtg/trac/wiki). This should allow directorate reviews to report technical issues that can actually get fixed early in the process (equivalent of bug reports) as opposed to just noting the concerns in the drafts (equivalent of release notes). Second, as was discussed during the recent IESG retreat, in addition to the IETF-wide WG chair training, we intend to have a series of training sessions for WG Chairs in the Routing Area addressing topics such as judging consensus, project management, motivating volunteers, using the datatracker (via a sandbox version that can be played with safely), and sharing experiences between WG chairs. Third, we intend to reorganize the working groups in the Routing area. We feel that it is important to focus on areas where there is active interest in standardization and to be open and able to accept new work into the area. As you know, we have had several new working groups (nvo3, i2rs, sfc, spring) created in the last few years and we need to be open and able to handle more new work as it comes in. We would also like to improve the signal-to-noise ratio experienced by participants in the different working groups and improve the quantity and quality of discussion and reviews. It is likely that not all WGs in the Routing Area will be directly affected. Here is the time-line for reorganizing the WGs. NOW: public discussion on routing-discussion@ietf.org about how to reorganize the working groups to best meet our motivations. Additional focused discussions are expected on the rtg-chairs@ietf.org and rtg-dir@ietf.org mailing lists. In Toronto: There will be meetings with the WG chairs and the Routing Directorate to get the ideas described and agreed upon. At the Routing Area Meeting in Toronto: Discuss the set of reorganized WGs and general charter content in the Routing Area meeting. September 2014: Based upon the feedback, suggestions, and discussion, Adrian and I finalize the reorganized WG charters. We start the internal IESG discussion and public reviews. October 2014: Formal rechartering process completes. In Honolulu: The new set of WGs meet. After Honolulu: Adrian and I deal with any issues and charter updates based upon a few months of experience. Here are the motivations that Adrian and I would like to be considered when coming up with ideas for how the WGs should be reorganized. 1) Move towards organizing working groups on functional responsibilities rather than scoping them to specific protocols. 2) Split giant working groups so relevant work is done in one place and there is an improved signal-to-noise ratio for participants who are only interested in a slice of the current working group's work. 3) Create synergies for scattered functionality (example ideas: OAM, FRR, traffic-engineering) 4) Create a DISPATCH working group for clear new idea discussion; rtgwg serves some of this purpose but doesn't have a clear process and isn't drawing in the new ideas. 5) Focus Routing Area time on design centers rather than on far corner cases. 6) Each working group should have clear, well defined, and achievable goals. Noting that the Routing Area has inherited some of its WG structure from the sub-IP area, it is not a goal to force IP routing and MPLS routing to remain separated. The goal of this reorganization is not closing working groups. Adrian and Alia are perfectly capable of closing working groups without going through restructuring. For those of you that have read this far, thank you. Getting this 80% right is going to take some serious discussion and thought. We all work in the Routing Area together with different perspectives. Please think carefully and help us have a highly focused discussion. Thanks, Alia and Adrian From nobody Tue Jun 17 04:20:58 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656801A034F for ; Tue, 17 Jun 2014 04:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3I3SO1NZZiCX for ; Tue, 17 Jun 2014 04:20:51 -0700 (PDT) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8073F1A034D for ; Tue, 17 Jun 2014 04:20:51 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id jx11so4597502veb.20 for ; Tue, 17 Jun 2014 04:20:50 -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=K0EXpnZx6LgzCp0me0/86FKTA5p6GovZ1isuOjHg/4Q=; b=ftJ10r7BDBX6VWFOtOolpUZR/0loNtSPSzN+Q/CHUGS925jzGA5jA231+XaS3SL6Lo wcJGYPQSFtgcwAExSecSbwmsGsP/UxCc96nCsn5scEpwIuV69AtenFYrpuraPf0Vftwy iNP/mooVIMy6kFHEmp8Z/at5TT58cIgatYU1RTWpRfaw4S636HC6Za6nQilCOHVVNkAI KtoRnYS2oXBQWRCOXBHNHaFQ4UPbW+JwPqtyfbs9kWR5UNwuIZiF8EJuQNoqdRoeoxz6 dSGNOq8ajyw6KT4PZbJxX7lpaFuTYO9keWas60rz4kga4K762OcvQFv1RhiLkbQ6J7Vv jbBw== X-Gm-Message-State: ALoCoQkgz3mpCfd8x0wnYb9dCL0H4QRnvwXBXF0pyi8OmaHZuBwQ26OcLe+SSqY/aJIIDjxuYUaY X-Received: by 10.52.14.9 with SMTP id l9mr1019224vdc.41.1403004050470; Tue, 17 Jun 2014 04:20:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Tue, 17 Jun 2014 04:20:30 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Tue, 17 Jun 2014 07:20:30 -0400 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/Q1nGXggn43K2ycdUVM-hpiPZb0w Subject: Re: [forces] WG last call: draft-ietf-forces-model-extension X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 11:20:56 -0000 Folks, The WG last call for this draft has now ended. If you have any comments - it is still not too late, please dont hesitate to send them to the author. cheers, jamal On Mon, May 26, 2014 at 9:40 AM, Jamal Hadi Salim wrote: > Salutations, > > DJ and I would like to start the two week working group last call for > draft-ietf-forces-model-extension. The document may be found here: > > http://tools.ietf.org/html/draft-ietf-forces-model-extension-02 > > The author is advised to try to resolve as many of the > comments as possible (on the mailing list) as they come in, but not to > post the new version of the draft until the wglc is closed and the > comments are resolved. > > This working group last call will end on Monday, 7th of June. > > cheers, > jamal From nobody Tue Jun 17 04:23:56 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6D11A0352 for ; Tue, 17 Jun 2014 04:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5ds4VB_8k_X for ; Tue, 17 Jun 2014 04:23:46 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3F71A034D for ; Tue, 17 Jun 2014 04:23:46 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id la4so6378404vcb.28 for ; Tue, 17 Jun 2014 04:23:45 -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=xvVuCRYas31LporBMdyNVSt52ctSN/4do9AgbH5jUNQ=; b=J+QHKMin0RxfMyPWQEUl2M5A6bfzG3dNgkgzS8i+gi1kbPc2rXAa5Axhw2Dg47Jhem GdSexjyeMcNVeYKCeNB8EPrypCUyAKmiRuQ7FbQMe1oNj/Vni6SB8RpwELBDtLJUD1K9 lqt8Us3dg9OHByTyLOR/zrbuhCLqOfuolnrXcX5nqEuGOelxdF/cCwqMOkfHvQa/UX13 IbwqEYTgvj4M1keGp9e1xduOSAq7bCV2TZKFkmYHfVTWIkxAlf9HV2/ZPJ26rdPUaSvh e4n8tZqBFYHGcW6eWu7UaZRW8Jq+ZSJamYnu0qQw6BIsyfIfZtXDdq5tbj1HlttG+UIK aC6A== X-Gm-Message-State: ALoCoQldOsbXAlMaQrl1wLYpISMLy24GICZl9pZ4VpIuo2fyebiW2WwuZ/MmGdw6vnx897uVc12p X-Received: by 10.220.113.207 with SMTP id b15mr69247vcq.55.1403004225425; Tue, 17 Jun 2014 04:23:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Tue, 17 Jun 2014 04:23:25 -0700 (PDT) From: Jamal Hadi Salim Date: Tue, 17 Jun 2014 07:23:25 -0400 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/uQEexq2bgUov7Dv2_JYcuyB3m48 Subject: [forces] WG last call: draft-ietf-forces-protoextension X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 11:23:51 -0000 Greetings, DJ and I would like to start the two week working group last call for draft-ietf-forces-protoextension. The document may be found here: http://tools.ietf.org/html/draft-ietf-forces-protoextension-02 And speaking in the third person ;-> : The author is advised to try to resolve as many of the comments as possible (on the mailing list) as they come in, but not to post the new version of the draft until the wglc is closed and the comments are resolved. This working group last call will end on Tuesday, 1st of July. cheers, jamal From nobody Thu Jun 19 06:38:03 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCF21A0362 for ; Thu, 19 Jun 2014 06:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDmS6db1dm13 for ; Thu, 19 Jun 2014 06:37:58 -0700 (PDT) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 317B71A01DE for ; Thu, 19 Jun 2014 06:37:58 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jz11so2296615veb.16 for ; Thu, 19 Jun 2014 06:37:57 -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=H7lzJTREYnPFzM1sZYdXk0cRxY1y+r7pxTXJV3E1q+8=; b=SfMoMTrC8aiVVouNjRlKqtpHazdLtFlbmFPS5M7q+lDSTQLi31tSMly2HHBtJNiix9 sP8leC9U2f+1x0t6lSI0rjlqwtp3yuAxI+6LBlcxzC6zRmhrh8vWKX41LXhBer/4/l61 NRZ8BtV4+hol8i1c2dedfpidp2x/wPDwZYeo1QyVBGzGg1Tqxj7lVBpXknnKFGhvAcd9 VWHu4t/wq0SPJocPio64OA6Af6hi+HEKasAm35kKEQaqNAEc27BWNqfOaJHg7To3o0Nn RJ5LaPmbHgXitwdtm9fHx0mmQL8gHJvzMlrPyDLKW0QK0QEy4uTeyMgjNaMNBh5vhQ4m FlcQ== X-Gm-Message-State: ALoCoQkSnujYwihNRPqIB1J8ndCfF/9sVZp7HPHMu2YWN1pA1CX0EkNjr10GnsC/k/iqsXhkB8Rs X-Received: by 10.52.72.39 with SMTP id a7mr3318960vdv.13.1403185076142; Thu, 19 Jun 2014 06:37:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Thu, 19 Jun 2014 06:37:35 -0700 (PDT) From: Jamal Hadi Salim Date: Thu, 19 Jun 2014 09:37:35 -0400 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/LTJ3n9NmcabtLaM1Gfw0GWfsRfE Subject: [forces] Inheritance dilema X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 13:38:00 -0000 I have come across an interesting issue with an LFB we are trying to implement that inherits from a parent LFB. Assume LFB class A which has: a) datatype struct foo = {...} b) component id 1 footab which is an indexed table of struct foos. c) an event id 61/1 which is generated anytime footab changes Assume LFB class B which inherits from LFB class A. It does: a) augment struct foo to create a new struct newfoo which adds two new fields goo and gah b) It overrides component Id 1(footab) to a new table that uses struct newfoo as table row. Lets change this to a new name newfootab. The interesting part: class B *does not* want to define any events. What rules make sense to enforce that? So far everything we've come across has fallen under simple rules: Because we changed the name of component ID 1 - we have to redefine (cutnpaste from parent) the events. Which is Ok. If we didnt change the name and kept it as footab, then not redefining means we are using the same events the parent had. cheers, jamal PS: I think the same question applies to "what if i didnt need a parent's components" From nobody Mon Jun 23 16:32:11 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A3C1A03C2 for ; Mon, 23 Jun 2014 16:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.929 X-Spam-Level: * X-Spam-Status: No, score=1.929 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DSL=1.129, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTgJPmvkQdEl for ; Mon, 23 Jun 2014 16:32:08 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 600361A02B0 for ; Mon, 23 Jun 2014 16:32:08 -0700 (PDT) Received: from dummy.name; Mon, 23 Jun 2014 23:32:07 +0000 Message-ID: <53A8B8F9.2020504@stevecrocker.com> Date: Mon, 23 Jun 2014 19:32:09 -0400 From: Joel User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jamal Hadi Salim , "forces@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/forces/bdBYwpv2eZVIMrIHvbmqyPXRiJo Subject: Re: [forces] Inheritance dilema X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 23:32:09 -0000 My own reading is that the events from A would still apply. The ID it applies to still exists. The fields it applies to still exists. Any conditions it defines are still well-defined. So the event is inherited. In fact, the rules of inheritance in ForCES are such that you can not invalidate an event. And the rule of substitutability (a child should always be useable as a parent) seem to require that the event exist and be well-defined. (This is important, for example, if the FE implements B but the CE thinks in terms of A. Note, the FE is always free to say "sorry, I won't accept registration for that event." Yours, Joel On 6/19/14, 9:37 AM, Jamal Hadi Salim wrote: > I have come across an interesting issue with an LFB we are trying to implement > that inherits from a parent LFB. > > Assume LFB class A which has: > a) datatype struct foo = {...} > b) component id 1 footab which is an indexed table of struct foos. > c) an event id 61/1 which is generated anytime footab changes > > Assume LFB class B which inherits from LFB class A. It does: > a) augment struct foo to create a new struct newfoo which adds two > new fields goo and gah > b) It overrides component Id 1(footab) to a new table that uses struct > newfoo as table row. > Lets change this to a new name newfootab. > > The interesting part: > class B *does not* want to define any events. > What rules make sense to enforce that? > > So far everything we've come across has fallen under simple rules: > Because we changed the name of component ID 1 - we have to redefine > (cutnpaste from parent) > the events. Which is Ok. > If we didnt change the name and kept it as footab, then not redefining > means we are using the same > events the parent had. > > cheers, > jamal > > PS: I think the same question applies to "what if i didnt need a > parent's components" > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From nobody Tue Jun 24 08:59:25 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4AD1B2E1D for ; Tue, 24 Jun 2014 08:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpbhQ8L0EnFo for ; Tue, 24 Jun 2014 08:59:19 -0700 (PDT) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3560E1B2E1E for ; Tue, 24 Jun 2014 08:54:15 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id db11so553121veb.4 for ; Tue, 24 Jun 2014 08:54: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=gDk8lImK9jwJzYAEIG8gQhV87L1Jq0hkue+C6bju0SU=; b=bwqc2PQV/SoazSfV15Dhyzc9ZzkbeETjDURpqTOhLFRacAbyrjVi8cDExalUGRE23j rKNSJb4xN+RuefiDQYhtV7sBwnjuXwuzt452xoyi0ZHxhQFYqm2N8PeA574uRkCpVDMZ YBhM1MQOijsxulghHzbHan1Bay7Z5b8pRe5/bekggkDnK4AIF+i3Mr59JP72hcUlKkjM 9yYtceCWkG+xYgO0LxXjXVSVYo0rnqtkk2EBaGaO0HUp4k20fqwqdrVEi2ptg8xPaqi9 oQEt47r1g9H8y7w1z+BYMBbmKZhXBNWDXWNWSVAHAPoQ1XZQI0EfKmg5VkqVTiVUVoP1 yMAQ== X-Gm-Message-State: ALoCoQmYoe3MfZBHByFdUwydcy92iAPAiklMyndaZ+TtbgxojKsv5ZEsPPMkp/SCCCYKMLfny+rt X-Received: by 10.220.192.129 with SMTP id dq1mr1202640vcb.57.1403625253246; Tue, 24 Jun 2014 08:54:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Tue, 24 Jun 2014 08:53:52 -0700 (PDT) In-Reply-To: <53A8B8F9.2020504@stevecrocker.com> References: <53A8B8F9.2020504@stevecrocker.com> From: Jamal Hadi Salim Date: Tue, 24 Jun 2014 11:53:52 -0400 Message-ID: To: Joel Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/GCZzHC2glWowuQKfgwfT2kRrEp8 Cc: "forces@ietf.org" Subject: Re: [forces] Inheritance dilema X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 15:59:21 -0000 On Mon, Jun 23, 2014 at 7:32 PM, Joel wrote: > My own reading is that the events from A would still apply. > The ID it applies to still exists. > The fields it applies to still exists. > Any conditions it defines are still well-defined. > So the event is inherited. > > In fact, the rules of inheritance in ForCES are such that you can not > invalidate an event. I did a little a little reading on general OO inheritance (and played around with python for a few hours) and it seems what we have with ForCES in "implicit inheritance and explicit override" is a common theme. > And the rule of substitutability (a child should always be useable as a > parent) seem to require that the event exist and be well-defined. (This is > important, for example, if the FE implements B but the CE thinks in terms of > A. I didnt get your last sentence (why would the CE think of LFB B in terms of A?); regardless you are making sense and i dont think we are far off from what the rest of the OO world does. This is more philosophical: It seems such a waste - I have to inherit all attributes my mother gave me whether i use them or not (and i have to have DNA code that handles them). I can add new attributes for my children to inherit and pass on all the things i inherited, but my children can not get rid of them ;-> At some point this becomes high maintanance. Humans not so bad, there are about 10-15 useless organs we have, but for LFBs - could we do better? ;-> It is solvable with a rebirth of a new LFB to purge old attributes but would it not be useful if we could add an explicit "null override" to purge an attribute? > Note, the FE is always free to say "sorry, I won't accept registration for > that event." > Yes, this should be enough. Could we introduce an event property for this? The FE sets it (and may reject the subscriptions) but if the CE reads it and knows then it wont bother subscribing. cheers, jamal From nobody Tue Jun 24 09:43:03 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C92A1B2BAD for ; Tue, 24 Jun 2014 09:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wecD5qYv82xo for ; Tue, 24 Jun 2014 09:42:59 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FBE21B2B12 for ; Tue, 24 Jun 2014 09:42:59 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id id10so596189vcb.30 for ; Tue, 24 Jun 2014 09:42:58 -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=80iSxtQVg83W5gSuG1Nty51V3ENxny/lDxQFtpeYm5Q=; b=imRtn/q1VfSRLNyH5W8gOIcBJO4NgjO+JECyWksRqfSrqtcrGaHmHGPglK1H80CCaA r21Ri2FObQtlJ8+qpoHJe1awIo7HzyzJE/ADHo0lKTRNTb5QOJeT5CznS/OimJHuAqv1 U8b2yuKOJd/P0Zb+REIGBJvpeh2AU4fJnCt3hvduc+ZYHSxuTHTkeayt3JBt2Ymv3/Q4 BrQLsozIAc5Cj2Mkqwt38mqc611u6iUwFssP9AWFzFdGNE4XBVFoNbM7bsyz5r6K7vNT VnEsQEIAr/Eld2KdMX0eMboS3+JN/Ppvx2Gn2Hnvt+YLwKqtYO2vYLPrdXbxqfdlUtBH /5jg== X-Gm-Message-State: ALoCoQnu2D1Srg2+uhPr7bmZ2xSrQcUk60uPfEOXStSgMV6kxajdKI1Pe1siOzvDuqilRGtgZVDs X-Received: by 10.58.141.168 with SMTP id rp8mr1804676veb.40.1403628178547; Tue, 24 Jun 2014 09:42:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Tue, 24 Jun 2014 09:42:38 -0700 (PDT) From: Jamal Hadi Salim Date: Tue, 24 Jun 2014 12:42:38 -0400 Message-ID: To: draft-ietf-forces-model-extension@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/UTT95XzKPe8Pjcg9QKuwvj2PbK0 Cc: "forces@ietf.org" Subject: [forces] Shepherding draft-ietf-forces-model-extension X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 16:43:01 -0000 Evangelos, I am going to begin the shepherding process for this document, As part of that process, I need to check if anyone has knowledge of any applicable IPR that has not been declared for this draft. Please respond to this email whether or not you are aware of any relevant IPR. If you are on the ForCES WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. cheers, jamal From nobody Tue Jun 24 12:07:21 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33641B285B for ; Tue, 24 Jun 2014 12:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcBCgpivChem for ; Tue, 24 Jun 2014 12:07:17 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B26A1B296C for ; Tue, 24 Jun 2014 12:07:16 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so837588wes.15 for ; Tue, 24 Jun 2014 12:07:13 -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=pTd5NNfxjvkB5h2xjBxLv8ioygoi6zi/S+N0ca2/ik0=; b=qNVHVj1H4o3GqPPjOckWXX5/mDFZlnlfegWiuAN7NBHjZrBbAY2mLbb2/PDw/3vEiS dnOgGHG6wmK3/GZUBz3PAbc5e0QFIVXiEYgzMFYiSp4qNlZjHL1dE/6sDVfjQib6T2II DPTXTaxVGndsWbTdOkAoJCany16b7jMCVNmkMK2hZ+FKxds+DZNpIG+p5CGR8yypyZ6M JcMMOW8m//X3WfZ48T5tlymVhrA27SScDQPw0sfCo75QO2v/2kdB8FYsl9qEoalyC19/ EVfpEsiGkMFoByNRVtgRnKVSolyXm+J/lYPbi9mrJBfinrg6RmhuCHUca6wk2Wq5UAUu CGcQ== X-Received: by 10.180.88.131 with SMTP id bg3mr4618086wib.57.1403636833268; Tue, 24 Jun 2014 12:07:13 -0700 (PDT) Received: from EhalepXPS (ppp079166027155.access.hol.gr. [79.166.27.155]) by mx.google.com with ESMTPSA id fn1sm4279238wib.18.2014.06.24.12.07.11 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 24 Jun 2014 12:07:12 -0700 (PDT) From: "Haleplidis Evangelos" To: "'Jamal Hadi Salim'" , References: In-Reply-To: Date: Tue, 24 Jun 2014 22:07:03 +0300 Message-ID: <008501cf8fdf$7f3f7d60$7dbe7820$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+Py17hpTlSUheRR+GQmz+mURftMQAE+klA Content-Language: el Archived-At: http://mailarchive.ietf.org/arch/msg/forces/QWmf7EoEWJeU_Eeu_JkEvM_dZMg Cc: forces@ietf.org Subject: Re: [forces] Shepherding draft-ietf-forces-model-extension X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 19:07:18 -0000 Greetings Jamal, I have no knowledge of any IPR related to this draft. Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces [mailto:forces-bounces@ietf.org] On Behalf Of Jamal Hadi > Salim > Sent: Tuesday, June 24, 2014 7:43 PM > To: draft-ietf-forces-model-extension@tools.ietf.org > Cc: forces@ietf.org > Subject: [forces] Shepherding draft-ietf-forces-model-extension > > Evangelos, > > I am going to begin the shepherding process for this document, As part > of that process, I need to check if anyone has knowledge of any > applicable IPR that has not been declared for this draft. > Please respond to this email whether or not you are aware of any > relevant IPR. > > If you are on the ForCES WG email list but are not listed as an author > or contributor, then please explicitly respond only if you are aware of > any IPR that has not yet been disclosed in conformance with IETF rules. > > cheers, > jamal > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From nobody Tue Jun 24 20:31:28 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AE91B2A84 for ; Tue, 24 Jun 2014 20:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.771 X-Spam-Level: X-Spam-Status: No, score=-0.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNGDtEGeEIpo for ; Tue, 24 Jun 2014 20:31:23 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id C5DC01B2A7A for ; Tue, 24 Jun 2014 20:31:23 -0700 (PDT) Received: from dummy.name; Wed, 25 Jun 2014 03:31:23 +0000 Message-ID: <53AA428E.4080705@stevecrocker.com> Date: Tue, 24 Jun 2014 23:31:26 -0400 From: Joel User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jamal Hadi Salim References: <53A8B8F9.2020504@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/forces/yBc0qhgCnZG0chTSgu74sU87rII Cc: "forces@ietf.org" Subject: Re: [forces] Inheritance dilema X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 03:31:26 -0000 Yes, we could add an event property for "I don't actually support this." I would prefer not to bother, as I think it will be relatively rare that the CE will actually want to subscribe to the event, but the FE won't support it. So having to go read the status may be more work than just subscribing and getting the error. Yours, Joel On 6/24/14, 11:53 AM, Jamal Hadi Salim wrote: > On Mon, Jun 23, 2014 at 7:32 PM, Joel wrote: ... >> Note, the FE is always free to say "sorry, I won't accept registration for >> that event." >> > > Yes, this should be enough. > Could we introduce an event property for this? > The FE sets it (and may reject the subscriptions) but if the CE reads > it and knows > then it wont bother subscribing. > > cheers, > jamal > From nobody Wed Jun 25 04:16:57 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36E81B2BA5 for ; Wed, 25 Jun 2014 04:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4g1x7RafPz3l for ; Wed, 25 Jun 2014 04:16:52 -0700 (PDT) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0031B2BEA for ; Wed, 25 Jun 2014 04:14:02 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jz11so1792272veb.30 for ; Wed, 25 Jun 2014 04:14:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=2uM5xzrpHSYyPof3Y2VnBbCmSZWcWCl9kvbzJpGVPe0=; b=K6aYJRXekzz1ISbXsEuZ2mjQXfXR67AMLWuxNbXnvqPXv8JnIql0A4I5a+EBs9ROuE nil1oUzJZK8awoGIOKZawv9uzVOPRrZyfekG+3fYaP6zBm5jHVkFWcC9oblBJAjFdEcy R4A9yKa3tvqBewGO0eHOOwhsqwFMJurU7G+p385gJuBcgvHkUc55LinOEa0ihPtbmn02 Oww2QqVVwsYGAA1ey1Kba4zLe2ZKGPuOkf406GWeUpZ2TLRXrM1Ql7xqGOHB5qyh+V4U BNOzk0o4Kcq7XKr8hQxVYNwkhSBZuSnS1JwlKULEuUCJM8RiOUis9/bIjMFrWqWmenT0 eWRg== X-Gm-Message-State: ALoCoQlXHQwmhHc00h+2tniRb2g+V5f3KdJFYIwlQhlT47cqE4xgJvwqwFUm7pbqoMvOh3BdLUQk X-Received: by 10.58.127.130 with SMTP id ng2mr5291veb.64.1403694842002; Wed, 25 Jun 2014 04:14:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Wed, 25 Jun 2014 04:13:41 -0700 (PDT) From: Jamal Hadi Salim Date: Wed, 25 Jun 2014 07:13:41 -0400 Message-ID: To: "forces@ietf.org" , draft-ietf-forces-model-extension@tools.ietf.org, Adrian Farrel Content-Type: multipart/mixed; boundary=047d7b66fec56e6d4c04fca72c57 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/ff6UQ-tEmBXnYjnqyBWdux0txio Subject: [forces] draft-ietf-forces-model-extension: Publication process started X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 11:16:53 -0000 --047d7b66fec56e6d4c04fca72c57 Content-Type: text/plain; charset=UTF-8 Folks, Attached is the "easy writeup" for this document. cheers, jamal --047d7b66fec56e6d4c04fca72c57 Content-Type: text/plain; charset=US-ASCII; name="writeup-model-ext.txt" Content-Disposition: attachment; filename="writeup-model-ext.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hwujlrmp0 CjEuIFN1bW1hcnkKClRoZSBkb2N1bWVudCBzaGVwaGVyZCBpcyBKYW1hbCBIYWRpIFNhbGltIDxo YWRpQG1vamF0YXR1LmNvbT4KVGhlIHJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IgaXMgQWRyaWFu IEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51az4KClRoaXMgZG9jdW1lbnQgZXh0ZW5kcyB0aGUg Rm9yQ0VTIE1vZGVsIGRvY3VtZW50IChSRkMgNTgxMikgdG8KYWxsb3cgY29tcGxleCBkYXRhdHlw ZXMgZm9yIG1ldGFkYXRhLCBvcHRpb25hbCBkZWZhdWx0IHZhbHVlcyBmb3IgCmRhdGF0eXBlcywg b3B0aW9uYWwgYWNjZXNzIHR5cGVzIGZvciBzdHJ1Y3R1cmVzIGFuZCBmaXhlcyBhbiBpc3N1ZSAK d2l0aCBMRkIgaW5oZXJpdGFuY2UuICBUaGUgZG9jdW1lbnQgYWxzbyBpbnRyb2R1Y2VzIHR3byBu ZXcgZmVhdHVyZXM6CmEgbmV3IGV2ZW50IGNvbmRpdGlvbiBCZWNvbWVzRXF1YWxUbyBhbmQgdGhl IGNvbmNlcHQgb2YgTEZCIHByb3BlcnRpZXMuCgoyLiBSZXZpZXcgYW5kIENvbnNlbnN1cwoKVGhl IGV4dGVuc2lvbnMgYXJlIHN0cmFpZ2h0Zm9yd2FyZCwgYW5kIHRoZXJlIHdhcyBubyBkaWZmaWN1 bHR5IGluIGNvbWluZyAKdG8gY29uc2Vuc3VzIG9uIGFsbCBwb2ludHMgZGVzY3JpYmVkLiBUaGVy ZSB3ZXJlIGVhcmxpZXIgZXh0ZW5zaW9ucyBpbgplYXJsaWVyIHZlcnNpb25zIG9mIHRoZSBkb2N1 bWVudCB0aGF0IHdlcmUgcmVtb3ZlZCBiYXNlZCBvbiBkaXNjdXNzaW9ucyAKaW4gdGhlIFdHIGZv ciB0aGUgc2FrZSBvZiBzaW1wbGljaXR5LiBBdCBsZWFzdCBvbmUgaW1wbGVtZW50YXRpb24gaGFz IAp2YWxpZGF0ZWQgc29tZSBvZiB0aGUgZmVhdHVyZXMgZGVzY3JpYmVkIGluIHRoZSBkb2N1bWVu dC4gIApXZSBiZWxpZXZlIHRoZSB3b3JraW5nIGdyb3VwIGlzIHNvbGlkbHkgYmVoaW5kIHRoaXMg ZG9jdW1lbnQuIApUaGUgc2hlcGhlcmQgdmFsaWRhdGVkIHRoZSBzYW5pdHkgb2YgdGhlIG5ldyBl eHRlbnNpb25zIHRvIHRoZSBYTUwgc2NoZW1hCmluIHNlY3Rpb24gNC4KCjMuIEludGVsbGVjdHVh bCBQcm9wZXJ0eQoKVGhlIGF1dGhvciBoYXMgY29uZmlybWVkIGNvbmZvcm1hbmNlIHdpdGggQkNQ IDc4Lzc5LiAKVGhlcmUgYXJlIG5vIElQUiBkaXNjbG9zdXJlcyBvbiB0aGUgZG9jdW1lbnQuCgo0 LiBPdGhlciBQb2ludHMKCmEpIFRoZSBkb2N1bWVudCBkb2VzIG5vdCBwYXNzIHRoZSBmdWxsIElE IE5pdHMgdGVzdC4KVGhlcmUgaXMgb25lIGVycm9yIHdoZXJlIGEgcmVmZXJlbmNlIHRvIHRoZSBw cmUtUkZDIDcxMjEgaXMgdXNlZC4KVGhlcmUgYSBmZXcgZWRpdG9yaWFsIG5pdCB3YXJuaW5ncy4K VGhlIGF1dGhvciBoYXMgYmVlbiBub3RpZmllZCB0byBmaXggdGhlc2UgaXNzdWVzIG9uIGFueSBu ZXcgcmVsZWFzZQpjb21pbmcgdXAgZnJvbSBhbnkgb3RoZXIgZmVlZGJhY2suCmIpIFRoZXJlIGlz IGEgdHlwbyBvbiB0aGUgY2FwdGlvbiBvbiBzZWN0aW9uIDQgWE1MIChhIGNsZWFyIGN1dG5wYXN0 ZSAKZXJyb3IgZnJvbSBhIHJlY3ljbGVkIGRyYWZ0KS4KVGhlIGF1dGhvciBoYXMgYmVlbiBub3Rp ZmllZCB0byBmaXggdGhpcyBvbiB0aGUgbmV4dCBwb3NzaWJsZSBvcHBvcnR1bmUuCgo= --047d7b66fec56e6d4c04fca72c57-- From nobody Wed Jun 25 04:19:46 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444851B2B87 for ; Wed, 25 Jun 2014 04:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YX38ElKvyYYu for ; Wed, 25 Jun 2014 04:19:37 -0700 (PDT) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5041B2B7A for ; Wed, 25 Jun 2014 04:19:05 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id jx11so1766153veb.6 for ; Wed, 25 Jun 2014 04:19: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=HIkNZVkAUzKgtvozwDIM9a/CV+Yl6Qq2mMFBN47RH6s=; b=EMHDe86479HKINTr83Mj6cpFMtdHop4MSyKxxQlWV342kq8kj1cmYk3p3YhG0hIXaZ 2u3jwgvRdeZ4KUIwaZ4evl6pwcrSl1noMeFHSb+XsTUj2vwYOMUzqgTOvbhormyeG8Ye kKM/1ciBFZ0XT1v/z3QxPEv9TfXupMUyg8Pmt6Jq6YLZCvM4vrBTyUaocqEDG964jc3z hcNZIDbPAYxVj0Oq4d1DbOKkw9cUe0ceXJq2Ldi95o9p5DvGMvZotOSVJQnt3dk2MnIM RVy4IgkSZYPKmktLX6tvkGKIuTW8OaD1kzoKBmlj4sucPl9b/er8Xy0WiECP5ddGaRRi Srdg== X-Gm-Message-State: ALoCoQkZlpqNgky5oAFrRM46lkNOsjj+zu5iZ+qgtlmIbjaUiDGAg9hbjXbxE0bVSlGM0+dJTqVw X-Received: by 10.220.165.6 with SMTP id g6mr6320582vcy.17.1403695144837; Wed, 25 Jun 2014 04:19:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.235.65 with HTTP; Wed, 25 Jun 2014 04:18:44 -0700 (PDT) In-Reply-To: <53AA428E.4080705@stevecrocker.com> References: <53A8B8F9.2020504@stevecrocker.com> <53AA428E.4080705@stevecrocker.com> From: Jamal Hadi Salim Date: Wed, 25 Jun 2014 07:18:44 -0400 Message-ID: To: Joel Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/ewRnmdZG2OWDnEE28Qc31PEn8c4 Cc: "forces@ietf.org" Subject: Re: [forces] Inheritance dilema X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 11:19:40 -0000 On Tue, Jun 24, 2014 at 11:31 PM, Joel wrote: > Yes, we could add an event property for "I don't actually support this." I > would prefer not to bother, as I think it will be relatively rare that the > CE will actually want to subscribe to the event, but the FE won't support > it. So having to go read the status may be more work than just subscribing > and getting the error. > At this point with current experience - I agree. It was good to discuss it. Thanks Joel. cheers, jamal