From nobody Sun Jun 3 06:51:50 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FB1127077 for ; Sun, 3 Jun 2018 06:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 iMwX6PBK43TV for ; Sun, 3 Jun 2018 06:51:46 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C714126CD8 for ; Sun, 3 Jun 2018 06:51:46 -0700 (PDT) X-AuditID: 12074423-2e9ff700000055a7-ae-5b13f27181c8 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id C3.43.21927.172F31B5; Sun, 3 Jun 2018 09:51:45 -0400 (EDT) Received: from outgoing-exchange-3.mit.edu (OUTGOING-EXCHANGE-3.MIT.EDU [18.9.28.13]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w53DpiXm019968 for ; Sun, 3 Jun 2018 09:51:45 -0400 Received: from OC11EXEDGE4.EXCHANGE.MIT.EDU (OC11EXEDGE4.EXCHANGE.MIT.EDU [18.9.3.27]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id w53DpgTE009473 for ; Sun, 3 Jun 2018 09:51:43 -0400 Received: from W92EXCAS20.exchange.mit.edu (18.7.71.33) by OC11EXEDGE4.EXCHANGE.MIT.EDU (18.9.3.27) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sun, 3 Jun 2018 09:51:33 -0400 Received: from OC11EXPO33.exchange.mit.edu ([169.254.1.177]) by W92EXCAS20.exchange.mit.edu ([18.7.71.33]) with mapi id 14.03.0352.000; Sun, 3 Jun 2018 09:51:42 -0400 From: Thomas Hardjono To: "din@irtf.org" Thread-Topic: Minimal assumption for interoperable blockchain systems Thread-Index: AQHT+0CmDYm4GElA7Ua0jKaUNEZ41g== Date: Sun, 3 Jun 2018 13:51:42 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.7.71.62] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBKsWRmVeSWpSXmKPExsUixG6nolv4STjaYOkXKYulH/eyODB6TN54 mC2AMYrLJiU1J7MstUjfLoEr4+/G60wFL9gqfpzfy9LAeIS1i5GTQ0LARGLN7clMILaQwGIm icaX/l2MXED2JUaJ5vfr2SGcm4wSLx+3sEE42xglOve+Y4VwVjFKfGu8ywjSzyagIdH2o5cd xBYRUJRY2jAVLC4s4CCxaekzFoi4q8S6+V2sELaexPv/j8BsFgEVibWvOsHqeQWCJM7tvwRm MwqISXw/tQbsPmYBcYlbT+YzQdwtKLFo9h5mCFtM4t+uh2wQtpzE9L1fWCDqDSTen5vPDGFr Syxb+JoZYr6gxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsopRNiW3Sjc3MTOnODVZtzg5MS8v tUjXTC83s0QvNaV0EyM4UlyUdzC+7PM+xCjAwajEw5txXihaiDWxrLgy9xCjJAeTkijvqwrh aCG+pPyUyozE4oz4otKc1OJDjBIczEoivOGegtFCvCmJlVWpRfkwKWkOFiVx3pxFjNFCAumJ JanZqakFqUUwWRkODiUJ3usfgYYKFqWmp1akZeaUIKSZODhBhvMADd8AUsNbXJCYW5yZDpE/ xajLcaetp4dZiCUvPy9VSpz3I0iRAEhRRmke3BxwguNkln7FKA70ljCvG0gVDzA5wk16BbSE CWjJswqwJSWJCCmpBsaCT0WtsodYkjYwZGUt2L5dl9O9z+JCNZ929Z3s5oOXb//cJzup4Ujk qyiR5YaeF88dPSB+Ypvciu08Sz78WLzHpvW+wQHf17k/SyKmBCb8ual1I8wyL5xxauDHCDnf wz9+qzaauu6U2D97c2i0nhGj1fH+JQl8a68u3a2XcjGDdbfh85/6ks1KLMUZiYZazEXFiQCK K3fVSwMAAA== Archived-At: Subject: [Din] Minimal assumption for interoperable blockchain systems X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2018 13:51:48 -0000 Here is a question I'd like to throw out to this community regarding "inter= operable blockchain systems" -- a topic which will undoubtedly come to the = forefront (assuming it doesn't get drowned-out or killed by the barrage of = hype about BC): -- Minimal assumption: What is the minimal assumption for interoperable blo= ckchain systems with regards to the notion of transaction units. In other w= ords, what is the =93datagram=94 equivalent of transactions =96 namely the = transaction unit that is semantically understandable (processable) by multi= ple different blockchain systems. This is a question we posed in our recent discussion paper: https://arxiv.org/pdf/1805.05934.pdf Would love to get your thoughts on this "datagram" equivalent question (or = if this framework of thought is even the correct one). Best -- thomas --=20 From nobody Sun Jun 3 07:12:56 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F14E127078 for ; Sun, 3 Jun 2018 07:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZfPUFOFKSc4O for ; Sun, 3 Jun 2018 07:12:53 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1AED126CD8 for ; Sun, 3 Jun 2018 07:12:52 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id x2-v6so9965357wmh.5 for ; Sun, 03 Jun 2018 07:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Ss/9gH3qTpDr7nYOcqEG1bySPTEnkLUMkz3oxhHOECQ=; b=fZKhxx52vkUaNMlu73/ZB64Llj2ocm0A8fG5FfgtOhcsRAQtMQS6QM1c3HCLIHjJ5N Sf5SIVqt2OAYPXVWbtI3u5XPuDNX8BpOh893LO45WA2xY3i1IzaPEuJ2uVOpAtpjXFUG 6BfDKHTDLR/roIn0kcITq32i7x4F+C5GqZlrycwGvpEvuVahexcwPG8pRQDrOYB46yVC CjOLPzUIBXlYYiYwA94MxUwyFd3i6gG69FEiHtJFCIgoLpF91u6J9zgEN9swPzBO3jAO EqAqupH52Dhl9i43XtOzJaRyRTZIwvmNpr6jFhPUEObdsg0pqv1p0nvrIqtSh1HEfVZK Kwvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Ss/9gH3qTpDr7nYOcqEG1bySPTEnkLUMkz3oxhHOECQ=; b=UGRrXEtrPNi4iAqhqMWk/kMmTgnqjf8IHpugVRvjljDYbid2V5CoeU4puPj7egAuyS Y6veK2egDMp40nHs38zO9f8ZcxXjwMEAsIM3q++BCx98cCayqEyOipvD4HBeFBsx6o5X QR8KFwXegzKXXPvJIH8NvxPaXtzjvnH6vC8ErInluhnm1vdG4ExZaVXMGAaroawsvQO5 vTQyuVrA9fWzKkNYCGmVSBSKpy4xda86atqCndgL7xh8cGF2QppLNP8k7+wtUyBAx4F9 Gwgj986VfRLUt5mMD8Q4jV8WUFCe17TrarPUp9/kFmTruNekGJY6M/TGnLjS9lkIiCeo 0aKA== X-Gm-Message-State: ALKqPweyl9B1qdLGnsvBX6UGFW6e9NblYtHrxIHKaYq1PwCH7ADcuq3e 5hH+VjjggGwTQTR48gRl5A5tAy/wl8gpVVMB7o8= X-Google-Smtp-Source: ADUXVKI8fq6v0MoXpmkEPF4zKxo8QZbTyWb8k7WiWWmkkphTfpRn1bNIgzpLYbje2lfcaL4RWOUknf6g43nG+WCUhrM= X-Received: by 2002:a1c:8ec1:: with SMTP id q184-v6mr7469382wmd.104.1528035170800; Sun, 03 Jun 2018 07:12:50 -0700 (PDT) MIME-Version: 1.0 Sender: crowcroft@gmail.com Received: by 2002:a1c:589:0:0:0:0:0 with HTTP; Sun, 3 Jun 2018 07:12:50 -0700 (PDT) In-Reply-To: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu> References: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu> From: Jon Crowcroft Date: Sun, 3 Jun 2018 15:12:50 +0100 X-Google-Sender-Auth: DqqHSN_bm1jjXJ_SkbUfS8L47Uo Message-ID: To: Thomas Hardjono Cc: "din@irtf.org" Content-Type: multipart/alternative; boundary="0000000000008f56b9056dbd6999" Archived-At: Subject: Re: [Din] Minimal assumption for interoperable blockchain systems X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2018 14:12:56 -0000 --0000000000008f56b9056dbd6999 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable looks sane (as did interledger) but we're missing (I think, but may be I missed it too) one of the big challenges for this compared with scaling (which is what you have to address in internetworking stuff whether subnetworks with IP or IGPs with BGP, or serice+content with WWW - that's a fundamentally difficult piece of distributed ledgers- consistency one thing the e2e model did for thinking (amongst many) was to think in an intensely relaxed way about consistency - IP doesn't care if the source is still where it was when the packet reaches the destination (or even first hop router. BGP doesn't care (much) about IGP convergance when announcing (or withdrawing) prefixes and (most) AS paths. WWW doesn't care if the remote page (server, site or content) are there when you add a URL to your site - all this is "fixed up later" by some eventual consistency protocol (in IPs case, TCP; in the IGP/BGPs case the linkstate and path vector and a lot of magic pixie dust and luck; in the WWW case, search/rank&shame and later maintenance) - so for inter-ledger type thinking, we're connecting systems that fundamentally care about consistency - but define its eventuality differently - so a basic building block of an interoperabilty or inter-domain protocol would be to convey (and somehow reconcile) that variation in notion of how long before we agree about an append in domain 1, when were' 5 ledger domain hops away... which reminds me, am I allowed to coin that term "ledgerdomain" ? :-) On Sun, Jun 3, 2018 at 2:51 PM, Thomas Hardjono wrote: > > Here is a question I'd like to throw out to this community regarding > "interoperable blockchain systems" -- a topic which will undoubtedly come > to the forefront (assuming it doesn't get drowned-out or killed by the > barrage of hype about BC): > > -- Minimal assumption: What is the minimal assumption for interoperable > blockchain systems with regards to the notion of transaction units. In > other words, what is the =E2=80=9Cdatagram=E2=80=9D equivalent of transac= tions =E2=80=93 namely the > transaction unit that is semantically understandable (processable) by > multiple different blockchain systems. > > This is a question we posed in our recent discussion paper: > > https://arxiv.org/pdf/1805.05934.pdf > > Would love to get your thoughts on this "datagram" equivalent question (o= r > if this framework of thought is even the correct one). > > > Best > > > -- thomas -- > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > --0000000000008f56b9056dbd6999 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
looks sane (as did interledger) but we're missing (I t= hink, but may be I missed it too) one of the big challenges for this compar= ed with scaling (which is what you have to address in internetworking stuff= whether subnetworks with IP or IGPs with BGP, or serice+content with WWW -= that's a fundamentally difficult piece of distributed ledgers- consist= ency

one thing the e2e model did for thinking (amongst m= any) was to think in an intensely relaxed way about consistency - IP doesn&= #39;t care if the source is still where it was when the packet reaches the = destination (or even first hop router. BGP doesn't care (much) about IG= P convergance when announcing (or withdrawing) prefixes and (most) AS paths= . WWW doesn't care if the remote page (server, site or content) are the= re when you add a URL to your site - all this is "fixed up later"= by some eventual consistency protocol (in IPs case, TCP;=C2=A0 in the IGP/= BGPs case the linkstate and path vector and a lot of magic pixie dust and l= uck; in the WWW case, search/rank&shame and later maintenance) -
<= div>
so for inter-ledger type thinking, we're connecting = systems that fundamentally care about consistency - but define its eventual= ity differently - so a basic building block of an interoperabilty or inter-= domain protocol would be to convey (and somehow reconcile) that variation i= n notion of how long before we agree about an append in domain 1, when were= ' 5 ledger domain hops away...

which reminds m= e, am I allowed to coin that term "ledgerdomain" ? :-)

On Sun, Jun 3, 2= 018 at 2:51 PM, Thomas Hardjono <hardjono@mit.edu> wrote:
=

Here is a question I'd like to throw out to this community regarding &q= uot;interoperable blockchain systems" -- a topic which will undoubtedl= y come to the forefront (assuming it doesn't get drowned-out or killed = by the barrage of hype about BC):

-- Minimal assumption: What is the minimal assumption for interoperable blo= ckchain systems with regards to the notion of transaction units. In other w= ords, what is the =E2=80=9Cdatagram=E2=80=9D equivalent of transactions =E2= =80=93 namely the transaction unit that is semantically understandable (pro= cessable) by multiple different blockchain systems.

This is a question we posed in our recent discussion paper:

https://arxiv.org/pdf/1805.05934.pdf

Would love to get your thoughts on this "datagram" equivalent que= stion (or if this framework of thought is even the correct one).


Best


-- thomas --

_______________________________________________
Din mailing list
Din@irtf.org
https://www.irtf.org/mailman/listinfo/din

--0000000000008f56b9056dbd6999-- From nobody Sun Jun 3 14:50:11 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D780126BF3 for ; Sun, 3 Jun 2018 14:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com 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 efEg-xQwx1nB for ; Sun, 3 Jun 2018 14:50:07 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E88C124234 for ; Sun, 3 Jun 2018 14:50:07 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D1C5721149 for ; Sun, 3 Jun 2018 17:50:05 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Sun, 03 Jun 2018 17:50:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=gyUM6U xHAIdAoFqyXXZ/0GlvI1v5LfQnJh+ZnqZDh18=; b=jmpHveVHmNRsJAm0UcV9Tb QsdoXOZ7NqCncn4a3SaCgkF3Ul9a/FnZl72uHDrwLCHSQFyMjvoFbQJGOU8YCk4e SaYVM+DlUAkEhaKwrwKvIySvyqHUYENIlsWeAangDWqZaBMPTVbHTzGBCiDu60eG 7vFDIERjZlcFAkleh38LlbxJuf7fFXLLtft0X3t5Ol/MElxVoSfHTg6jv64RcARO K1gyrbv3N9sIP/CpWmOMgWR8IT1GnPZt5fqmhNpr6GQDspKfZ9Z+WuqhqU2eMzSd +ptmR8vkGZ4pqs7E2/8tzGISvhqCDBO7WCeQAr9oOKfNRUoyGB4RybXplM2Uq02w == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 474FEBA50D; Sun, 3 Jun 2018 17:50:05 -0400 (EDT) Message-Id: <1528062605.1487185.1394957608.1F05953C@webmail.messagingengine.com> From: Jehan Tremback To: din@irtf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152806260514871855" X-Mailer: MessagingEngine.com Webmail Interface - ajax-397f98d6 In-Reply-To: Date: Sun, 03 Jun 2018 17:50:05 -0400 References: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu> Archived-At: Subject: Re: [Din] Minimal assumption for interoperable blockchain systems X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2018 21:50:11 -0000 This is a multi-part message in MIME format. --_----------=_152806260514871855 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" No citation of https://github.com/cosmos/cosmos-sdk/tree/develop/docs/spec/ibc? This was the original work along these lines from around 2 years ago IIRC. Should be in production soon if they meet their launch schedule. I'd appreciate a comparison with tradecoin and an analysis of what trade-in does differently. -- Jehan Tremback jehan@altheamesh.com On Sun, Jun 3, 2018, at 10:12 AM, Jon Crowcroft wrote: > looks sane (as did interledger) but we're missing (I think, but may be > I missed it too) one of the big challenges for this compared with > scaling (which is what you have to address in internetworking stuff > whether subnetworks with IP or IGPs with BGP, or serice+content with > WWW - that's a fundamentally difficult piece of distributed ledgers- > consistency>=20 > one thing the e2e model did for thinking (amongst many) was to think > in an intensely relaxed way about consistency - IP doesn't care if the > source is still where it was when the packet reaches the destination > (or even first hop router. BGP doesn't care (much) about IGP > convergance when announcing (or withdrawing) prefixes and (most) AS > paths.. WWW doesn't care if the remote page (server, site or content) > are there when you add a URL to your site - all this is "fixed up > later" by some eventual consistency protocol (in IPs case, TCP; in > the IGP/BGPs case the linkstate and path vector and a lot of magic > pixie dust and luck; in the WWW case, search/rank&shame and later > maintenance) ->=20 > so for inter-ledger type thinking, we're connecting systems that > fundamentally care about consistency - but define its eventuality > differently - so a basic building block of an interoperabilty or inter- > domain protocol would be to convey (and somehow reconcile) that > variation in notion of how long before we agree about an append in > domain 1, when were' 5 ledger domain hops away...>=20 > which reminds me, am I allowed to coin that term "ledgerdomain" ? :-)>=20 > On Sun, Jun 3, 2018 at 2:51 PM, Thomas Hardjono > wrote:>>=20 >> Here is a question I'd like to throw out to this community regarding >> "interoperable blockchain systems" -- a topic which will undoubtedly >> come to the forefront (assuming it doesn't get drowned-out or killed >> by the barrage of hype about BC):>>=20 >> -- Minimal assumption: What is the minimal assumption for >> interoperable blockchain systems with regards to the notion of >> transaction units. In other words, what is the =E2=80=9Cdatagram=E2=80= =9D equivalent >> of transactions =E2=80=93 namely the transaction unit that is semantica= lly >> understandable (processable) by multiple different blockchain >> systems.>>=20 >> This is a question we posed in our recent discussion paper: >>=20 >> https://arxiv.org/pdf/1805.05934.pdf >>=20 >> Would love to get your thoughts on this "datagram" equivalent >> question (or if this framework of thought is even the correct one).>>=20 >>=20 >> Best >>=20 >>=20 >> -- thomas --=20 >>=20 >> _______________________________________________ >> Din mailing list >> Din@irtf.org >> https://www.irtf.org/mailman/listinfo/din > _________________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din --_----------=_152806260514871855 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
No citation of https://github.com/cosmos/cosmos-sdk/tree/d= evelop/docs/spec/ibc? This was the original work along these lines from= around 2 years ago IIRC. Should be in production soon if they meet their l= aunch schedule. I'd appreciate a comparison with tradecoin and an analysis = of what trade-in does differently.

--
  Jehan Tremback
  jehan@altheamesh.com



On Sun, Jun 3, 2018, at 10:12 AM, Jon Crowcroft wrote:
looks sane (as did interled= ger) but we're missing (I think, but may be I missed it too) one of the big= challenges for this compared with scaling (which is what you have to addre= ss in internetworking stuff whether subnetworks with IP or IGPs with BGP, o= r serice+content with WWW - that's a fundamentally difficult piece of distr= ibuted ledgers- consistency

one thing the e2e model did for thinking (amongst many) was to think i= n an intensely relaxed way about consistency - IP doesn't care if the sourc= e is still where it was when the packet reaches the destination (or even fi= rst hop router. BGP doesn't care (much) about IGP convergance when announci= ng (or withdrawing) prefixes and (most) AS paths.. WWW doesn't care if the = remote page (server, site or content) are there when you add a URL to your = site - all this is "fixed up later" by some eventual consistency protocol (= in IPs case, TCP;  in the IGP/BGPs case the linkstate and path vector = and a lot of magic pixie dust and luck; in the WWW case, search/rank&sh= ame and later maintenance) -

so for inter-ledger type thinking, we're connecting systems that funda= mentally care about consistency - but define its eventuality differently - = so a basic building block of an interoperabilty or inter-domain protocol wo= uld be to convey (and somehow reconcile) that variation in notion of how lo= ng before we agree about an append in domain 1, when were' 5 ledger domain = hops away...

which reminds me, am I allowed to coin that term "ledgerdomain" ? :-)<= br>

On Sun, Jun 3, 2018 at 2:51 PM, Th= omas Hardjono <har= djono@mit.edu> wrote:

Here is a question I'd like to throw out to this community regarding "= interoperable blockchain systems" -- a topic which will undoubtedly come to= the forefront (assuming it doesn't get drowned-out or killed by the barrag= e of hype about BC):

-- Minimal assumption: What is the minimal assumption for interoperab= le blockchain systems with regards to the notion of transaction units. In o= ther words, what is the =E2=80=9Cdatagram=E2=80=9D equivalent of transactio= ns =E2=80=93 namely the transaction unit that is semantically understandabl= e (processable) by multiple different blockchain systems.

This is a question we posed in our recent discussion paper:


Would love to get your thoughts on this "datagram" equivalent questio= n (or if this framework of thought is even the correct one).


Best


-- thomas --

_______________________________________________
Din mailing list
_______________________________________________
Din mailing list

--_----------=_152806260514871855-- From nobody Mon Jun 4 00:19:51 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5161241F8 for ; Mon, 4 Jun 2018 00:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bZRmE0TsLwm5 for ; Mon, 4 Jun 2018 00:19:47 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B61012421A for ; Mon, 4 Jun 2018 00:19:46 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id d8-v6so10805023wro.4 for ; Mon, 04 Jun 2018 00:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kwLLxdflOqhzvZgUUMeydWbeU6J/fWXtSjNDIqxdIW8=; b=l+7jHXVugkl5gPCV6R9MhmR1OlFyRsr8PN/YT8RE+WXGC2joYtSmeIWTAohbydiUTW OZGtXJrP2KLVpbomZITFyVn+my8IEp2VZl/2AVEPHPE5IpxC5Myi83GAAW70FfhyjL0X x64YYlYiqePLB79i7XY4fWO20GiU1tGKPqDTxmUbeCbvPYxSS99CWRYJ8cc2xLYnzbYj 6E12DvNb0B5eVzzI4V3IB29kHaF+LGn2hzy2lmRhhf/QaL8kabCv13S7Y+zc2onhMEWN HIHuobTV/2GYhpaiMEhY8ZWw4idjmydeFUsGf/sKgTonk6UKz1WlNzJUdJPg36U/kSuD ecIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kwLLxdflOqhzvZgUUMeydWbeU6J/fWXtSjNDIqxdIW8=; b=b5ufGfzfQDv0S4nM3/B+OasS6ukwJgGpt42ACUbVjWH1sVmgNezNgSWJ4nl0gsVU+6 QQuxiUhzVuiZjmvhlaUN2NIJn6WAok2+l37UeurEcP2v/EXo6iObOPFRH/0qqr/9ajbU iVRtP390UEAJduYgsM6+DqtkmFvOx2IxzEIHS1EAp/wVvrSfmx+3TPEly19XmAdJpQgk 2ghNPbXvhG2d9/mSYFhiQ8j2h/bIUBDLBbg0qTMnwdgytEiIW0ZE1bmkKhLCfKIdCI4R 3V/h+6yckbg/h+Rq+nHNWuA2JKRIsadbYKLgZPtaACgnVykfvWXNkgHGjOMjzLitCnQz Gaiw== X-Gm-Message-State: ALKqPwczK6E3ANTUciU5D6Ra8diOrr6oByXA8oQ6ndY+0TUiR+02HzvU 5huSKksdAr2qU4l5w37v1sYCzJgqe8g7aikpCj0= X-Google-Smtp-Source: ADUXVKJqcHjELLxwDs9kM04uQbbB2OgyX4/S12jE/tCpl5Cgjt3fB5MNYFlIuBAJo9ADsEdFxaEWuX81qznwtJXS68o= X-Received: by 2002:adf:e084:: with SMTP id c4-v6mr14696265wri.199.1528096785244; Mon, 04 Jun 2018 00:19:45 -0700 (PDT) MIME-Version: 1.0 Sender: crowcroft@gmail.com Received: by 2002:a1c:589:0:0:0:0:0 with HTTP; Mon, 4 Jun 2018 00:19:43 -0700 (PDT) In-Reply-To: <1528062605.1487185.1394957608.1F05953C@webmail.messagingengine.com> References: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu> <1528062605.1487185.1394957608.1F05953C@webmail.messagingengine.com> From: Jon Crowcroft Date: Mon, 4 Jun 2018 08:19:43 +0100 X-Google-Sender-Auth: ReG9-ITI9EUAjC_MdgAKEUHsk_I Message-ID: To: Jehan Tremback Cc: din@irtf.org Content-Type: multipart/alternative; boundary="0000000000001124f1056dcbc287" Archived-At: Subject: Re: [Din] Minimal assumption for interoperable blockchain systems X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 07:19:50 -0000 --0000000000001124f1056dcbc287 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable i hadn't been tracking where the tendermint stuff had been going - in your current ibc spec, you implement causal ordering (It looks pretty much like virtual synchrony, no?) - this is fine in terms of semantics, but i'm worred about (as per my prev. ressponse) scalability.... On Sun, Jun 3, 2018 at 10:50 PM, Jehan Tremback wrote: > No citation of https://github.com/cosmos/cosmos-sdk/tree/develop/docs/ > spec/ibc? This was the original work along these lines from around 2 > years ago IIRC. Should be in production soon if they meet their launch > schedule. I'd appreciate a comparison with tradecoin and an analysis of > what trade-in does differently. > > -- > Jehan Tremback > jehan@altheamesh.com > > > > On Sun, Jun 3, 2018, at 10:12 AM, Jon Crowcroft wrote: > > looks sane (as did interledger) but we're missing (I think, but may be I > missed it too) one of the big challenges for this compared with scaling > (which is what you have to address in internetworking stuff whether > subnetworks with IP or IGPs with BGP, or serice+content with WWW - that's= a > fundamentally difficult piece of distributed ledgers- consistency > > one thing the e2e model did for thinking (amongst many) was to think in a= n > intensely relaxed way about consistency - IP doesn't care if the source i= s > still where it was when the packet reaches the destination (or even first > hop router. BGP doesn't care (much) about IGP convergance when announcing > (or withdrawing) prefixes and (most) AS paths.. WWW doesn't care if the > remote page (server, site or content) are there when you add a URL to you= r > site - all this is "fixed up later" by some eventual consistency protocol > (in IPs case, TCP; in the IGP/BGPs case the linkstate and path vector an= d > a lot of magic pixie dust and luck; in the WWW case, search/rank&shame an= d > later maintenance) - > > so for inter-ledger type thinking, we're connecting systems that > fundamentally care about consistency - but define its eventuality > differently - so a basic building block of an interoperabilty or > inter-domain protocol would be to convey (and somehow reconcile) that > variation in notion of how long before we agree about an append in domain > 1, when were' 5 ledger domain hops away... > > which reminds me, am I allowed to coin that term "ledgerdomain" ? :-) > > On Sun, Jun 3, 2018 at 2:51 PM, Thomas Hardjono wrote: > > > Here is a question I'd like to throw out to this community regarding > "interoperable blockchain systems" -- a topic which will undoubtedly come > to the forefront (assuming it doesn't get drowned-out or killed by the > barrage of hype about BC): > > -- Minimal assumption: What is the minimal assumption for interoperable > blockchain systems with regards to the notion of transaction units. In > other words, what is the =E2=80=9Cdatagram=E2=80=9D equivalent of transac= tions =E2=80=93 namely the > transaction unit that is semantically understandable (processable) by > multiple different blockchain systems. > > This is a question we posed in our recent discussion paper: > > https://arxiv.org/pdf/1805.05934.pdf > > Would love to get your thoughts on this "datagram" equivalent question (o= r > if this framework of thought is even the correct one). > > > Best > > > -- thomas -- > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > > *_______________________________________________* > Din mailing list > Din@irtf.org > https://www.irtf..org/mailman/listinfo/din > > > > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > > --0000000000001124f1056dcbc287 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
i hadn't been tracking where the tendermint stuff had = been going - in your current ibc spec, you implement causal ordering (It lo= oks pretty much like virtual synchrony, no?) - this is fine in terms of sem= antics, but i'm worred about (as per my prev. ressponse) scalability...= .

On Sun, Ju= n 3, 2018 at 10:50 PM, Jehan Tremback <jehan@altheamesh.com> wrote:
No citation of=C2=A0https://github.com/cosmos/= cosmos-sdk/tree/develop/docs/spec/ibc? This was the original = work along these lines from around 2 years ago IIRC. Should be in productio= n soon if they meet their launch schedule. I'd appreciate a comparison = with tradecoin and an analysis of what trade-in does differently.

--
=C2=A0 Jehan Tremback
=C2=A0 jehan@altheamesh.com



On Sun, Jun 3, 2018, at 10:12 AM, Jon Crowcroft wrote:
loo= ks sane (as did interledger) but we're missing (I think, but may be I m= issed it too) one of the big challenges for this compared with scaling (whi= ch is what you have to address in internetworking stuff whether subnetworks= with IP or IGPs with BGP, or serice+content with WWW - that's a fundam= entally difficult piece of distributed ledgers- consistency

one thing the e2e model did for thinking (amongst many) was to = think in an intensely relaxed way about consistency - IP doesn't care i= f the source is still where it was when the packet reaches the destination = (or even first hop router. BGP doesn't care (much) about IGP converganc= e when announcing (or withdrawing) prefixes and (most) AS paths.. WWW doesn= 't care if the remote page (server, site or content) are there when you= add a URL to your site - all this is "fixed up later" by some ev= entual consistency protocol (in IPs case, TCP;=C2=A0 in the IGP/BGPs case t= he linkstate and path vector and a lot of magic pixie dust and luck; in the= WWW case, search/rank&shame and later maintenance) -

so for inter-ledger type thinking, we're connecting systems that f= undamentally care about consistency - but define its eventuality differentl= y - so a basic building block of an interoperabilty or inter-domain protoco= l would be to convey (and somehow reconcile) that variation in notion of ho= w long before we agree about an append in domain 1, when were' 5 ledger= domain hops away...

which reminds me, am I allowed to coin that term "ledgerdomain&qu= ot; ? :-)

On Sun, Jun 3, 2018 at 2:51 PM, Thomas Hardjono <hardjono@mit.edu= > wrote:

Here is a question I'd like to throw out to this community regardi= ng "interoperable blockchain systems" -- a topic which will undou= btedly come to the forefront (assuming it doesn't get drowned-out or ki= lled by the barrage of hype about BC):

-- Minimal assumption: What is the minimal assumption for interoperab= le blockchain systems with regards to the notion of transaction units. In o= ther words, what is the =E2=80=9Cdatagram=E2=80=9D equivalent of transactio= ns =E2=80=93 namely the transaction unit that is semantically understandabl= e (processable) by multiple different blockchain systems.

This is a question we posed in our recent discussion paper:


Would love to get your thoughts on this "datagram" equivale= nt question (or if this framework of thought is even the correct one).
<= /div>


Best


-- thomas --

_______________________________________________
Din mailing list
_______________________________________________
Din mailing list


_______________________________________________
Din mailing list
Din@irtf.org
https://www.irtf.org/mailman/listinfo/din


--0000000000001124f1056dcbc287-- From nobody Mon Jun 4 05:20:50 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F79812D889 for ; Mon, 4 Jun 2018 05:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 G-vOAz-VqG8w for ; Mon, 4 Jun 2018 05:20:45 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB0F126DFF for ; Mon, 4 Jun 2018 05:20:45 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id p185-v6so5500264itp.4 for ; Mon, 04 Jun 2018 05:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Rnjsyca93mE1kN8X7V83AfkJDh1s9NxW8AjkjvXzPK8=; b=D/R6eYjNBpPfzCreO2b1B5+W7w7RAbcyZEa7+Xa0oPElmcZCpuPkzd3Cm0UPXNaY6A 1TFOHoYU8RIX0RpXgJNfTIB0C6aGOFm4xHB6Si2t2hx7a6Oc9s4DwHtkDCxQukA91t5N 2fmFKbG+VXOC0ONexMorntjXGH7FcgGNNjcOB34cvv1UQ+bfeuxTs4FTeV3ZA0MfxUpj 0MZ3oCUrgLvhkV+s3i2jU8QFuXCesd6OGpG5QlnQjSkSHpr4ShzpOtK5G2GzuddPGFq4 ZgvZTX+8lWsNXvU0bCFDxGlWc2Aq8XDgfgI0KLUICzsORGOmqX6p0lRVsr/zdJVkvuzc Pgaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Rnjsyca93mE1kN8X7V83AfkJDh1s9NxW8AjkjvXzPK8=; b=IFR9cznQ4Gxo+yFBYgBslv8/QTPMb2i58g8ZukOXcvyv+dsgcZL95t5eRR1nt2oxKn 1QrpeDzz57O15zTxRMXP6nOBPaExRoohrWYwQxCmjASWya4vOryyPFQF7lGSstXbBsO3 snc5dnA4ML8+uoFedGE94KsLJKB1qpGzGzyEoVnd79cBiQ50m73d9V6jb/Dha3SsIH5N yN8qcC0LBwGMN9rCSGBFDFiw9/FnjDWPilw8B9Fq5S7cEfEZLFTnnL9ia5PvB9wx7UEr dRhXVkqxgMMeHle8HtT/TEIrSwQ25vvuETJLLflL/HE1R2JoMod4QE2E3O8p8zDl4Z0M poYw== X-Gm-Message-State: ALKqPwc5ToMucQUW9O2C93JAo8GPCSwfjg95UrLBCvupdVBSJKvte8wi UKRU1QOR5UTDF6uNPhjl9nGogW2S3Odl6rFvLkU= X-Google-Smtp-Source: ADUXVKJhXpeaGiGJ6V9R54zfXtHj/kGcSiTL6DZlBcPGeXQziqUrSDoQ7phV+S0/a3OCvRWmT0gH0xtyltR4BSKLOfY= X-Received: by 2002:a24:7c13:: with SMTP id a19-v6mr13898131itd.81.1528114844578; Mon, 04 Jun 2018 05:20:44 -0700 (PDT) MIME-Version: 1.0 Sender: arjuna.sathiaseelan@gmail.com Received: by 2002:a4f:4543:0:0:0:0:0 with HTTP; Mon, 4 Jun 2018 05:20:43 -0700 (PDT) In-Reply-To: References: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu> From: Arjuna Sathiaseelan Date: Mon, 4 Jun 2018 13:20:43 +0100 X-Google-Sender-Auth: YB80dizsL72E6_nqPteQQKpi58Y Message-ID: To: Jon Crowcroft Cc: Thomas Hardjono , "din@irtf.org" Content-Type: multipart/alternative; boundary="0000000000007cbc1b056dcff6bf" Archived-At: Subject: Re: [Din] Minimal assumption for interoperable blockchain systems X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 12:20:48 -0000 --0000000000007cbc1b056dcff6bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable i think its not just the tech (consistency) - also handling governance across DAOs is a major issue.. regards On 3 June 2018 at 15:12, Jon Crowcroft wrote: > looks sane (as did interledger) but we're missing (I think, but may be I > missed it too) one of the big challenges for this compared with scaling > (which is what you have to address in internetworking stuff whether > subnetworks with IP or IGPs with BGP, or serice+content with WWW - that's= a > fundamentally difficult piece of distributed ledgers- consistency > > one thing the e2e model did for thinking (amongst many) was to think in a= n > intensely relaxed way about consistency - IP doesn't care if the source i= s > still where it was when the packet reaches the destination (or even first > hop router. BGP doesn't care (much) about IGP convergance when announcing > (or withdrawing) prefixes and (most) AS paths.. WWW doesn't care if the > remote page (server, site or content) are there when you add a URL to you= r > site - all this is "fixed up later" by some eventual consistency protocol > (in IPs case, TCP; in the IGP/BGPs case the linkstate and path vector an= d > a lot of magic pixie dust and luck; in the WWW case, search/rank&shame an= d > later maintenance) - > > so for inter-ledger type thinking, we're connecting systems that > fundamentally care about consistency - but define its eventuality > differently - so a basic building block of an interoperabilty or > inter-domain protocol would be to convey (and somehow reconcile) that > variation in notion of how long before we agree about an append in domain > 1, when were' 5 ledger domain hops away... > > which reminds me, am I allowed to coin that term "ledgerdomain" ? :-) > > On Sun, Jun 3, 2018 at 2:51 PM, Thomas Hardjono wrote: > >> >> Here is a question I'd like to throw out to this community regarding >> "interoperable blockchain systems" -- a topic which will undoubtedly com= e >> to the forefront (assuming it doesn't get drowned-out or killed by the >> barrage of hype about BC): >> >> -- Minimal assumption: What is the minimal assumption for interoperable >> blockchain systems with regards to the notion of transaction units. In >> other words, what is the =E2=80=9Cdatagram=E2=80=9D equivalent of transa= ctions =E2=80=93 namely the >> transaction unit that is semantically understandable (processable) by >> multiple different blockchain systems. >> >> This is a question we posed in our recent discussion paper: >> >> https://arxiv.org/pdf/1805.05934.pdf >> >> Would love to get your thoughts on this "datagram" equivalent question >> (or if this framework of thought is even the correct one). >> >> >> Best >> >> >> -- thomas -- >> >> _______________________________________________ >> Din mailing list >> Din@irtf.org >> https://www.irtf.org/mailman/listinfo/din >> > > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > > --=20 Arjuna Sathiaseelan | http://sathiaseelan.org --0000000000007cbc1b056dcff6bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
i think its not just the tech (consistency) - also handlin= g governance across DAOs is a major issue..

regards

On 3 June = 2018 at 15:12, Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk><= /span> wrote:
looks sane= (as did interledger) but we're missing (I think, but may be I missed i= t too) one of the big challenges for this compared with scaling (which is w= hat you have to address in internetworking stuff whether subnetworks with I= P or IGPs with BGP, or serice+content with WWW - that's a fundamentally= difficult piece of distributed ledgers- consistency

one= thing the e2e model did for thinking (amongst many) was to think in an int= ensely relaxed way about consistency - IP doesn't care if the source is= still where it was when the packet reaches the destination (or even first = hop router. BGP doesn't care (much) about IGP convergance when announci= ng (or withdrawing) prefixes and (most) AS paths.. WWW doesn't care if = the remote page (server, site or content) are there when you add a URL to y= our site - all this is "fixed up later" by some eventual consiste= ncy protocol (in IPs case, TCP;=C2=A0 in the IGP/BGPs case the linkstate an= d path vector and a lot of magic pixie dust and luck; in the WWW case, sear= ch/rank&shame and later maintenance) -

so for = inter-ledger type thinking, we're connecting systems that fundamentally= care about consistency - but define its eventuality differently - so a bas= ic building block of an interoperabilty or inter-domain protocol would be t= o convey (and somehow reconcile) that variation in notion of how long befor= e we agree about an append in domain 1, when were' 5 ledger domain hops= away...

which reminds me, am I allowed to coin th= at term "ledgerdomain" ? :-)

On= Sun, Jun 3, 2018 at 2:51 PM, Thomas Hardjono <hardjono@mit.edu> wrote:

Here is a question I'd like to throw out to this community regarding &q= uot;interoperable blockchain systems" -- a topic which will undoubtedl= y come to the forefront (assuming it doesn't get drowned-out or killed = by the barrage of hype about BC):

-- Minimal assumption: What is the minimal assumption for interoperable blo= ckchain systems with regards to the notion of transaction units. In other w= ords, what is the =E2=80=9Cdatagram=E2=80=9D equivalent of transactions =E2= =80=93 namely the transaction unit that is semantically understandable (pro= cessable) by multiple different blockchain systems.

This is a question we posed in our recent discussion paper:

https://arxiv.org/pdf/1805.05934.pdf

Would love to get your thoughts on this "datagram" equivalent que= stion (or if this framework of thought is even the correct one).


Best


-- thomas --

_______________________________________________
Din mailing list
Din@irtf.org
https://www.irtf.org/mailman/listinfo/din


_______________________________________________
Din mailing list
Din@irtf.org
https://www.irtf.org/mailman/listinfo/din




--
=

Arjuna Sathiasee= lan |=C2=A0http://sat= hiaseelan.org

--0000000000007cbc1b056dcff6bf-- From nobody Mon Jun 4 12:17:53 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4539130DDB for ; Mon, 4 Jun 2018 12:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 lXVHCKrivZyB for ; Mon, 4 Jun 2018 12:17:44 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F93E130DCE for ; Mon, 4 Jun 2018 12:17:44 -0700 (PDT) X-AuditID: 12074424-1bdff700000014b0-f8-5b1590572617 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 95.45.05296.750951B5; Mon, 4 Jun 2018 15:17:43 -0400 (EDT) Received: from outgoing-exchange-3.mit.edu (OUTGOING-EXCHANGE-3.MIT.EDU [18.9.28.13]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w54JHgYo012073; Mon, 4 Jun 2018 15:17:42 -0400 Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id w54JHLqe004464; Mon, 4 Jun 2018 15:17:40 -0400 Received: from W92EXCAS23.exchange.mit.edu (18.7.71.38) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 4 Jun 2018 15:17:15 -0400 Received: from OC11EXPO33.exchange.mit.edu ([169.254.1.177]) by w92excas23.exchange.mit.edu ([18.7.71.38]) with mapi id 14.03.0352.000; Mon, 4 Jun 2018 15:17:34 -0400 From: Thomas Hardjono To: "jon.crowcroft@cl.cam.ac.uk" CC: "din@irtf.org" Thread-Topic: [Din] Minimal assumption for interoperable blockchain systems Thread-Index: AQHT+0CmDYm4GElA7Ua0jKaUNEZ41qRO1nUAgAFpmmc= Date: Mon, 4 Jun 2018 19:17:33 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342AFD22E716@OC11EXPO33.exchange.mit.edu> References: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.7.71.71] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDKsWRmVeSWpSXmKPExsUixG6nohs+QTTa4NZrOYulH/eyWDy4+ITJ gclja+txFo/JGw+zBTBFcdmkpOZklqUW6dslcGVsn36DqeC9YsWcxzfYGxjPS3cxcnBICJhI fDkHZHJxCAksZpI42L+RHcLZzyixfGY/E4RzlFHiz5Q2qMx2IGfiPpYuRk4gZxWjxL/v7iA2 m4CGRNuPXnYQW0TAVuLgxcNgNrOAokTX5CYmEFtYwEvi1L2VTBA13hKffp1nhLCtJA59+Q5m swioSJycfhKshlcgSOL+io9sEIunM0r8/n2aDSTBKRAosXfSBLAGRgExie+n1jBBLBOXuPVk PpgtISAosWj2HmYIW0zi366HbBC2nMSE3xOhjjOQeH9uPjOErS2xbOFrZojFghInZz5hmcAo MQvJ2FlIWmYhaZmFpGUBI8sqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXXO93MwSvdSU0k2M4Ch0 UdnB2N3jfYhRgINRiYdXw0o0Wog1say4MvcQoyQHk5Iob3waUIgvKT+lMiOxOCO+qDQntfgQ owQHs5II7+kCoBxvSmJlVWpRPkxKmoNFSZw3dxFjtJBAemJJanZqakFqEUxWhoNDSYK3vR+o UbAoNT21Ii0zpwQhzcTBCTKcB2j4NJAa3uKCxNzizHSI/ClGY447bT09zBwd76f0MAux5OXn pUqJ85qDlAqAlGaU5sFNgyRST/5XjOJAzwnzPu0DquIBJmG4ea+AVjEBrXpWIQyyqiQRISXV wNjx4p6KQMbjlavf21yLmx29geVdR3qOwNG1KyIjpc1bpn74++HlFs7FlmZ67t2zi7m/LWIJ +VQqoySvmVX6P2+/w5mOM4xmJpLtHmz8UT8dn9i6/reoMWt9rKC07tGE/V/VzV5qO75UtWH9 3reYa92FWxohNfd11WJvSb3y5VnO3DNzwpmSpUosxRmJhlrMRcWJAJOX5eR/AwAA Archived-At: Subject: Re: [Din] Minimal assumption for interoperable blockchain systems X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 19:17:52 -0000 >>> From: crowcroft@gmail.com [crowcroft@gmail.com] >>> ... >>> so for inter-ledger type thinking, we're connecting systems >>> that fundamentally care about consistency - but define its=20 >>> eventuality differently - so a basic building block of an=20 >>> interoperabilty or inter-domain protocol would be to=20 >>> convey (and somehow reconcile) that variation in notion=20 >>> of how long before we agree about an append in domain 1,=20 >>> when were' 5 ledger domain hops away... Jon, this is excellent. I've been struggling to find words to use for what you refer to as "consist= ency", particularly with regards to the end-state ("eventuality"). I'm assuming that at a high level, the "eventuality" is defined as some dat= a-string being recorded on the ledger of a BC (i.e. all distributed P2P nod= es of the BC). As you correctly intuited, the consistency-problem is more difficult for cr= oss-ledger transactions. A simple example with 1 entity only: Alice wants to "move" her registered = land-deed from BC1 to BC2 (direct, no hops).=20 -- How many transactions does Alice's Application need to transmit? (one on= ly to BC1; or one each to BC1 and BC2; or three: BC1; BC2 and then BC1 agai= n). Any thoughts how how to define "consistency" more specific/technically? -- thomas --=20 ________________________________________ From: crowcroft@gmail.com [crowcroft@gmail.com] on behalf of Jon Crowcroft = [jon.crowcroft@cl.cam.ac.uk] Sent: Sunday, June 03, 2018 10:12 AM To: Thomas Hardjono Cc: din@irtf.org Subject: Re: [Din] Minimal assumption for interoperable blockchain systems looks sane (as did interledger) but we're missing (I think, but may be I mi= ssed it too) one of the big challenges for this compared with scaling (whic= h is what you have to address in internetworking stuff whether subnetworks = with IP or IGPs with BGP, or serice+content with WWW - that's a fundamental= ly difficult piece of distributed ledgers- consistency one thing the e2e model did for thinking (amongst many) was to think in an = intensely relaxed way about consistency - IP doesn't care if the source is = still where it was when the packet reaches the destination (or even first h= op router. BGP doesn't care (much) about IGP convergance when announcing (o= r withdrawing) prefixes and (most) AS paths. WWW doesn't care if the remote= page (server, site or content) are there when you add a URL to your site -= all this is "fixed up later" by some eventual consistency protocol (in IPs= case, TCP; in the IGP/BGPs case the linkstate and path vector and a lot o= f magic pixie dust and luck; in the WWW case, search/rank&shame and later m= aintenance) - so for inter-ledger type thinking, we're connecting systems that fundamenta= lly care about consistency - but define its eventuality differently - so a = basic building block of an interoperabilty or inter-domain protocol would b= e to convey (and somehow reconcile) that variation in notion of how long be= fore we agree about an append in domain 1, when were' 5 ledger domain hops = away... which reminds me, am I allowed to coin that term "ledgerdomain" ? :-) On Sun, Jun 3, 2018 at 2:51 PM, Thomas Hardjono > wrote: Here is a question I'd like to throw out to this community regarding "inter= operable blockchain systems" -- a topic which will undoubtedly come to the = forefront (assuming it doesn't get drowned-out or killed by the barrage of = hype about BC): -- Minimal assumption: What is the minimal assumption for interoperable blo= ckchain systems with regards to the notion of transaction units. In other w= ords, what is the =93datagram=94 equivalent of transactions =96 namely the = transaction unit that is semantically understandable (processable) by multi= ple different blockchain systems. This is a question we posed in our recent discussion paper: https://arxiv.org/pdf/1805.05934.pdf Would love to get your thoughts on this "datagram" equivalent question (or = if this framework of thought is even the correct one). Best -- thomas -- _______________________________________________ Din mailing list Din@irtf.org https://www.irtf.org/mailman/listinfo/din= From nobody Mon Jun 4 12:29:39 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388DD130DCC for ; Mon, 4 Jun 2018 12:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com 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 o_yBDCbXKJgR for ; Mon, 4 Jun 2018 12:29:35 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E1C130DC0 for ; Mon, 4 Jun 2018 12:29:35 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9DEA121E3E for ; Mon, 4 Jun 2018 15:29:34 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Mon, 04 Jun 2018 15:29:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ZRwjEC HtNyWsFCp+tHkRm26lN3BEYEm+PWayNCGjldY=; b=NzP6nuVQDqplawrPG7t6o2 1ZsJxYwW8nWcuUaI0WbcV+fGJLvFRH6C7nnPe9U5YSOFJgL5c98AYDLtN4t1o0qf x1Tw6trpTDx/CWeMJHamRwx3XI/plwXIu0Ma/l+MJGmETSB7u68jhfZNg96UlvIs dAllyJw0zi/88C097RK0ZjptitJJO1irmsmsDRaJoTK6cFtft4X41kH1fqM7wUVi 68XCgq/Zh5aLcZ7pUaWrJMmO9bjOGi2E7m/Az//SGT1Ia2/E2XmCXT8OzigBgA/H Ongdq4ZvpSly7bKw6B7aOsqUGC7/eAxJR+/pl/pXe3xkCmJQ0tdx2+QQREy5zNRA == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3B23E419B; Mon, 4 Jun 2018 15:29:34 -0400 (EDT) Message-Id: <1528140574.155626.1396147592.6E286D5C@webmail.messagingengine.com> From: Jehan Tremback To: din@irtf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15281405741556261" X-Mailer: MessagingEngine.com Webmail Interface - ajax-fb4a77ea Date: Mon, 04 Jun 2018 15:29:34 -0400 In-Reply-To: <5E393DF26B791A428E5F003BB6C5342AFD22E716@OC11EXPO33.exchange.mit.edu> References: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu> <5E393DF26B791A428E5F003BB6C5342AFD22E716@OC11EXPO33.exchange.mit.edu> Archived-At: Subject: Re: [Din] Minimal assumption for interoperable blockchain systems X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 19:29:38 -0000 This is a multi-part message in MIME format. --_----------=_15281405741556261 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I=E2=80=99m not on the cosmos team, although I do know them. I=E2=80=99ll t= ry to see if one of their team members have time to join this discussion. I don=E2=80=99t have the expertise to do either protocol justice. -- Jehan Tremback jehan@altheamesh.com On Mon, Jun 4, 2018, at 3:17 PM, Thomas Hardjono wrote: > > >>> From: crowcroft@gmail.com [crowcroft@gmail.com] > >>> ... > >>> so for inter-ledger type thinking, we're connecting systems > >>> that fundamentally care about consistency - but define its > >>> eventuality differently - so a basic building block of an > >>> interoperabilty or inter-domain protocol would be to > >>> convey (and somehow reconcile) that variation in notion > >>> of how long before we agree about an append in domain 1, > >>> when were' 5 ledger domain hops away... > > > Jon, this is excellent. > > I've been struggling to find words to use for what you refer to as > "consistency", particularly with regards to the end-state > ("eventuality"). > > I'm assuming that at a high level, the "eventuality" is defined as > some> data-string being recorded on the ledger of a BC (i.e. all distribu= ted> P2P nodes of the BC). > > As you correctly intuited, the consistency-problem is more > difficult for> cross-ledger transactions. > > A simple example with 1 entity only: Alice wants to "move" her > registered land-deed from BC1 to BC2 (direct, no hops). > > -- How many transactions does Alice's Application need to > transmit? (one> only to BC1; or one each to BC1 and BC2; or three: BC1; B= C2 and > then BC1> again). > > Any thoughts how how to define "consistency" more > specific/technically?> > > -- thomas -- > > > > ________________________________________ > From: crowcroft@gmail.com [crowcroft@gmail.com] on behalf of Jon > Crowcroft [jon.crowcroft@cl.cam.ac.uk] > Sent: Sunday, June 03, 2018 10:12 AM > To: Thomas Hardjono > Cc: din@irtf.org > Subject: Re: [Din] Minimal assumption for interoperable blockchain > systems > > looks sane (as did interledger) but we're missing (I think, but > may be I> missed it too) one of the big challenges for this compared with > scaling> (which is what you have to address in internetworking stuff whet= her > subnetworks with IP or IGPs with BGP, or serice+content with WWW - > that's a fundamentally difficult piece of distributed ledgers- > consistency > > one thing the e2e model did for thinking (amongst many) was to > think in> an intensely relaxed way about consistency - IP doesn't care if= the > source is still where it was when the packet reaches the > destination (or> even first hop router. BGP doesn't care (much) about IGP= convergance > when announcing (or withdrawing) prefixes and (most) AS paths. WWW > doesn't care if the remote page (server, site or content) are > there when> you add a URL to your site - all this is "fixed up later" by = some > eventual consistency protocol (in IPs case, TCP; in the IGP/BGPs case> t= he linkstate and path vector and a lot of magic pixie dust and > luck; in> the WWW case, search/rank&shame and later maintenance) - > > so for inter-ledger type thinking, we're connecting systems that > fundamentally care about consistency - but define its eventuality > differently - so a basic building block of an interoperabilty or inter-> = domain protocol would be to convey (and somehow reconcile) that > variation in notion of how long before we agree about an append in > domain 1, when were' 5 ledger domain hops away... > > which reminds me, am I allowed to coin that term "ledgerdomain" ? :-)> > On Sun, Jun 3, 2018 at 2:51 PM, Thomas Hardjono > > wrote: > > Here is a question I'd like to throw out to this community regarding > "interoperable blockchain systems" -- a topic which will undoubtedly > come to the forefront (assuming it doesn't get drowned-out or > killed by> the barrage of hype about BC): > > -- Minimal assumption: What is the minimal assumption for > interoperable> blockchain systems with regards to the notion of transacti= on units. In> other words, what is the =E2=80=9Cdatagram=E2=80=9D equivalen= t of transactions > =E2=80=93 namely> the transaction unit that is semantically understandabl= e (processable)> by multiple different blockchain systems. > > This is a question we posed in our recent discussion paper: > > https://arxiv.org/pdf/1805.05934.pdf > > Would love to get your thoughts on this "datagram" equivalent question> (= or if this framework of thought is even the correct one). > > > Best > > > -- thomas -- > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din --_----------=_15281405741556261 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
I=E2=80=99m not on the cosmos team, although I do know them. I= =E2=80=99ll try to see if one of their team members have time to join this = discussion. I don=E2=80=99t have the expertise to do either protocol justic= e.

--
  Jehan Tremback
  jehan@altheamesh.com



On Mon, Jun 4, 2018, at 3:17 PM, Thomas Hardjono wrote:
>
> >>> From: crowcroft@gmail.com [crowcroft@gmail.com]
<= /div>
> >>> ...
> >>> so for inter-ledger type thinking, we're connecting = systems
> >>> that fundamentally care about consistency - but defi= ne its
> >>> eventuality differently - so a basic building block = of an
> >>> interoperabilty or inter-domain protocol would be to=
> >>> convey (and somehow reconcile) that variation in not= ion
> >>> of how long before we agree about an append in domai= n 1,
> >>> when were' 5 ledger domain hops away...
>
>
> Jon, this is excellent.
>
> I've been struggling to find words to use for what you refer to a= s
> "consistency", particularly with regards to the end-state
> ("eventuality").
>
> I'm assuming that at a high level, the "eventuality" is defined a= s some
> data-string being recorded on the ledger of a BC (i.e. all distri= buted
> P2P nodes of the BC).
>
> As you correctly intuited, the consistency-problem is more diffic= ult for
> cross-ledger transactions.
>
> A simple example with 1 entity only:  Alice wants to "move" = her
> registered land-deed from BC1 to BC2 (direct, no hops).
>
> -- How many transactions does Alice's Application need to transmi= t? (one
> only to BC1; or one each to BC1 and BC2; or three: BC1; BC2 and t= hen BC1
> again).
>
> Any thoughts how how to define  "consistency" more specific/= technically?
>
>
> -- thomas --
>
>
>
> ________________________________________
> From: crowcroft@gmail.com [crowcroft@gmail.com] on behalf of Jon<= br>
> Crowcroft [jon.crowcroft@cl.cam.ac.uk]
> Sent: Sunday, June 03, 2018 10:12 AM
> To: Thomas Hardjono
> Cc: din@irtf.org
> Subject: Re: [Din] Minimal assumption for interoperable blockchai= n
> systems
>
> looks sane (as did interledger) but we're missing (I think, but m= ay be I
> missed it too) one of the big challenges for this compared with s= caling
> (which is what you have to address in internetworking stuff wheth= er
> subnetworks with IP or IGPs with BGP, or serice+content with WWW = -
> that's a fundamentally difficult piece of distributed ledgers-
> consistency
>
> one thing the e2e model did for thinking (amongst many) was to th= ink in
> an intensely relaxed way about consistency - IP doesn't care if t= he
> source is still where it was when the packet reaches the destinat= ion (or
> even first hop router. BGP doesn't care (much) about IGP converga= nce
> when announcing (or withdrawing) prefixes and (most) AS paths. WW= W
> doesn't care if the remote page (server, site or content) are the= re when
> you add a URL to your site - all this is "fixed up later" by some=
> eventual consistency protocol (in IPs case, TCP;  in the IGP= /BGPs case
> the linkstate and path vector and a lot of magic pixie dust and l= uck; in
> the WWW case, search/rank&shame and later maintenance) -
<= /div>
>
> so for inter-ledger type thinking, we're connecting systems that<= br>
> fundamentally care about consistency - but define its eventuality=
> differently - so a basic building block of an interoperabilty or = inter-
> domain protocol would be to convey (and somehow reconcile) that
> variation in notion of how long before we agree about an append i= n
> domain 1, when were' 5 ledger domain hops away...
>
> which reminds me, am I allowed to coin that term "ledgerdomain" ?= :-)
>
> On Sun, Jun 3, 2018 at 2:51 PM, Thomas Hardjono
> <hardjono@mit.edu<mailto:hardjono@mit.edu>> wrote:
>
> Here is a question I'd like to throw out to this community regard= ing
> "interoperable blockchain systems" -- a topic which will undoubte= dly
> come to the forefront (assuming it doesn't get drowned-out or kil= led by
> the barrage of hype about BC):
>
> -- Minimal assumption: What is the minimal assumption for interop= erable
> blockchain systems with regards to the notion of transaction unit= s. In
> other words, what is the =E2=80=9Cdatagram=E2=80=9D equivalent of= transactions =E2=80=93 namely
> the transaction unit that is semantically understandable (process= able)
> by multiple different blockchain systems.
>
> This is a question we posed in our recent discussion paper:
>
> https://arxiv.org/pdf/1805.05934.pdf
>
> Would love to get your thoughts on this "datagram" equivalent que= stion
> (or if this framework of thought is even the correct one).
>
>
> Best
>
>
> -- thomas --
>
> _______________________________________________
> Din mailing list
> Din@irtf.org<mailto:Din@irtf.org>
> https://www.irtf.org/mailman/listinfo/din
> _______________________________________________
> Din mailing list
> Din@irtf.org
> https://www.irtf.org/mailman/listinfo/din

--_----------=_15281405741556261-- From nobody Tue Jun 5 07:01:54 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1A2131074 for ; Tue, 5 Jun 2018 07:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 w3VZdhqN-ZAE for ; Tue, 5 Jun 2018 07:01:48 -0700 (PDT) Received: from mta2.cl.cam.ac.uk (mta2.cl.cam.ac.uk [IPv6:2001:630:212:200::25:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D812131055 for ; Tue, 5 Jun 2018 07:01:48 -0700 (PDT) Received: from ely.cl.cam.ac.uk ([2001:630:212:238:230:48ff:fefe:c314]) by mta2.cl.cam.ac.uk with esmtp (Exim 4.86_2) (envelope-from ) id 1fQCWv-0005Th-VA; Tue, 05 Jun 2018 15:01:45 +0100 From: Jon Crowcroft To: Thomas Hardjono cc: "jon.crowcroft@cl.cam.ac.uk" , "din@irtf.org" In-reply-to: <5E393DF26B791A428E5F003BB6C5342AFD22E716@OC11EXPO33.exchange.mit.edu> References: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu>, <5E393DF26B791A428E5F003BB6C5342AFD22E716@OC11EXPO33.exchange.mit.edu> Comments: In-reply-to Thomas Hardjono message dated "Mon, 04 Jun 2018 19:17:33 -0000." MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <5853.1528207305.1@ely.cl.cam.ac.uk> Content-Transfer-Encoding: 8bit Date: Tue, 05 Jun 2018 15:01:45 +0100 Message-Id: Archived-At: Subject: Re: [Din] Minimal assumption for interoperable blockchain systems X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 14:01:51 -0000 strawman - design a standard description for consistency algo used by each BC (there are some semi-formal ways of describing such algos...) form a full interconnect of blochain systems and exchange descriptions which should form a partial order on the graph (guess) compute which interconnects make sense and which ones cannot... proceed.... > >>> From: crowcroft@gmail.com [crowcroft@gmail.com] > >>> ... > >>> so for inter-ledger type thinking, we're connecting systems > >>> that fundamentally care about consistency - but define its > >>> eventuality differently - so a basic building block of an > >>> interoperabilty or inter-domain protocol would be to > >>> convey (and somehow reconcile) that variation in notion > >>> of how long before we agree about an append in domain 1, > >>> when were' 5 ledger domain hops away... > > > Jon, this is excellent. > > I've been struggling to find words to use for what you refer to as > "consistency", particularly with regards to the end-state ("eventuality"). > > I'm assuming that at a high level, the "eventuality" is defined as some > data-string being recorded on the ledger of a BC (i.e. all distributed > P2P nodes of the BC). > > As you correctly intuited, the consistency-problem is more difficult for > cross-ledger transactions. > > A simple example with 1 entity only: Alice wants to "move" her > registered land-deed from BC1 to BC2 (direct, no hops). > > -- How many transactions does Alice's Application need to transmit? (one > only to BC1; or one each to BC1 and BC2; or three: BC1; BC2 and then BC1 > again). > > Any thoughts how how to define "consistency" more specific/technically? > > > -- thomas -- > > > > ________________________________________ > From: crowcroft@gmail.com [crowcroft@gmail.com] on behalf of Jon > Crowcroft [jon.crowcroft@cl.cam.ac.uk] > Sent: Sunday, June 03, 2018 10:12 AM > To: Thomas Hardjono > Cc: din@irtf.org > Subject: Re: [Din] Minimal assumption for interoperable blockchain systems > > looks sane (as did interledger) but we're missing (I think, but may be I > missed it too) one of the big challenges for this compared with scaling > (which is what you have to address in internetworking stuff whether > subnetworks with IP or IGPs with BGP, or serice+content with WWW - that's > a fundamentally difficult piece of distributed ledgers- consistency > > one thing the e2e model did for thinking (amongst many) was to think in > an intensely relaxed way about consistency - IP doesn't care if the > source is still where it was when the packet reaches the destination (or > even first hop router. BGP doesn't care (much) about IGP convergance when > announcing (or withdrawing) prefixes and (most) AS paths. WWW doesn't > care if the remote page (server, site or content) are there when you add > a URL to your site - all this is "fixed up later" by some eventual > consistency protocol (in IPs case, TCP; in the IGP/BGPs case the > linkstate and path vector and a lot of magic pixie dust and luck; in the > WWW case, search/rank&shame and later maintenance) - > > so for inter-ledger type thinking, we're connecting systems that > fundamentally care about consistency - but define its eventuality > differently - so a basic building block of an interoperabilty or > inter-domain protocol would be to convey (and somehow reconcile) that > variation in notion of how long before we agree about an append in domain > 1, when were' 5 ledger domain hops away... > > which reminds me, am I allowed to coin that term "ledgerdomain" ? :-) > > On Sun, Jun 3, 2018 at 2:51 PM, Thomas Hardjono > > wrote: > > Here is a question I'd like to throw out to this community regarding > "interoperable blockchain systems" -- a topic which will undoubtedly come > to the forefront (assuming it doesn't get drowned-out or killed by the > barrage of hype about BC): > > -- Minimal assumption: What is the minimal assumption for interoperable > blockchain systems with regards to the notion of transaction units. In > other words, what is the “datagram” equivalent of transactions – > namely the transaction unit that is semantically understandable > (processable) by multiple different blockchain systems. > > This is a question we posed in our recent discussion paper: > > https://arxiv.org/pdf/1805.05934.pdf > > Would love to get your thoughts on this "datagram" equivalent question > (or if this framework of thought is even the correct one). > > > Best > > > -- thomas -- > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > From nobody Wed Jun 6 03:09:23 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88029128BAC for ; Wed, 6 Jun 2018 03:09:21 -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 autolearn_force=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 Dt-TkmwS0i0S for ; Wed, 6 Jun 2018 03:09:15 -0700 (PDT) Received: from mta2.cl.cam.ac.uk (mta2.cl.cam.ac.uk [IPv6:2001:630:212:200::25:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82077130ED0 for ; Wed, 6 Jun 2018 03:09:15 -0700 (PDT) Received: from ely.cl.cam.ac.uk ([2001:630:212:238:230:48ff:fefe:c314]) by mta2.cl.cam.ac.uk with esmtp (Exim 4.86_2) (envelope-from ) id 1fQVNR-0001Qo-9c; Wed, 06 Jun 2018 11:09:13 +0100 From: Jon Crowcroft To: Jon Crowcroft cc: Thomas Hardjono , "din@irtf.org" In-reply-to: References: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu>, <5E393DF26B791A428E5F003BB6C5342AFD22E716@OC11EXPO33.exchange.mit.edu> Comments: In-reply-to Jon Crowcroft message dated "Tue, 05 Jun 2018 15:01:45 +0100." MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <47718.1528279753.1@ely.cl.cam.ac.uk> Content-Transfer-Encoding: 8bit Date: Wed, 06 Jun 2018 11:09:13 +0100 Message-Id: Archived-At: Subject: Re: [Din] Minimal assumption for interoperable blockchain systems X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 10:09:22 -0000 oh, plus you could have semantically equivalent blockchains, but with different performance parameters, so we can sort those on tightness of temporal bounds on consistency....but that's easy ... for the stuff below, this might be useful: https://arxiv.org/pdf/1707.01747.pdf > strawman - > > design a standard description for consistency algo used by each BC > (there are some semi-formal ways of describing such algos...) > > form a full interconnect of blochain systems and exchange > descriptions which should form a partial order on the graph (guess) > > compute which interconnects make sense and which ones cannot... > > proceed.... > > > >>> From: crowcroft@gmail.com [crowcroft@gmail.com] > > >>> ... > > >>> so for inter-ledger type thinking, we're connecting systems > > >>> that fundamentally care about consistency - but define its > > >>> eventuality differently - so a basic building block of an > > >>> interoperabilty or inter-domain protocol would be to > > >>> convey (and somehow reconcile) that variation in notion > > >>> of how long before we agree about an append in domain 1, > > >>> when were' 5 ledger domain hops away... > > > > > > Jon, this is excellent. > > > > I've been struggling to find words to use for what you refer to as > > "consistency", particularly with regards to the end-state > ("eventuality"). > > > > I'm assuming that at a high level, the "eventuality" is defined as some > > data-string being recorded on the ledger of a BC (i.e. all distributed > > P2P nodes of the BC). > > > > As you correctly intuited, the consistency-problem is more difficult for > > cross-ledger transactions. > > > > A simple example with 1 entity only: Alice wants to "move" her > > registered land-deed from BC1 to BC2 (direct, no hops). > > > > -- How many transactions does Alice's Application need to transmit? (one > > only to BC1; or one each to BC1 and BC2; or three: BC1; BC2 and then BC1 > > again). > > > > Any thoughts how how to define "consistency" more specific/technically? > > > > > > -- thomas -- > > > > > > > > ________________________________________ > > From: crowcroft@gmail.com [crowcroft@gmail.com] on behalf of Jon > > Crowcroft [jon.crowcroft@cl.cam.ac.uk] > > Sent: Sunday, June 03, 2018 10:12 AM > > To: Thomas Hardjono > > Cc: din@irtf.org > > Subject: Re: [Din] Minimal assumption for interoperable blockchain > systems > > > > looks sane (as did interledger) but we're missing (I think, but may be I > > missed it too) one of the big challenges for this compared with scaling > > (which is what you have to address in internetworking stuff whether > > subnetworks with IP or IGPs with BGP, or serice+content with WWW - > that's > > a fundamentally difficult piece of distributed ledgers- consistency > > > > one thing the e2e model did for thinking (amongst many) was to think in > > an intensely relaxed way about consistency - IP doesn't care if the > > source is still where it was when the packet reaches the destination (or > > even first hop router. BGP doesn't care (much) about IGP convergance > when > > announcing (or withdrawing) prefixes and (most) AS paths. WWW doesn't > > care if the remote page (server, site or content) are there when you add > > a URL to your site - all this is "fixed up later" by some eventual > > consistency protocol (in IPs case, TCP; in the IGP/BGPs case the > > linkstate and path vector and a lot of magic pixie dust and luck; in the > > WWW case, search/rank&shame and later maintenance) - > > > > so for inter-ledger type thinking, we're connecting systems that > > fundamentally care about consistency - but define its eventuality > > differently - so a basic building block of an interoperabilty or > > inter-domain protocol would be to convey (and somehow reconcile) that > > variation in notion of how long before we agree about an append in > domain > > 1, when were' 5 ledger domain hops away... > > > > which reminds me, am I allowed to coin that term "ledgerdomain" ? :-) > > > > On Sun, Jun 3, 2018 at 2:51 PM, Thomas Hardjono > > > wrote: > > > > Here is a question I'd like to throw out to this community regarding > > "interoperable blockchain systems" -- a topic which will undoubtedly > come > > to the forefront (assuming it doesn't get drowned-out or killed by the > > barrage of hype about BC): > > > > -- Minimal assumption: What is the minimal assumption for interoperable > > blockchain systems with regards to the notion of transaction units. In > > other words, what is the “datagram” equivalent of transactions – > > namely the transaction unit that is semantically understandable > > (processable) by multiple different blockchain systems. > > > > This is a question we posed in our recent discussion paper: > > > > https://arxiv.org/pdf/1805.05934.pdf > > > > Would love to get your thoughts on this "datagram" equivalent question > > (or if this framework of thought is even the correct one). > > > > > > Best > > > > > > -- thomas -- > > > > _______________________________________________ > > Din mailing list > > Din@irtf.org > > https://www.irtf.org/mailman/listinfo/din > > > From nobody Thu Jun 7 06:09:03 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431D8130E9D for ; Thu, 7 Jun 2018 06:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 IeMHPf2cg010 for ; Thu, 7 Jun 2018 06:08:56 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E530E130E60 for ; Thu, 7 Jun 2018 06:08:55 -0700 (PDT) X-AuditID: 12074424-fbbff700000019fe-b0-5b192e66da7f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 9E.68.06654.66E291B5; Thu, 7 Jun 2018 09:08:54 -0400 (EDT) Received: from outgoing-exchange-3.mit.edu (OUTGOING-EXCHANGE-3.MIT.EDU [18.9.28.13]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w57D8smI020763; Thu, 7 Jun 2018 09:08:54 -0400 Received: from OC11EXEDGE3.EXCHANGE.MIT.EDU (OC11EXEDGE3.EXCHANGE.MIT.EDU [18.9.3.21]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id w57D8k4B008108; Thu, 7 Jun 2018 09:08:51 -0400 Received: from W92EXCAS21.exchange.mit.edu (18.7.71.34) by OC11EXEDGE3.EXCHANGE.MIT.EDU (18.9.3.21) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Jun 2018 09:07:57 -0400 Received: from OC11EXPO33.exchange.mit.edu ([169.254.1.177]) by W92EXCAS21.exchange.mit.edu ([18.7.71.34]) with mapi id 14.03.0352.000; Thu, 7 Jun 2018 09:08:47 -0400 From: Thomas Hardjono To: "jon.crowcroft@cl.cam.ac.uk" CC: "din@irtf.org" Thread-Topic: [Din] Minimal assumption for interoperable blockchain systems Thread-Index: AQHT+0CmDYm4GElA7Ua0jKaUNEZ41qRO1nUAgAFpmmeAAbf3gIABUV2AgAF/ANM= Date: Thu, 7 Jun 2018 13:08:46 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342AFD23D9E9@OC11EXPO33.exchange.mit.edu> References: <5E393DF26B791A428E5F003BB6C5342AFD22A42F@OC11EXPO33.exchange.mit.edu>, <5E393DF26B791A428E5F003BB6C5342AFD22E716@OC11EXPO33.exchange.mit.edu> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.7.71.72] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLKsWRmVeSWpSXmKPExsUixG6nopumJxlt8H62tcXSj3tZLB5cfMLk wOSxtfU4i8fkjYfZApiiuGxSUnMyy1KL9O0SuDL6bi5hKphrVLHz2Vz2BsYJGl2MnBwSAiYS XfM3sXcxcnEICSxmkthytAPK2c8osfHnXGYI5xijxM7FrVDONkaJiy1HoZxVjBI3p55hAhnG JqAh0fajlx3EFhGwlZh5YyEjiM0soCjRNbkJrEZYwEvi1L2VTBA13hKffp1nhLD9JN6/ncMG YrMIqEgcu7kQaAEHB69AkMSFK94Qu9YxSczp38ACUsMpYCTxa+EhZhCbUUBM4vupNUwQu8Ql bj2ZzwTxnKDEotl7mCFsMYl/ux6yQdhyEl83dbFD1BtIvD83nxnC1pZYtvA1mM0L1Hty5hOW CYwSs5CMnYWkZRaSlllIWhYwsqxilE3JrdLNTczMKU5N1i1OTszLSy3SNdfLzSzRS00p3cQI jkMXlR2M3T3ehxgFOBiVeHhvPBSPFmJNLCuuzD3EKMnBpCTKu0hZIlqILyk/pTIjsTgjvqg0 J7X4EKMEB7OSCG/iJbFoId6UxMqq1KJ8mJQ0B4uSOG/uIsZoIYH0xJLU7NTUgtQimKwMB4eS BG+SrmS0kGBRanpqRVpmTglCmomDE2Q4D9DwMB2gGt7igsTc4sx0iPwpRmOOO209PcwcHe+n 9DALseTl56VKifPGgowTACnNKM2DmwZOpZzMoq8YxYGeE+Y1AqniAaZhuHmvgFYxAa3yYAZb VZKIkJJqYKz6Z3eGy7FCevZLZQWd7EuugUY2eUrn9t2/XZJRIbt90YVEQ+4d/BpVhV1mEomc XyZcOv/Y7oZRZHSciYHLhEn3w/LlD19zWRyqJ65R+EJrkoxRmautgVyKurX/xhMPVM7P/d/D vfeQfJb3zI4/6zyyrqTN9Sx9zv3s3X7Flg+Rpul9jA5PlViKMxINtZiLihMBS/fvJoADAAA= Archived-At: Subject: Re: [Din] Minimal assumption for interoperable blockchain systems X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 13:09:00 -0000 >>> > form a full interconnect of blochain systems and exchange >>> > descriptions which should form a partial order on the graph (guess) >>> oh, plus you could have semantically equivalent blockchains, but >>> with different performance parameters, so we can sort those on tightnes= s >>> of temporal bounds on consistency....but that's easy ... Right. Assuming the gateway paradigm is the correct design framework, each= Gateway will form a "mental picture" (graph) of its adjacent BC systems ba= sed on the exchange of the temporal parameters.=20 The term "adjacent" here means other BC systems which "interoperable" (comp= atible) with it. >>> for the stuff below, this might be useful: >>> https://arxiv.org/pdf/1707.01747.pdf Thanks Jon -- I'll read through this paper. -- thomas --=20 ________________________________________ From: Jon Crowcroft [Jon.Crowcroft@cl.cam.ac.uk] Sent: Wednesday, June 06, 2018 6:09 AM To: Jon Crowcroft Cc: Thomas Hardjono; din@irtf.org Subject: Re: [Din] Minimal assumption for interoperable blockchain systems oh, plus you could have semantically equivalent blockchains, but with different performance parameters, so we can sort those on tightness of temporal bounds on consistency....but that's easy ... for the stuff below, this might be useful: https://arxiv.org/pdf/1707.01747.pdf > strawman - > > design a standard description for consistency algo used by each BC > (there are some semi-formal ways of describing such algos...) > > form a full interconnect of blochain systems and exchange > descriptions which should form a partial order on the graph (guess) > > compute which interconnects make sense and which ones cannot... > > proceed.... > > > >>> From: crowcroft@gmail.com [crowcroft@gmail.com] > > >>> ... > > >>> so for inter-ledger type thinking, we're connecting systems > > >>> that fundamentally care about consistency - but define its > > >>> eventuality differently - so a basic building block of an > > >>> interoperabilty or inter-domain protocol would be to > > >>> convey (and somehow reconcile) that variation in notion > > >>> of how long before we agree about an append in domain 1, > > >>> when were' 5 ledger domain hops away... > > > > > > Jon, this is excellent. > > > > I've been struggling to find words to use for what you refer to as > > "consistency", particularly with regards to the end-state > ("eventuality"). > > > > I'm assuming that at a high level, the "eventuality" is defined as some > > data-string being recorded on the ledger of a BC (i.e. all distributed > > P2P nodes of the BC). > > > > As you correctly intuited, the consistency-problem is more difficult fo= r > > cross-ledger transactions. > > > > A simple example with 1 entity only: Alice wants to "move" her > > registered land-deed from BC1 to BC2 (direct, no hops). > > > > -- How many transactions does Alice's Application need to transmit? (on= e > > only to BC1; or one each to BC1 and BC2; or three: BC1; BC2 and then BC= 1 > > again). > > > > Any thoughts how how to define "consistency" more specific/technically= ? > > > > > > -- thomas -- > > > > > > > > ________________________________________ > > From: crowcroft@gmail.com [crowcroft@gmail.com] on behalf of Jon > > Crowcroft [jon.crowcroft@cl.cam.ac.uk] > > Sent: Sunday, June 03, 2018 10:12 AM > > To: Thomas Hardjono > > Cc: din@irtf.org > > Subject: Re: [Din] Minimal assumption for interoperable blockchain > systems > > > > looks sane (as did interledger) but we're missing (I think, but may be = I > > missed it too) one of the big challenges for this compared with scaling > > (which is what you have to address in internetworking stuff whether > > subnetworks with IP or IGPs with BGP, or serice+content with WWW - > that's > > a fundamentally difficult piece of distributed ledgers- consistency > > > > one thing the e2e model did for thinking (amongst many) was to think in > > an intensely relaxed way about consistency - IP doesn't care if the > > source is still where it was when the packet reaches the destination (o= r > > even first hop router. BGP doesn't care (much) about IGP convergance > when > > announcing (or withdrawing) prefixes and (most) AS paths. WWW doesn't > > care if the remote page (server, site or content) are there when you ad= d > > a URL to your site - all this is "fixed up later" by some eventual > > consistency protocol (in IPs case, TCP; in the IGP/BGPs case the > > linkstate and path vector and a lot of magic pixie dust and luck; in th= e > > WWW case, search/rank&shame and later maintenance) - > > > > so for inter-ledger type thinking, we're connecting systems that > > fundamentally care about consistency - but define its eventuality > > differently - so a basic building block of an interoperabilty or > > inter-domain protocol would be to convey (and somehow reconcile) that > > variation in notion of how long before we agree about an append in > domain > > 1, when were' 5 ledger domain hops away... > > > > which reminds me, am I allowed to coin that term "ledgerdomain" ? :-) > > > > On Sun, Jun 3, 2018 at 2:51 PM, Thomas Hardjono > > > wrote: > > > > Here is a question I'd like to throw out to this community regarding > > "interoperable blockchain systems" -- a topic which will undoubtedly > come > > to the forefront (assuming it doesn't get drowned-out or killed by the > > barrage of hype about BC): > > > > -- Minimal assumption: What is the minimal assumption for interoperable > > blockchain systems with regards to the notion of transaction units. In > > other words, what is the =93datagram=94 equivalent of transactions =96 > > namely the transaction unit that is semantically understandable > > (processable) by multiple different blockchain systems. > > > > This is a question we posed in our recent discussion paper: > > > > https://arxiv.org/pdf/1805.05934.pdf > > > > Would love to get your thoughts on this "datagram" equivalent question > > (or if this framework of thought is even the correct one). > > > > > > Best > > > > > > -- thomas -- > > > > _______________________________________________ > > Din mailing list > > Din@irtf.org > > https://www.irtf.org/mailman/listinfo/din > > >= From nobody Sat Jun 9 05:00:33 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE38130E59 for ; Sat, 9 Jun 2018 05:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 HHXD321krAXs for ; Sat, 9 Jun 2018 05:00:30 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AD5E130E55 for ; Sat, 9 Jun 2018 05:00:29 -0700 (PDT) Received: from [192.168.178.59] ([77.21.26.45]) by mrelayeu.kundenserver.de (mreue003 [212.227.15.167]) with ESMTPSA (Nemesis) id 0MCucZ-1fZdAO1xsh-009g4j; Sat, 09 Jun 2018 14:00:27 +0200 From: "Dirk Kutscher" To: din@irtf.org Cc: "Melinda Shore" Date: Sat, 09 Jun 2018 14:00:25 +0200 X-Mailer: MailMate (1.11.2r5479) Message-ID: <4B219430-1287-464E-8F16-008D1827C4D6@dkutscher.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown X-Provags-ID: V03:K1:w8RQp7bwKYj7IAkgOoz5jOaZgaG/uS07niAONv1EhZVaqWUN589 DLCUJ481X89y74b1WcTY0qG4fCXlG0YhBw1CcBcwAnFRAfTRUPyKgJUR8ai6TVVFOgrDuzF 1q7inqhSb264tEAXBPTmbP38E+l7lLWI9PS67vZEk2x0j8DLCWHYkJ/IUrBb4Tg8ZQQ1K79 NAgC++1JRutwX7mAPM15A== X-UI-Out-Filterresults: notjunk:1;V01:K0:d8HTe2gmsP0=:hGt55gWgY96AOM85bX0ufb 2Zc7FKaMmDQrZd5zmEFxm3HWFI+6NF6W/4yBY0fXej58JQ31jeObmNr38Ln16qEdDQ682j9+8 Tiy5AMSJ6wEh7J/BWsW9mBX+eRjKXJx8tsmwP4tqKUyArSfden9gmVn9BP/D/WsY+SkMACneL wOBFWYppXTBGPt88mxZcCKj8bHZMmDpFAOGxrnGG5KOdNBbaw+cvRfjPqRBBznxcx8/HrdPwC 5H72ubW8T3Wz/re8UuIgdsUsvaMTbjqNsNi/U4SZGH/hfcSF3iCdA34Z0I7ItFP59qcZie/GW FJD4ZDqYgXhD05bh41seF0Wfl+LEXh9ziUzmT8U0b6vg4G8FjwLWxRNL9nDDFxGd6tPXm+fZv bxXtfAMYRS98XsAU+nQUe/SPkYH9JpKC6vBd7oLeuH4ajIG6WnGpbffuT8nTsI6blldNKGqyt rJaoPEsn6WzGuorebXc5S2SEVhaabY4YVkudVov/p08onQ9xdJTH2YNsTQmSjBGZ+HqAwEr8v TU+tw1UB2bk7WJGn+AHtuQCyhj9qpb0dU2q6Vs4Q8abkabTP0QIfqYMFxqVnMDMgql8uLZWEp z7+CMUZoB8MPsAijaeVpbHY+DdpL/UD0LfESuIYdx+jWfI+ccvs8OaP1ziZswixI4lsNuIOxN sL4B0wIytEA/Vb9VOCDzykaMdyOIA3Dxz0VAXvs+Hbqi4PJUTaUcvZXyZznZQwGNRGBbvMYHr olS+8jdcG3u1iIdA Archived-At: Subject: [Din] Inviting presentations for DINRG@Montreal X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2018 12:00:32 -0000 Hi, DINRG is going to meet in Montreal at IETF-102. In case you are interested to present or discuss something, please send a message to the chairs. Best regards, Melinda and Dirk From pierspowlesland@gmail.com Tue Jun 12 10:13:08 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B8C130F73 for ; Tue, 12 Jun 2018 10:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZQFsGNdptkOM for ; Tue, 12 Jun 2018 10:13:06 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9180A130F6A for ; Tue, 12 Jun 2018 10:13:06 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id j15-v6so418990wme.0 for ; Tue, 12 Jun 2018 10:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=o9u0oTLjfQyv0n0HUbhNFuh/hiLFtA0WEpuogDr/Srs=; b=l7aByIHWUB/EUsnHP+vU0EptGdTSTDZRZOfupQvaR4CHLr4EauYOizdGED4xpRQl0u 01+g591ypitFR37B8tv513dGqYXa599cOBNiXTho5cAzqm2ZneKr1GfQghZ7zSd7V+6T YzF9X8DkZLufDx5Qk618q01cYPyjTAKiA2bhhcyEOGmrGZGiTV41XZ/MD/EcvZDC4dr1 wbVjpV2SCUWeThXcMEoLx3F0er9lCYyLRR6CPsPhhrvq/ioB0aZJthjPMt+UcYG3hkhy dpgKQYoqgtRq7KH8hf9WFeeRh39X60YDqbjlmaq/iSmNwL7tbMqR+jvdiMOiHya7VitO ZsLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=o9u0oTLjfQyv0n0HUbhNFuh/hiLFtA0WEpuogDr/Srs=; b=TLZ/7UtoCzkw6JwDPGNUx82gi21YoXfEiJrQAuqvBqxddx9LFsKPnkK11+4n+0tEmV SZBPeezVpR/dXy0vleqildZFi5NtPXQhnh3q1Lh8pkLTJMI+o9J3qKdwR86dgKgg7pbr bIHzGbfDCZ26loQ30MbqdkTumLIBJWK03ijGPyXIatnvMYqY89qziX4hncrnuS9UDCGk Em67J/ufAhSUkPfmfyiIyJ7ty/Qtev137jChKgRVkcdt19hYsMlxxiFPhtrFJLza/1+b MkRhmiKWksFi81IXtz4lJQ+cfPgfZqloWM+Q3jXzceUO7ncFcG6Ch70r19mLJVGtH56o MqOg== X-Gm-Message-State: APt69E1FwaAayVQKQJJK5fz3oEpzxKsWVwyZp42y8O5YhrmSJmsTDzgC 3aCwCgzWhR4dD2sizt/usAjbUNkaegc9fbeCtXVuZg== X-Google-Smtp-Source: ADUXVKI0d8AiUvLSC3XgcVoEVIHXIo8Io2tAknxp3poVauhsod3HKX59x29eM53cr/6h2ss7Jy/Vr1deoL+F2Br1a7c= X-Received: by 2002:a1c:9:: with SMTP id 9-v6mr846988wma.10.1528823584792; Tue, 12 Jun 2018 10:13:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:eec9:0:0:0:0:0 with HTTP; Tue, 12 Jun 2018 10:13:04 -0700 (PDT) From: Piers Powlesland Date: Tue, 12 Jun 2018 18:13:04 +0100 Message-ID: To: din@irtf.org Content-Type: multipart/alternative; boundary="000000000000b22439056e74fa88" Archived-At: Subject: [Din] Quorum slice representation in revised SCP draft draft-mazieres-dinrg-scp-02 X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 17:27:44 -0000 --000000000000b22439056e74fa88 Content-Type: text/plain; charset="UTF-8" Hi all, The description of a node's quorum slices in the white paper is a collection of sets of nodes for which any set is sufficient to convince the node of system wide agreement. I would represent this as a list of lists. So I'm wondering why the recursive SCPQuorumSet struct was chosen to represent quorum slices? Thanks, Piers --000000000000b22439056e74fa88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,


The description of a node's qu= orum slices in the white paper is a collection of sets of nodes for which a= ny set is sufficient to convince the node of system wide agreement. I would= represent this as a list of lists.

So I'= m wondering why the recursive SCPQuorumSet struct was chosen to represent q= uorum slices?

Thanks,

Pie= rs


--000000000000b22439056e74fa88-- From nobody Tue Jun 12 20:01:10 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D56130DDB for ; Tue, 12 Jun 2018 20:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scs.stanford.edu 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 yRgXrKfAZSyQ for ; Tue, 12 Jun 2018 20:01:04 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95458130DD5 for ; Tue, 12 Jun 2018 20:01:04 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.16.0.21/8.16.0.21) with ESMTP id w5D3125G054421; Tue, 12 Jun 2018 20:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scs.stanford.edu; s=scs; t=1528858862; bh=KGIfik+3DZBhtVxXQ9wtJ4cLGJdvwq460VUPwVswDLs=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version; b=J8SUWUTO6++zrxcbFoFsIaTSyFi+4QJ+lLbtIbSHe9t2fjSMSFJdDIyHUtklKKal1 PqeA0SNx9XbVNFoHyeqa3FhZDSM7hPE7Z8OXmgHxqg/qvTmdydkJvJBKUs4NiCfQb6 DPl06gT4rKkMHrsER1ne4RWGYTSGE9FrIgIHjs98= Received: (from dm@localhost) by market.scs.stanford.edu (8.16.0.21/8.16.0.21/Submit) id w5D311Il079052; Tue, 12 Jun 2018 20:01:01 -0700 (PDT) From: David Mazieres To: Piers Powlesland , din@irtf.org In-Reply-To: References: Reply-To: David Mazieres expires 2018-09-10 PDT Date: Tue, 12 Jun 2018 20:01:01 -0700 Message-ID: <87k1r3bdaq.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Din] Quorum slice representation in revised SCP draft draft-mazieres-dinrg-scp-02 X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 03:01:09 -0000 Piers Powlesland writes: > Hi all, > > > The description of a node's quorum slices in the white paper is a > collection of sets of nodes for which any set is sufficient to convince the > node of system wide agreement. I would represent this as a list of lists. > > So I'm wondering why the recursive SCPQuorumSet struct was chosen to > represent quorum slices? The whitepaper uses sets of sets for the proofs because it's the most general thing possible. However, often people want a very large number of quorum slices--like, say, k of n nodes. For, say, a 7-out-of-10 configuration, that's 120 different quorum slices, which would be quite unwieldy to ship around as a list of lists. David From nobody Wed Jun 13 11:55:35 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87413126CB6 for ; Wed, 13 Jun 2018 11:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nbKaMSnCZ1In for ; Wed, 13 Jun 2018 11:55:31 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23844130E70 for ; Wed, 13 Jun 2018 11:55:31 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id z6-v6so349431wma.0 for ; Wed, 13 Jun 2018 11:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+S/sz5IrWYQXQGX8aF1GfYsqNnFrl0mEjYA0kXbZzCI=; b=Rf6vKIumCXTGhruqhYnFJrRBm2qsdvlBjS4HaYMDQZ8oOg4tPbe603YieGjd2jOwAU JkMoAqQaIMCvoHYkKle4PZdrnTXdmqtU2Q4OND48TtWEoF5GVn2o5DZvlvHnmTrBtUWp tUn3QtZXZ2eezx6hc+2YY5InHlWyL4I0A/rlyO5qVVSd1/hQFJdUOxqoJiixiecExQh4 oRNpzA7OPk/vaArAF5+IEPeM8Nyzim+AE27+bweU5jypDylv5cRfjrTpgSVcb1Fw4CGm mbDnRWV8BjjP+k3mOB5xKuOVP+TEM3MXQOaHmvVMMknFmI7flBcws69nSAfYeQkdEz4e kuQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+S/sz5IrWYQXQGX8aF1GfYsqNnFrl0mEjYA0kXbZzCI=; b=A/VWuOAToeyW7SSrqkMUIL0LNQ1EqwjVAsuQmyKtzNWHtsko9h1A5I2L+HFj4gUa4b HXCRrG8SdFm3DtunuwBozpGC6ALoMeDINQ2eyeElrZO58WCYRY0RWfXxO+3gXnN4CChZ ps0OtKH+CYk7M4emGS536PJhD6BgGejwpq/cwNNMHUyoMNagVSE3sf/wGcIPLYuuwK7J 4oglD8s2aAA6XRq6SYxna4IYq4QYiyPgc2TuWTkjlpsa2cE5vvmqQS8UOrLSs4JkMmtt bndt5E7g3fTR0aMh4jQT2u9ETTVoZ73GxM25Nj+Rv9Zprpz5sxWyHVegsf9qBjkNQEUx wJYw== X-Gm-Message-State: APt69E3R3T4xhJoaTvkr6f7Zj90mmKGTzRyfpHf7pbf6NPqY9w9kwX6d vGOljR9BZO5yl4lbVBpH8S0kTheS6Q68SG1PLgo= X-Google-Smtp-Source: ADUXVKL6aFPsobOKWtTuj4Tz6V46m2ug4VCE7WPd+HaYe0ev/ICanyI1damTFBshNCkE6K84OysQeE43jfchq0YFRPo= X-Received: by 2002:a1c:5c93:: with SMTP id q141-v6mr4196028wmb.77.1528916129641; Wed, 13 Jun 2018 11:55:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:eec9:0:0:0:0:0 with HTTP; Wed, 13 Jun 2018 11:55:28 -0700 (PDT) In-Reply-To: <87k1r3bdaq.fsf@ta.scs.stanford.edu> References: <87k1r3bdaq.fsf@ta.scs.stanford.edu> From: Piers Powlesland Date: Wed, 13 Jun 2018 19:55:28 +0100 Message-ID: To: David Mazieres expires 2018-09-10 PDT Cc: din@irtf.org Content-Type: multipart/alternative; boundary="000000000000cc7cf3056e8a8636" Archived-At: Subject: Re: [Din] Quorum slice representation in revised SCP draft draft-mazieres-dinrg-scp-02 X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 18:55:34 -0000 --000000000000cc7cf3056e8a8636 Content-Type: text/plain; charset="UTF-8" Thanks David, That makes a bunch of sense. If I did want to encode a bunch of explicit slices in a manner similar to that discussed in the whitepaper using the SCPQuorumSet structure ( https://tools.ietf.org/html/draft-mazieres-dinrg-scp-02#section-3.3). I guess I could have a top level set with the threshold set to 1 and then encode each quorum slice in separate SCPQuorumSet1 instances each of which would have the threshold set to the length of their validators. Reading that section again I'm wondering why only 2 levels of nesting are allowed? On Wed, Jun 13, 2018 at 4:01 AM, David Mazieres < dm-list-ietf-ilc@scs.stanford.edu> wrote: > Piers Powlesland writes: > > > Hi all, > > > > > > The description of a node's quorum slices in the white paper is a > > collection of sets of nodes for which any set is sufficient to convince > the > > node of system wide agreement. I would represent this as a list of lists. > > > > So I'm wondering why the recursive SCPQuorumSet struct was chosen to > > represent quorum slices? > > The whitepaper uses sets of sets for the proofs because it's the most > general thing possible. However, often people want a very large number > of quorum slices--like, say, k of n nodes. For, say, a 7-out-of-10 > configuration, that's 120 different quorum slices, which would be quite > unwieldy to ship around as a list of lists. > > David > --000000000000cc7cf3056e8a8636 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks David,<= br>
That makes a bunch of sense.

If I did want to encode a bunch of explicit slices in a manner simil= ar to that discussed in the whitepaper using the SCPQuorumSet structure (https://tools.ietf.org/html/draft-mazieres-dinrg-= scp-02#section-3.3).=C2=A0I guess I could have a top level set wit= h the threshold set to 1 and then encode each quorum slice in separate SCPQ= uorumSet1 instances each of which would have the threshold set to the lengt= h of their validators.

= Reading that section again I'm wondering why only 2 levels of nesting a= re allowed?


On Wed, Jun 13, 2018 at 4:01 AM, David Mazieres <dm-list-ietf-ilc@scs.stanford.edu> wrote:
Piers Powlesland <pierspowlesland@gmail.com> writes= :

> Hi all,
>
>
> The description of a node's quorum slices in the white paper is a<= br> > collection of sets of nodes for which any set is sufficient to convinc= e the
> node of system wide agreement. I would represent this as a list of lis= ts.
>
> So I'm wondering why the recursive SCPQuorumSet struct was chosen = to
> represent quorum slices?

The whitepaper uses sets of sets for the proofs because it's the= most
general thing possible.=C2=A0 However, often people want a very large numbe= r
of quorum slices--like, say, k of n nodes.=C2=A0 For, say, a 7-out-of-10 configuration, that's 120 different quorum slices, which would be quite=
unwieldy to ship around as a list of lists.

David

--000000000000cc7cf3056e8a8636-- From nobody Wed Jun 13 12:27:18 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01843130E87 for ; Wed, 13 Jun 2018 12:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scs.stanford.edu 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 bXnNovymXZ8z for ; Wed, 13 Jun 2018 12:27:15 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942A312426A for ; Wed, 13 Jun 2018 12:27:15 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.16.0.21/8.16.0.21) with ESMTP id w5DJREKZ023929; Wed, 13 Jun 2018 12:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scs.stanford.edu; s=scs; t=1528918034; bh=bqTlqhGVxt8GVkistHFOCnvcTaL5iM1bghGyq2VuJ2A=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version; b=C/jycmUg4361Qrayvt7C3LpbCKKu7mFgYnEAC62GXvTZzQwlPAkC7WOc6RlsnFUdO WdevlPlBi17zJINxDuw6/q90FXsDeIkct7sGYFJSbhzWK/U1sWpmW+St6EM5oyrhz/ eHCoIHqhfE+uHPNLXWAgTZcQR4gD/6TSagds59tA= Received: (from dm@localhost) by market.scs.stanford.edu (8.16.0.21/8.16.0.21/Submit) id w5DJRETC079453; Wed, 13 Jun 2018 12:27:14 -0700 (PDT) From: David Mazieres To: Piers Powlesland Cc: din@irtf.org In-Reply-To: References: <87k1r3bdaq.fsf@ta.scs.stanford.edu> Reply-To: David Mazieres expires 2018-09-11 PDT Date: Wed, 13 Jun 2018 12:27:14 -0700 Message-ID: <87bmcecwrx.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Din] Quorum slice representation in revised SCP draft draft-mazieres-dinrg-scp-02 X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 19:27:17 -0000 Piers Powlesland writes: > Thanks David, > > That makes a bunch of sense. > > If I did want to encode a bunch of explicit slices in a manner similar to > that discussed in the whitepaper using the SCPQuorumSet structure ( > https://tools.ietf.org/html/draft-mazieres-dinrg-scp-02#section-3.3). I > guess I could have a top level set with the threshold set to 1 and then > encode each quorum slice in separate SCPQuorumSet1 instances each of which > would have the threshold set to the length of their validators. > > Reading that section again I'm wondering why only 2 levels of nesting are > allowed? Again, it's a compromise between flexibility and practical aspects. Arbitrary recursion would make checking more expensive. More practically, many implementations of XDR use recursive functions to parse recursive data structures, so would be vulnerable to DoS attacks that blow out the stack if the structures could nest arbitrarily. David From nobody Wed Jun 13 14:33:38 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B88E130FCA for ; Wed, 13 Jun 2018 14:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scs.stanford.edu 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 4LTs78xx2hZB for ; Wed, 13 Jun 2018 14:33:35 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA928130F83 for ; Wed, 13 Jun 2018 14:33:35 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.16.0.21/8.16.0.21) with ESMTP id w5DLXZ0u076116 for ; Wed, 13 Jun 2018 14:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scs.stanford.edu; s=scs; t=1528925615; bh=Cmw4/xOasTqACiJ/IEDzh6REZbCNX8QiBtwpud4dXgM=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=luJdw3s0NdjGOvRbNqoptl+P3hI5khhtj3WmQgX6AYhZUyfd8NUD+Uo5FeuZNjCsp +cq0IAeP8ZIA0XjDLVwqiPv213v88rl2qcsrLr6MIY5srsmkFnnsawYZkiX9EmCdZ0 tcB9fpPOJAW9hHW7LCfs+CCeXCZOgWaylDElZcBM= Received: (from dm@localhost) by market.scs.stanford.edu (8.16.0.21/8.16.0.21/Submit) id w5DLXZgr090487; Wed, 13 Jun 2018 14:33:35 -0700 (PDT) From: David Mazieres To: din@irtf.org Reply-To: David Mazieres expires 2018-09-11 PDT Date: Wed, 13 Jun 2018 14:33:35 -0700 Message-ID: <87vaambccw.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [Din] New SCP draft X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 21:33:38 -0000 Hi, everyone. We've posted a new draft of the SCP protocol spec in the usual place: https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/ In addition to a bunch of clarifications, the new draft addresses a bug or serious ambiguity in how nodes may exit the NOMINATION phase. Previously, nomination effectively had to go on in perpetuity. Now, we just run the NOMINATION and PREPARE phases concurrently, and allow a node to accept a prepared ballot even before it has completed the nomination phase. This makes it possible for a node that has externalized a slot to remember only the externalize message and no longer have to participate in nomination. To make this all clearer, we also added a new section with a table summarizing the phase transitions. Thanks for any comments and feedback. David From nobody Thu Jun 14 04:09:15 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A25E130F3F for ; Thu, 14 Jun 2018 04:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mNOKnXzBfa2H for ; Thu, 14 Jun 2018 04:09:11 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9FE130E0A for ; Thu, 14 Jun 2018 04:09:11 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id o12-v6so5951339wrm.12 for ; Thu, 14 Jun 2018 04:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PxhcEBRzlKlKU/jgcjU7izV4AGBC+guCa3Y2GBdeWJo=; b=qlYswgPP4j5Hh+szKm35d1zSpx+Y4IhFlFmdOOLLCTSQiLq5MXvKIgUsMoLSK8cQI7 JDa7l20ol/AhaVmj1bcuIHcywLVj2aSuIxwjLs2DvV5OIy2XjnAdKxeikjaZ7aEUDUyw PDb6Abb16cN3wSQ7hJWPt3G2ZIThLjbBDnG358a7ceDIqaHCOEpcSUOyqXCMtiec8acX LyAbJ1uQVQsys2oObe6wbFsvHU/I47bG0bkCtu72gTNuEEl++VBuCQcyaVlOAeyI8dWv IinUhPXy/5ngd6y/CXt/OMYUdTq+LUidMzX076cW2e1kVdAtcASbuhB0F8PlWptHgKq+ d72Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PxhcEBRzlKlKU/jgcjU7izV4AGBC+guCa3Y2GBdeWJo=; b=hG62Kf0QG+hXob1Fi/clWazq6jLCEdCi3dhOq2la9ndjQHJGdSydUkEtiMrUmPguc4 YtueZXEfqe+HFwrhDZXJU5m9aJGkl7zGBU1Ix7yGXlS03hcdzv5TN7EMtqKZYdxpncAJ tcNrwo1ZbCrChg8mnGM56g7ojnunpuidF0rJjnQtxD8HUZlD2nMO737cDWxDgG4mt1+D /XsYwCdzXE97xLs45FBcgNNcQz/dSZYtrbvAowBbg+9VDFlz3QOqB3J5l9QKGvfrkzKu ML1iL9W5/5Fq7yjZJSJYTZuNWx/OcqpDj7xDNLUrFxHgghkaXreS0RKUs2IDYEIqpUEM HgPg== X-Gm-Message-State: APt69E2zoJOA72lLYKsV/VFZ8yVp3G9hYsWBO7Nh0deCBruCFmKs5+YN D9tfL5SZVcwCsOAkr9U9yXO5EWia/PK2gO5MEn6HLA== X-Google-Smtp-Source: ADUXVKJFfFekgjs6jDoHIJ0bOE7o565T7Fn98s9wFlzBwyQQzi/dZV6/mP8hLMvU0bFD6mT8TOfnAg9Sq2MQ/HTsyWM= X-Received: by 2002:adf:d10a:: with SMTP id a10-v6mr1750398wri.18.1528974549958; Thu, 14 Jun 2018 04:09:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:eec9:0:0:0:0:0 with HTTP; Thu, 14 Jun 2018 04:09:09 -0700 (PDT) In-Reply-To: <87vaambccw.fsf@ta.scs.stanford.edu> References: <87vaambccw.fsf@ta.scs.stanford.edu> From: Piers Powlesland Date: Thu, 14 Jun 2018 12:09:09 +0100 Message-ID: To: David Mazieres expires 2018-09-11 PDT Cc: din@irtf.org Content-Type: multipart/alternative; boundary="000000000000ebc529056e982081" Archived-At: Subject: Re: [Din] New SCP draft X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 11:09:14 -0000 --000000000000ebc529056e982081 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi David, A couple of thoughts. I think SCPQuorumSet could be renamed to SCPScliceSet or SCPQuorumSliceSet. As it is, the naming implies that the set contains quorums when in fact it may not. Also does echoing a peer involve forwarding messages from a peer to other peers? My usual understanding of the word "echo" is that a message sent is sent back, in this context my immediate understanding of "echoing a peer" would be that messages from a peer are forwarded on or redistributed to the network, but the definition of echoing a peer makes no mention of that. 'To echo "v", the node merges any valid values from "v"=E2=80=99s "voted" a= nd "accepted" sets into its own "voted" set.' On Wed, Jun 13, 2018 at 10:33 PM, David Mazieres < dm-list-ietf-ilc@scs.stanford.edu> wrote: > Hi, everyone. We've posted a new draft of the SCP protocol spec in the > usual place: > > https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/ > > In addition to a bunch of clarifications, the new draft addresses a bug > or serious ambiguity in how nodes may exit the NOMINATION phase. > Previously, nomination effectively had to go on in perpetuity. Now, we > just run the NOMINATION and PREPARE phases concurrently, and allow a > node to accept a prepared ballot even before it has completed the > nomination phase. This makes it possible for a node that has > externalized a slot to remember only the externalize message and no > longer have to participate in nomination. > > To make this all clearer, we also added a new section with a table > summarizing the phase transitions. > > Thanks for any comments and feedback. > > David > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > --000000000000ebc529056e982081 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi David,

A couple of thoughts.

I think SCPQuorumSet could be renamed to SCPScliceSet or = SCPQuorumSliceSet. As it is, the naming implies that the set contains quoru= ms when in fact it may not.

Also does echoing a pe= er involve forwarding messages from a peer to other peers? My usual underst= anding of the word "echo" is that a message sent is sent back, in= this context my immediate understanding of "echoing a peer" woul= d be that messages from a peer are forwarded on or redistributed to the net= work, but the definition of echoing a peer makes no mention of that.
<= div>
'To echo "v", the node merges any valid values from "v"=E2=80= =99s "voted" and "accepted" sets into its own "voted" set.'



On Wed, Jun 13, 2018 at 10:33 PM, David Mazieres <dm-list-ietf-ilc@scs.stanford.edu> wrote:
Hi, everyone.=C2=A0 We've posted a new draft of= the SCP protocol spec in the
usual place:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatr= acker.ietf.org/doc/draft-mazieres-dinrg-scp/

In addition to a bunch of clarifications, the new draft addresses a bug
or serious ambiguity in how nodes may exit the NOMINATION phase.
Previously, nomination effectively had to go on in perpetuity.=C2=A0 Now, w= e
just run the NOMINATION and PREPARE phases concurrently, and allow a
node to accept a prepared ballot even before it has completed the
nomination phase.=C2=A0 This makes it possible for a node that has
externalized a slot to remember only the externalize message and no
longer have to participate in nomination.

To make this all clearer, we also added a new section with a table
summarizing the phase transitions.

Thanks for any comments and feedback.

David

_______________________________________________
Din mailing list
Din@irtf.org
https://www.irtf.org/mailman/listinfo/din

--000000000000ebc529056e982081-- From nobody Thu Jun 14 08:12:38 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD69A130E46 for ; Thu, 14 Jun 2018 08:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scs.stanford.edu 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 iYUqS8w7JTap for ; Thu, 14 Jun 2018 08:12:35 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84141130E29 for ; Thu, 14 Jun 2018 08:12:35 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.16.0.21/8.16.0.21) with ESMTP id w5EFCYq9077637; Thu, 14 Jun 2018 08:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scs.stanford.edu; s=scs; t=1528989154; bh=yNywyURTaHWSm9/PmvrCKfdkgBvFc8Zy8cgjo1Boftw=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version; b=btT+CCgPbVLZsxrl7hkQXKEbPUUEnFvzGO+qVfKw9vPQY/nmIRUe4eObniBrSJaa9 Gz9EceqnMenHamwR3/XaGJoBnIB8fFd8oObQ0PpyKMdhgt3sT7NCSqoUbmqjTj/rFQ juOCziqENIWvF0RFFMF2cekT9oHq0RS+ncStf8wg= Received: (from dm@localhost) by market.scs.stanford.edu (8.16.0.21/8.16.0.21/Submit) id w5EFCXnO052840; Thu, 14 Jun 2018 08:12:33 -0700 (PDT) From: David Mazieres To: Piers Powlesland Cc: din@irtf.org In-Reply-To: References: <87vaambccw.fsf@ta.scs.stanford.edu> Reply-To: David Mazieres expires 2018-09-12 PDT Date: Thu, 14 Jun 2018 08:12:33 -0700 Message-ID: <87h8m5e71a.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Din] New SCP draft X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 15:12:37 -0000 Piers Powlesland writes: > Hi David, > > A couple of thoughts. > > I think SCPQuorumSet could be renamed to SCPScliceSet or SCPQuorumSliceSe= t. > As it is, the naming implies that the set contains quorums when in fact it > may not. That's a good idea. I think maybe just SCPSlices is clear enough and shorter. > Also does echoing a peer involve forwarding messages from a peer to other > peers? My usual understanding of the word "echo" is that a message sent is > sent back, in this context my immediate understanding of "echoing a peer" > would be that messages from a peer are forwarded on or redistributed to t= he > network, but the definition of echoing a peer makes no mention of that. > > 'To echo "v", the node merges any valid values from "v"=E2=80=99s "voted"= and > "accepted" sets into its own "voted" set.' Since the messages are broadcast, technically the sending node may hear its votes echoed back, but I agree this could provide the wrong intuition. Similarly "mirroring" might convey the wrong thing. Maybe "relaying" or "repeating" or "following"? Any other ideas? David From nobody Sat Jun 16 06:45:27 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E8F130EF3 for ; Sat, 16 Jun 2018 06:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 bnxD3cDs3lTR for ; Sat, 16 Jun 2018 06:45:22 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F37B0130E4C for ; Sat, 16 Jun 2018 06:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w5GDjHm9025525 for ; Sat, 16 Jun 2018 15:45:17 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 417JWx5gl2zDXmN for ; Sat, 16 Jun 2018 15:45:17 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 550849515.758203-cb4733873a846608d18460921fcf54cd Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <325530B8-6BA6-4769-8EA2-9799B6899FAA@tzi.org> Date: Sat, 16 Jun 2018 15:45:17 +0200 To: din@irtf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Din] Constrained Node/Network Cluster @ IETF102: DRAFT AGENDA X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 13:45:26 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF102. Remember that there is still quite some potential for changes. ACE vs. DISPATCH seems to become a common occurrance; at this rate, I'll probably never see a DISPATCH meeting again. CBOR vs. 6LO is maybe just a personal problem for me, throwing in TEEP on top is a bit weird, though. 6TISCH vs. SUIT is probably painful for the few individuals who care about security in both. All times are EDT (UTC-0400). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY -- Hackathon (including various interops) (Centre Ville) -- Sun 1800-2000: HotRFC (Viger) MONDAY, July 16, 2018 0930-1200 Morning Session I Duluth ART dispatch Dispatch WG - Joint with ARTAREA Laurier INT 6man IPv6 Maintenance WG Place du Canada RTG detnet Deterministic Networking WG Viger SEC *** ace Authentication and Authorization for = Constrained Environments WG 1330-1530 Afternoon Session I Viger INT ipwave IP Wireless Access in Vehicular = Environments WG Place du Canada SEC tls Transport Layer Security WG 1550-1750 Afternoon Session II Viger ART *** core Constrained RESTful Environments WG Place du Canada INT intarea Internet Area Working Group WG 1810-1940 Afternoon Session III Laurier GEN rfcplusplus The label "RFC" BOF TUESDAY, July 17, 2018 0930-1200 Morning Session I Place du Canada IRTF irtfopen IRTF Open Meeting St-Paul/St-Cath RTG babel Babel routing protocol WG Duluth RTG *** roll Routing Over Low power and Lossy = networks WG 1330-1530 Afternoon Session I Duluth ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Van Horne INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Laurier RTG rtgarea Routing Area Open Meeting Viger SEC *** teep Trusted Execution Environment = Provisioning WG 1550-1820 Afternoon Session II Place du Canada ART httpbis Hypertext Transfer Protocol WG Viger IRTF cfrg Crypto Forum - 1720 - 1820 Centre Ville IRTF icnrg Information-Centric Networking Van Horne SEC acme Automated Certificate Management = Environment WG - 1720 - 1820 Van Horne SEC oauth Web Authorization Protocol WG - 1550 - = 1720 Duluth TSV taps Transport Services WG WEDNESDAY, July 18, 2018 0930-1200 Morning Session I Van Horne OPS anima Autonomic Networking Integrated Model = and Approach WG St-Paul/St-Cath RTG bier Bit Indexed Explicit Replication WG Duluth SEC secdispatch Security Dispatch WG Place du Canada TSV quic QUIC WG 1330-1500 Afternoon Session I Laurier ART httpbis Hypertext Transfer Protocol WG Van Horne INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Centre Ville SEC *** suit Software Updates for Internet of Things = WG 1520-1650 Afternoon Session II Centre Ville INT homenet Home Networking WG Viger TSV tsvarea Transport Area Open Meeting THURSDAY, July 19, 2018 0930-1200 Morning Session I Duluth INT dnssd Extensions for Scalable DNS Service = Discovery WG Centre Ville INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Place du Canada IRTF maprg Measurement and Analysis for Protocols Viger SEC mls Messaging Layer Security WG Van Horne SEC oauth Web Authorization Protocol WG - 0930 - = 1100 1330-1530 Afternoon Session I Centre Ville OPS v6ops IPv6 Operations WG Viger RTG rift Routing In Fat Trees WG Place du Canada SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Viger IRTF*** t2trg Thing-to-Thing Duluth OPS driu DNS Resolver Identification and Use BOF Centre Ville TSV tsvwg Transport Area Working Group WG 1810-1910 Afternoon Session III Van Horne ART *** core Constrained RESTful Environments WG Place du Canada SEC tls Transport Layer Security WG Centre Ville TSV tsvwg Transport Area Working Group WG FRIDAY, July 20, 2018 0930-1130 Morning Session I Duluth IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Place du Canada OPS v6ops IPv6 Operations WG St-Paul/St-Cath TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1150-1320 Afternoon Session I Duluth INT *** lwig Light-Weight Implementation Guidance WG Laurier IRTF panrg Path Aware Networking Proposed RG Centre Ville SEC tokbind Token Binding WG From nobody Tue Jun 26 11:38:31 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F067131102 for ; Tue, 26 Jun 2018 11:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 1Uzs3xnrN4oB for ; Tue, 26 Jun 2018 11:38:18 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BE0131110 for ; Tue, 26 Jun 2018 11:38:18 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A437858C4D8; Tue, 26 Jun 2018 20:38:14 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8D2B34401A4; Tue, 26 Jun 2018 20:38:14 +0200 (CEST) Date: Tue, 26 Jun 2018 20:38:14 +0200 From: tte+ietf@cs.fau.de To: Dirk Kutscher , Melinda Shore , dinrg-chairs@ietf.org Cc: din@irtf.org Message-ID: <20180626183814.ipaz2htbli5od3kd@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B219430-1287-464E-8F16-008D1827C4D6@dkutscher.net> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Din] Inviting presentations for DINRG@Montreal X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 18:38:30 -0000 Asking for a presentation slot if appropriate, so Cc'ing the list. If appropriate, i would like to summarize how i would like to see (in role of ANIMA chair) for DINRG and ANIMA to collaborate. To get the idea: -> ANIMA charter round 1 work "ANI" that is now finishing through IESG was direct result of NMRG work defining the concepts of a self-x (bootstrapping, securing, addressing, ...) -> This ANI from ANIMA is meant to be the infrastructure for self-orchestrating distributed network services. But it does not define any such self-orchestrated network services. -> ANIMA now is looking into good use-case examples of self-orchestrated services and how to map it to what ANI provices. ANIMA also wants to define the methodology of building such self-orchestrated services through constructs ANIMA calls ASA ' Autonomic Service Agents'. -> So, i could give an overview of this, explain what support for self-orchestration of disributed services ANI provides today (that could be used by DINRG work), service-discovery etc. pp. and describe that planned future/ongoing work in anima and discuss how DINRG might be able to help/collaborate and benefit from ANIMA. Cheers Toerless > DINRG is going to meet in Montreal at IETF-102. > > In case you are interested to present or discuss something, please send > a message to the chairs. > > Best regards, > Melinda and Dirk > > [Din] Inviting presentations for DINRG@Montreal Dirk Kutscher From nobody Tue Jun 26 13:26:43 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C96130E3A for ; Tue, 26 Jun 2018 13:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com 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 tIiWkUZO7giF for ; Tue, 26 Jun 2018 13:26:39 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FCA7130E2C for ; Tue, 26 Jun 2018 13:26:39 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A04AA21CDC for ; Tue, 26 Jun 2018 16:26:38 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Tue, 26 Jun 2018 16:26:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=YxUB7t y+2rjgeZ/W6ePzy0q//oy6Q6Orsv22/OK8MJM=; b=NAA32NDV7z78Ogckkyl0sy 5BWno+VmVWnENBa/aN1zlOfJg9KCCuH+3Q2wlsf+1/PiQWzlKddVk7SFRI78H0VN BE1RsnDI9SqmdqDFUJsuFYurF1GMfAQZWMEPdb7ZE02msd9H5MCBLuz/TW0fgBxO XE0BDg9wHB3j9LWK0ql/NSlVqHw69dYpO1NGOvJ7hGZTh/sBsiCnicl+0S5qmH0p 2dU9DnV4OKyjQfBVvh/80J3JPUrN6mzZpzkXKSphEInORNDWrFl5wt+KByvFlFOX H7EPLQ6oif3cCfIfRAeXDpxy0hV6WGlvi7mRMBLfi78zkvbOoF6Erz/rwsV97AZg == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 33956BA4CF; Tue, 26 Jun 2018 16:26:38 -0400 (EDT) Message-Id: <1530044798.37490.1421365440.6A84213E@webmail.messagingengine.com> From: Jehan Tremback To: din@irtf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c In-Reply-To: <20180626183814.ipaz2htbli5od3kd@faui48f.informatik.uni-erlangen.de> References: <20180626183814.ipaz2htbli5od3kd@faui48f.informatik.uni-erlangen.de> Date: Tue, 26 Jun 2018 13:26:38 -0700 Archived-At: Subject: Re: [Din] Inviting presentations for DINRG@Montreal X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 20:26:42 -0000 Which day is the DIN meeting? -- Jehan Tremback jehan@altheamesh.com On Tue, Jun 26, 2018, at 11:38 AM, tte+ietf@cs.fau.de wrote: > Asking for a presentation slot if appropriate, so Cc'ing the list. > > If appropriate, i would like to summarize how i would like to see > (in role of ANIMA chair) for DINRG and ANIMA to collaborate. > > To get the idea: > -> ANIMA charter round 1 work "ANI" that is now finishing through IESG was > direct result of NMRG work defining the concepts of a self-x > (bootstrapping, securing, addressing, ...) > > -> This ANI from ANIMA is meant to be the infrastructure for self- > orchestrating > distributed network services. But it does not define any such self- > orchestrated > network services. > > -> ANIMA now is looking into good use-case examples of self-orchestrated > services and how to map it to what ANI provices. ANIMA also wants to > define the methodology of building such self-orchestrated services > through constructs ANIMA calls ASA ' Autonomic Service Agents'. > > -> So, i could give an overview of this, explain what support for self- > orchestration > of disributed services ANI provides today (that could be used by > DINRG work), > service-discovery etc. pp. and describe that planned future/ongoing > work in anima and discuss how DINRG might be able to help/collaborate > and benefit from ANIMA. > > Cheers > Toerless > > > DINRG is going to meet in Montreal at IETF-102. > > > > In case you are interested to present or discuss something, please send > > a message to the chairs. > > > > Best regards, > > Melinda and Dirk > > > > [Din] Inviting presentations for DINRG@Montreal Dirk Kutscher > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din From nobody Tue Jun 26 13:40:28 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6687130ED0 for ; Tue, 26 Jun 2018 13:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com 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 epWTK7caoqja for ; Tue, 26 Jun 2018 13:40:25 -0700 (PDT) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E7F130ECB for ; Tue, 26 Jun 2018 13:40:25 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id m16-v6so4345415pls.11 for ; Tue, 26 Jun 2018 13:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=bWjIncNgtD1SZ29nyDqOtftUjG//Ii8qxfpyS4RCYpo=; b=0bOCUcesT/UKSEujZUd+e8py5R9Tq4gX+/fHCye8JJ2hzHdC3lW0loaxw6LxxZg1nX az5ComYq1XespzKYY6UUaYJmaAC45GCsCA7KAULrIfDcmOJP1KjCzCH4vxExb03Sxo5y lslulMIDSdVGjrk+4alUDNueqOudWW04cGMOvMBeQA7QmYW4UpR+mVwA6cg3WTL4f77S EJhSFPDjA8W729sOHjLLsJHE2KRkH7myUdPkt/OVY+lOW4dThOzFyIl24qzFktIaXcdY I1dcNwwuysomCOTzPtTCdU+OQRKOkMaks/NzrUJv4zXb95pr36vY4N0AYmsZI1KogXf8 pV2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bWjIncNgtD1SZ29nyDqOtftUjG//Ii8qxfpyS4RCYpo=; b=HaP0lHDsaNitWLK/o5rkDYUpIv9tMkM6ibvJMhoc4tEpjLmgAzJYg8W8rM51EXetY7 lXf2EQIFrTTarzW4QOBecOYFLBrI4i95GDOMtJUxGk7SLkJ4Q+dcvwoC9wx1C6Ih2XTs Kkjpj2h6QGxx9VDYL8GsMnXIra3gE/9aGpEJX+MqrDpczdYn1J8U6mOqAdKJjrZriBLG HmTMtQxOlZun4BU0UZjvUF0btzLbhhazpbEFheUvKaA7Yc9dV1toETFpQnKy34iThwTk RxNa9aUmlejGxCu2rhuOvPtHae74AxuuG1YiLjIkDjWxOZ9MiYRR68Hput6WXAjr+333 UJgQ== X-Gm-Message-State: APt69E0tco5zLf5/rnpuaJm0AicLoMqowb4x5X+sfLUtaz4nVM/jstWu DIk9Sk+3tx7B5HG12aiw/Kuj2Iw= X-Google-Smtp-Source: ADUXVKJrVfV9LcQ1sazqeSRd4qByJan6J+NJN+BL2U1ge0xxAQxLXxb4GixtML5BmmxbWIfCUmy1VA== X-Received: by 2002:a17:902:8491:: with SMTP id c17-v6mr3049019plo.97.1530045624745; Tue, 26 Jun 2018 13:40:24 -0700 (PDT) Received: from aspen.local (63-140-89-164-radius.dynamic.acsalaska.net. [63.140.89.164]) by smtp.gmail.com with ESMTPSA id z12-v6sm3401879pgu.57.2018.06.26.13.40.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jun 2018 13:40:24 -0700 (PDT) To: din@irtf.org References: <20180626183814.ipaz2htbli5od3kd@faui48f.informatik.uni-erlangen.de> <1530044798.37490.1421365440.6A84213E@webmail.messagingengine.com> From: Melinda Shore Message-ID: Date: Tue, 26 Jun 2018 12:40:22 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1530044798.37490.1421365440.6A84213E@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Din] Inviting presentations for DINRG@Montreal X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 20:40:27 -0000 On 6/26/18 12:26 PM, Jehan Tremback wrote: > Which day is the DIN meeting? We're meeting Friday morning at 9:30. Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F From nobody Tue Jun 26 13:49:13 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20662130ECF for ; Tue, 26 Jun 2018 13:49:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 X7MM1aEW1ThG for ; Tue, 26 Jun 2018 13:49:08 -0700 (PDT) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2BF130ED6 for ; Tue, 26 Jun 2018 13:49:07 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id z9-v6so2263271plo.1 for ; Tue, 26 Jun 2018 13:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cTL4xU/oaF8x0oeFRRhMNpljHLmUO3USkdx/K/iSOQI=; b=bgDwg9Z68Q1PP/1m3NjzcTt6GFIaunJRD/ieyra+K60TYEwomprTc8klTPTR5cyJcc 33KgEC9X0FK6e+UB8uhZO3JoZwUZIiqnWbtvaLXA6H0iOh1/q+6GWbAcGtoBjeG12wBe WsOe4U57FqCZLFWlko1wdQW/WsWb9ZWdYt/+rycPmhql8AYkU5U4w4Y9VzHVZaa7dUHh uCqmHgKJfX+Kx8v0Ar61/KXTv9S6oxon7B0ha0BO00Y4n1T+r1162G9Chpg5FWvQ1Dy6 Pp1gIcAkSsLUtBDtHsJWujCt4Yc6uP/1koTtOKADUamRyNX6HTg3BWFVe3Of0pE1a2OW M7bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=cTL4xU/oaF8x0oeFRRhMNpljHLmUO3USkdx/K/iSOQI=; b=jJkJPImzpPeN1ILoDH9weiLR+ijRnwyTIPeJ7Ie+r/xLfwHXtpLvsYtEbspoX86SBt /nqtaRFqWNmvRLUPQD3MwtIj7RAJKfkdiAnqLgDfj0RU+TKeJfMoMKfc6CnfcnNk4W6P oJVs+EzRrnIR2Z7+8gNBp5ZKL8mTOCydyvdnAg+tLT4duwN3lB5CLposV83iJyD85BCt IpzTdhKmTJL8xOrEVp9ApsZjt2lphDsl8g6cvIF5quDfocPG5PM7vcGxusHejU2oofDH eVBAcMkc7hbQOL/PGx2Xugf1zK7MNUIwryv/WudJEdbn+B2X4G8KU3yzYP99+5Zqe+LC zBJg== X-Gm-Message-State: APt69E3EJYH0wtMVwvRUa4UHdQGY+2suyirmbC8WhWX7g175bLqwdmom ny0DF+7vfFoMNlSf1lTG9Yp4BA== X-Google-Smtp-Source: ADUXVKKVpaTeDcUkOGkgkUxJ06jw2udWxjyF7d8C5mm5ipZQEDTZSOHTh+20p82u/gbbMoDOB28VRA== X-Received: by 2002:a17:902:292b:: with SMTP id g40-v6mr3126202plb.273.1530046147244; Tue, 26 Jun 2018 13:49:07 -0700 (PDT) Received: from [192.168.178.38] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id q8-v6sm4872908pfi.96.2018.06.26.13.49.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jun 2018 13:49:06 -0700 (PDT) To: Jehan Tremback , din@irtf.org References: <20180626183814.ipaz2htbli5od3kd@faui48f.informatik.uni-erlangen.de> <1530044798.37490.1421365440.6A84213E@webmail.messagingengine.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 27 Jun 2018 08:49:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1530044798.37490.1421365440.6A84213E@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Din] Inviting presentations for DINRG@Montreal X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 20:49:12 -0000 On 27/06/2018 08:26, Jehan Tremback wrote: > Which day is the DIN meeting? Friday morning. I think it clashes with the off-site NMRG, so it seems to me we have a problem. Brian From nobody Tue Jun 26 14:04:57 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A978130E41 for ; Tue, 26 Jun 2018 14:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 pEgtU_MqvlxS for ; Tue, 26 Jun 2018 14:04:53 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB42130E3D for ; Tue, 26 Jun 2018 14:04:53 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0FCA658C4D8; Tue, 26 Jun 2018 23:04:49 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id F1BCF4401A4; Tue, 26 Jun 2018 23:04:48 +0200 (CEST) Date: Tue, 26 Jun 2018 23:04:48 +0200 From: Toerless Eckert To: Jehan Tremback Cc: din@irtf.org Message-ID: <20180626210448.m5fyr7oyfxl5qqlm@faui48f.informatik.uni-erlangen.de> References: <20180626183814.ipaz2htbli5od3kd@faui48f.informatik.uni-erlangen.de> <1530044798.37490.1421365440.6A84213E@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1530044798.37490.1421365440.6A84213E@webmail.messagingengine.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Din] Inviting presentations for DINRG@Montreal X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 21:04:56 -0000 Fri morning, see agenda. On Tue, Jun 26, 2018 at 01:26:38PM -0700, Jehan Tremback wrote: > Which day is the DIN meeting? > > -- > Jehan Tremback > jehan@altheamesh.com > > On Tue, Jun 26, 2018, at 11:38 AM, tte+ietf@cs.fau.de wrote: > > Asking for a presentation slot if appropriate, so Cc'ing the list. > > > > If appropriate, i would like to summarize how i would like to see > > (in role of ANIMA chair) for DINRG and ANIMA to collaborate. > > > > To get the idea: > > -> ANIMA charter round 1 work "ANI" that is now finishing through IESG was > > direct result of NMRG work defining the concepts of a self-x > > (bootstrapping, securing, addressing, ...) > > > > -> This ANI from ANIMA is meant to be the infrastructure for self- > > orchestrating > > distributed network services. But it does not define any such self- > > orchestrated > > network services. > > > > -> ANIMA now is looking into good use-case examples of self-orchestrated > > services and how to map it to what ANI provices. ANIMA also wants to > > define the methodology of building such self-orchestrated services > > through constructs ANIMA calls ASA ' Autonomic Service Agents'. > > > > -> So, i could give an overview of this, explain what support for self- > > orchestration > > of disributed services ANI provides today (that could be used by > > DINRG work), > > service-discovery etc. pp. and describe that planned future/ongoing > > work in anima and discuss how DINRG might be able to help/collaborate > > and benefit from ANIMA. > > > > Cheers > > Toerless > > > > > DINRG is going to meet in Montreal at IETF-102. > > > > > > In case you are interested to present or discuss something, please send > > > a message to the chairs. > > > > > > Best regards, > > > Melinda and Dirk > > > > > > [Din] Inviting presentations for DINRG@Montreal Dirk Kutscher > > > > _______________________________________________ > > Din mailing list > > Din@irtf.org > > https://www.irtf.org/mailman/listinfo/din > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din -- --- tte@cs.fau.de From nobody Tue Jun 26 14:07:47 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CC7130E42 for ; Tue, 26 Jun 2018 14:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 GcZyn88CZrxO for ; Tue, 26 Jun 2018 14:07:44 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A29130E41 for ; Tue, 26 Jun 2018 14:07:44 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D2C5C58C4D8; Tue, 26 Jun 2018 23:07:40 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C286C4401A4; Tue, 26 Jun 2018 23:07:40 +0200 (CEST) Date: Tue, 26 Jun 2018 23:07:40 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Jehan Tremback , din@irtf.org Message-ID: <20180626210740.s3ggjhjwlt5affc4@faui48f.informatik.uni-erlangen.de> References: <20180626183814.ipaz2htbli5od3kd@faui48f.informatik.uni-erlangen.de> <1530044798.37490.1421365440.6A84213E@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Din] Inviting presentations for DINRG@Montreal X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 21:07:46 -0000 Good point, Brian i wanted to go that as well. DINrg chairs: any chance to get DINrg moved to a different slot ? Cheers toerless On Wed, Jun 27, 2018 at 08:49:03AM +1200, Brian E Carpenter wrote: > On 27/06/2018 08:26, Jehan Tremback wrote: > > Which day is the DIN meeting? > > Friday morning. I think it clashes with the off-site NMRG, so it seems to me we have a problem. > > Brian > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din From nobody Tue Jun 26 14:22:10 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD35D130E3C for ; Tue, 26 Jun 2018 14:22:07 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scs.stanford.edu 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 RDLCxtQv-04D for ; Tue, 26 Jun 2018 14:22:06 -0700 (PDT) Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9D3130E2E for ; Tue, 26 Jun 2018 14:22:06 -0700 (PDT) Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.16.0.21/8.16.0.21) with ESMTP id w5QLLtY4022944; Tue, 26 Jun 2018 14:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scs.stanford.edu; s=scs; t=1530048115; bh=0Y70R5gm/LCKRiL3gMxccXkFNsV/vWcOsPTJaKU1J54=; h=From:To:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version; b=bAgt7cObmuTVm4N1qwY4UlgpIb0Zqag75N/09ycih2VB0zsX6rFRh2Vl3o/rGHHcC nYf/VVpk9RCCgSHf4Tgupef71M5kIppNPB+Z6XbsNwdTtPdNYX3yOmgRYHPYAzsxLz E0G0fkjSR/bHzNjLsMR2cZi4onZrc1BkJn/sw28k= Received: (from dm@localhost) by market.scs.stanford.edu (8.16.0.21/8.16.0.21/Submit) id w5QLLteG095579; Tue, 26 Jun 2018 14:21:55 -0700 (PDT) From: David Mazieres To: Toerless Eckert , Brian E Carpenter Cc: din@irtf.org, Jehan Tremback In-Reply-To: <20180626210740.s3ggjhjwlt5affc4@faui48f.informatik.uni-erlangen.de> References: <20180626183814.ipaz2htbli5od3kd@faui48f.informatik.uni-erlangen.de> <1530044798.37490.1421365440.6A84213E@webmail.messagingengine.com> <20180626210740.s3ggjhjwlt5affc4@faui48f.informatik.uni-erlangen.de> Reply-To: David Mazieres expires 2018-09-24 PDT Date: Tue, 26 Jun 2018 14:21:55 -0700 Message-ID: <8736x9451o.fsf@ta.scs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Din] Inviting presentations for DINRG@Montreal X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 21:22:08 -0000 Toerless Eckert writes: > Good point, Brian i wanted to go that as well. > > DINrg chairs: any chance to get DINrg moved to a different slot ? Some of us have already made our travel plans, so I really hope the DINRG meeting does NOT move... David From nobody Tue Jun 26 15:16:29 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7DA130E42 for ; Tue, 26 Jun 2018 15:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com 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 3eYzvW7DDvXj for ; Tue, 26 Jun 2018 15:16:25 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A25130EE9 for ; Tue, 26 Jun 2018 15:16:25 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id n2-v6so1786pgq.6 for ; Tue, 26 Jun 2018 15:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=26GoGWSRGZk9MsJ6w3eTxZ4mKo2FUZywqR3kmrj4vsM=; b=nekMHRKkB0ts/7rmM8DZ8BGpO2fFZ/njdJtQVQYxnNVJ9+etK2gVNw6XtNTga/jUen 4V6Ydv9hmTdOIkX3zkSn+hb8a/uj/M8uqxQ4JE16cQ7QSGbIPe6kZ7IZvST0iKsSpxqY PNZlaixRBoVjCGZSXoD4Dl71M1BTgeWlVjfeN5nr+X0d6qfmVe/utyxuQqftGVrOkEqr orAoAaCLyf+1kkM1c2t3SZRWYZNLYk9ko3yECQu9c4cJSn2SfHBnI3QrMzfCBjqQo2en I8tCCFC3ROmbxEIaDwfoym6oV5lgO1vD0UDXOMnrnT1PvGs0KswTwWytVMpJU0yW5ggJ 9RyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=26GoGWSRGZk9MsJ6w3eTxZ4mKo2FUZywqR3kmrj4vsM=; b=RyYmRwMHDknoBjCboF+EzCkhvmQrHgflEpC8zgWG5pzWCxl3hWiuh1HKhG2o/oy2aA vXWS1l2Hn4NhRyaRaZ2iCAP4vunnSS6XXRK4mbB8myl08FWTRN5hf7mbkfc6Hy+7hdhq cr5WyYCJ2OMTbHSh7n36OhdspeQeejyTcFbfJn4gPEGNz/24Zm7KBaEzj/Rrk0eFb30z Y3h4D/R1Lgqq4YSxZjPhLj/QuJGPk8Q+aCfNwBygN8Q8AUhCw+fguPpUnq+EXjpt3xnj 2jtLFJjXpwGeQWhSAktvFyyJAr+/yreqMTlz/UMe8Me2mEKBCT5S3bIRqxDHcYHZX4gL el/A== X-Gm-Message-State: APt69E0LKBahQTM3zAH6+IbDDfafreHQ+Ql3jRSf7/ErgTVL3y3l6gET Btu+NAGI0rY2OQ82qMfFR1zngp4= X-Google-Smtp-Source: ADUXVKI+tlomCqr1Q4yu2R25KxONN8WsZOMopZfxWh83MGsDH+3PLqPT4wssCFED6b6zlYKIZY4lsg== X-Received: by 2002:a65:611a:: with SMTP id z26-v6mr2844810pgu.61.1530051384555; Tue, 26 Jun 2018 15:16:24 -0700 (PDT) Received: from aspen.local (63-140-89-164-radius.dynamic.acsalaska.net. [63.140.89.164]) by smtp.gmail.com with ESMTPSA id l14-v6sm4060249pgc.0.2018.06.26.15.16.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jun 2018 15:16:24 -0700 (PDT) To: din@irtf.org References: <20180626183814.ipaz2htbli5od3kd@faui48f.informatik.uni-erlangen.de> <1530044798.37490.1421365440.6A84213E@webmail.messagingengine.com> <20180626210740.s3ggjhjwlt5affc4@faui48f.informatik.uni-erlangen.de> From: Melinda Shore Message-ID: Date: Tue, 26 Jun 2018 14:16:21 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180626210740.s3ggjhjwlt5affc4@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Din] Inviting presentations for DINRG@Montreal X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 22:16:27 -0000 On 6/26/18 1:07 PM, Toerless Eckert wrote: > Good point, Brian i wanted to go that as well. > > DINrg chairs: any chance to get DINrg moved to a different slot ? We've got a number of academic participants (including active contributors) who don't otherwise participate in the IETF and who've already made their travel plans. Plus, having the ANRW on Monday has made scheduling research groups even more challenging than usual. That said, for those who are interested we can schedule an informal side meeting during the week, perhaps with a focus on the relationship between dinrg's problem space and what anima is doing. Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F From nobody Tue Jun 26 15:31:49 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFC3130E42 for ; Tue, 26 Jun 2018 15:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 fW00k0HzgkXY for ; Tue, 26 Jun 2018 15:31:44 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B52129C6A for ; Tue, 26 Jun 2018 15:31:43 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 01F0058C4D8; Wed, 27 Jun 2018 00:31:39 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id E4F394401A4; Wed, 27 Jun 2018 00:31:38 +0200 (CEST) Date: Wed, 27 Jun 2018 00:31:38 +0200 From: Toerless Eckert To: Melinda Shore Cc: din@irtf.org Message-ID: <20180626223138.eexveybgkt3a3ia7@faui48f.informatik.uni-erlangen.de> References: <20180626183814.ipaz2htbli5od3kd@faui48f.informatik.uni-erlangen.de> <1530044798.37490.1421365440.6A84213E@webmail.messagingengine.com> <20180626210740.s3ggjhjwlt5affc4@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Din] Inviting presentations for DINRG@Montreal X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 22:31:47 -0000 Melinda: I requested to present at DINRG re. ANIMA so i will certainly be at DINRG if i can present, don't worry about me ;-) If you think we shouldn't or can not have time to present/ discuss during RG meeting on friday, i am happy to take your guidance how else its best discussed. [ There are several colleagues who will track / participate in the NMRG side meeting ]. And sorry for even suggesting to change meeting time this late. Did obviously not make a lot of sense re. existing travel plans, thanks for folks replying with that insight. Forgot that the tracvel planning in IRTF is often so different from what i am used to. Cheers Toerless On Tue, Jun 26, 2018 at 02:16:21PM -0800, Melinda Shore wrote: > On 6/26/18 1:07 PM, Toerless Eckert wrote: > > Good point, Brian i wanted to go that as well. > > > > DINrg chairs: any chance to get DINrg moved to a different slot ? > > We've got a number of academic participants (including > active contributors) who don't otherwise participate > in the IETF and who've already made their travel plans. > Plus, having the ANRW on Monday has made scheduling > research groups even more challenging than usual. That > said, for those who are interested we can schedule an > informal side meeting during the week, perhaps with a > focus on the relationship between dinrg's problem space > and what anima is doing. > > Melinda > > > -- > Software longa, hardware brevis > > PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 > 34C0 DFB8 9172 9A76 DB8F > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din -- --- tte@cs.fau.de From nobody Tue Jun 26 16:24:19 2018 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6925A130E69 for ; Tue, 26 Jun 2018 16:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com 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 6CbS6oW1qKVq for ; Tue, 26 Jun 2018 16:24:12 -0700 (PDT) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31C87131150 for ; Tue, 26 Jun 2018 16:24:12 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id 31-v6so70381plc.4 for ; Tue, 26 Jun 2018 16:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jjNaKukNDp3JPf9N5GtXU/Fffm5VPqn1jUXW/JFHiHY=; b=YZrqe0it7H0GU0ZDY0St49DFYC0qXFDc90s9qY9Jp/CMYTSbDw1DtUSiKE9qmdiPJT 152hPaOO4pk6q3/TtiN3I+269TK3QxZvbTFzI10LSboiG+rh0gTeihP+/ugx3IXg8nKy R1UWGSJGQMUWeJnOAym5MzEaVLSca/ykQM7bTswcb9r5MWravU+0vTNqfXujOqvIWRrg v5pR0E6ie9pIgtsDh7iEVlWYdVEhA2QM0CAHR+EWAfdUHgZzyRUlKlEVYh8YyyoU/8D5 WeTazEadsGS04xvwo/v5TyhX3NLwS2mLyStPtNSwcDgfGe3Jsp7dpBQ6SITroHoYR7te mTkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jjNaKukNDp3JPf9N5GtXU/Fffm5VPqn1jUXW/JFHiHY=; b=pf2hyGCk29i2KYCJcrUWSBYqG7k5qXtjPlpWjsXzwDdb6Di6n8n6ZkX/TdgpfGCjD9 z0pNTNHBByskx/C2OwbDcexLQw1mUCoxT8BtVl1NdXLXPSo8gbEcJ0nux+UrW30YFLDq CJ2OOnfR3hsjTGqj5mB1QwEz+Thc0J0USXBWhLhUfQLSV5ISWgbCMMWEftqHvTXubEXL zR5cR3AFEFxRAoYbS3Bilej94I6T5CvfSO0PZwx8kAIM+kd9OWAD4lMXaZ078VT2w0Ua 9QspelwetiUSSZlwwk1UwQbxaGuQ95mIkO/kJNr1Dt4kK8FkEINq453V8NUx/gWGINA2 yPPA== X-Gm-Message-State: APt69E2yCu8vjWhXZvnsnj8WWnGuMTEcVjkE4SEpVCHM/ePikrAr8mlf I2hJ2aQtxd6u9niFWtzv3DhjVls= X-Google-Smtp-Source: ADUXVKLb+/tNsBq2j+8nmhqCRiDje5gKklEe9Lo9l8D47o4mMv+rU+A/eDjy+ZMG4It2hi2F+JjgJw== X-Received: by 2002:a17:902:b60b:: with SMTP id b11-v6mr3645649pls.330.1530055451543; Tue, 26 Jun 2018 16:24:11 -0700 (PDT) Received: from aspen.local (63-140-89-164-radius.dynamic.acsalaska.net. [63.140.89.164]) by smtp.gmail.com with ESMTPSA id m10-v6sm5506332pfi.101.2018.06.26.16.24.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jun 2018 16:24:11 -0700 (PDT) To: Toerless Eckert Cc: din@irtf.org References: <20180626183814.ipaz2htbli5od3kd@faui48f.informatik.uni-erlangen.de> <1530044798.37490.1421365440.6A84213E@webmail.messagingengine.com> <20180626210740.s3ggjhjwlt5affc4@faui48f.informatik.uni-erlangen.de> <20180626223138.eexveybgkt3a3ia7@faui48f.informatik.uni-erlangen.de> From: Melinda Shore Message-ID: Date: Tue, 26 Jun 2018 15:24:09 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180626223138.eexveybgkt3a3ia7@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Din] Inviting presentations for DINRG@Montreal X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 23:24:16 -0000 On 6/26/18 2:31 PM, Toerless Eckert wrote: > Melinda: I requested to present at DINRG re. ANIMA so i > will certainly be at DINRG if i can present, don't worry about me ;-) Excellent, thanks. As usual we have more requests than time available, but we'll try to get a draft agenda out soon, and then tweak as needed. Among the things we need to be thinking about as we discuss the transition to a chartered research group is the relationship to other work being done in both the IRTF and the IETF, so we'll want to discuss anima with you either way. Many thanks! Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F