From nobody Tue Jun 13 01:18:09 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B519129BBF for ; Tue, 13 Jun 2017 01:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 xrXlUFAHwjHh for ; Tue, 13 Jun 2017 01:18:05 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 79C73129BBD for ; Tue, 13 Jun 2017 01:18:05 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id p62so60157459vkp.0 for ; Tue, 13 Jun 2017 01:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=Zeu1VBWDjulJ6ss137tyRHg0sOYSfm1X8b/VULfrSRM=; b=I2i9smpDV2A5ZQ13/HLdj/yZ3HGCuH9j1FGvXDgdOOoJ8B2Qj/V0JfXwYHnDC9XaSN NnWm3maAakTsrXcFHLmHW2mjsKwXDbgJGlxWpoFXPh/yYGAjdmWiQ5x7UYR3PVK6WA9R 3QwuVke9P3dbKtX0u+bgLivSlybENyVVkkDAA= 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=Zeu1VBWDjulJ6ss137tyRHg0sOYSfm1X8b/VULfrSRM=; b=qtHx7JQ0zaH9MXmmI7eiA/d9da0N2JfBWW4hsZQ35p4lG2C96JSnkhIrh5YQaF93Im s1UYYqNNrzLpUcEl8xRx89AdF/sIeGowEK/XkqfP6EuVKBVtE8Ybz20Fyc4391q3xYXM 5uM5Fv0BduGLRuSg8qUN8THCwsnMg/Rgi+Ryf2cPdCihPp34fzzmKxkLcxzFQJzGdmXO DxcrXQZSiRo0Pb4P8OprWi8EdBKFWV5TgUBeXyb0D0xN/+viOv3D1Mo0rKn6qA832+14 u/ZNAwd5klc24AbVcrwB1oF/NTKQdBfwfhGQ7AzOFyzQUjM+JClmyxevB/3Q7wGbikZ9 Y+1A== X-Gm-Message-State: AODbwcAXaX2qeu61+gkHo01tgo7em0pqNXvIEEZZo7I77G7mltba1TBh 4bYaCBieSEBj7yWmESvkSSKtP5ESu0Vq X-Received: by 10.31.32.4 with SMTP id g4mr26587975vkg.140.1497341884473; Tue, 13 Jun 2017 01:18:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.75.144 with HTTP; Tue, 13 Jun 2017 01:18:03 -0700 (PDT) From: Adrian Hope-Bailie Date: Tue, 13 Jun 2017 10:18:03 +0200 Message-ID: To: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a113da64621b7400551d313fc" Archived-At: Subject: [Ledger] AGENDA - Interledger Call - 3pm UTC - 14 June X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 08:18:07 -0000 --001a113da64621b7400551d313fc Content-Type: text/plain; charset="UTF-8" Hi all, We're back to our bi-weekly schedule for our community calls. Looking forward to catching up on the workshop in Berlin and discussing where we take things from here. AGENDA - Workshop Recap (Adrian) - ILP-Kit Roadmap (Stefan) - Ideas here: https://gist.github.com/justmoon/8a22710b7e10ed2b684694376fac8330 - 10+ ledger demo (Evan) *Dial In Details* To join the meeting, go to: https://bluejeans.com/795795755 (Try your iPhone or Android phone) Just want to dial in? (http://bluejeans.com/numbers) Enter Meeting ID: 795795755 *Reminder that all calls are recorded.* --001a113da64621b7400551d313fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

We're ba= ck to our bi-weekly schedule for our community calls. Looking forward to ca= tching up on the workshop in Berlin and discussing where we take things fro= m here.

AGENDA

- Workshop Recap (Adrian)
- ILP-Kit Roadmap (Stefan) - Ideas here: https://gist.github.com/justmo= on/8a22710b7e10ed2b684694376fac8330
- 10+ ledger demo (Evan)

Dial In Details

To join the meeting, go to:https://blu= ejeans.com/795795755
(Try your iPhone or Android phone)

= Just want to dial in? (http://bluejeans.com/numbers)
Enter Meeting ID: 795795755
=
Reminder that all calls are recorded.
--001a113da64621b7400551d313fc-- From nobody Thu Jun 15 07:32:47 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2606812E040 for ; Thu, 15 Jun 2017 07:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 5_KfyNDQAMod for ; Thu, 15 Jun 2017 07:32:44 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 39BC0129505 for ; Thu, 15 Jun 2017 07:32:44 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id 191so7878794vko.2 for ; Thu, 15 Jun 2017 07:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=a3apZ3qLzgDR6X4FqgE04T3F1KSSZqqshy7PEMw6arA=; b=HpPF0kHOFQgf9h+i4d34H172Qq8OzL660Dc/oCmmrjuNM9k4gdxXOYwQz6trhRDqDz JxRBS/OPdjdvaIOP9JQI7PIVIN18iO7GJeOE6+3MzdHO7x3VJswiVbSwzPd3LEfyi3Lx u/j/AmDreYAuPpDL5Y+LzWMOU8vm5zvmKBBqk= 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=a3apZ3qLzgDR6X4FqgE04T3F1KSSZqqshy7PEMw6arA=; b=aXToSjpy2cTXlkhf2/+jX9DYzouzE2PIZ8LpF7ZlufPy7JmBeoC6WZ6fc9CYjrDEot B4yKKA9a8bXPN1JI94oSKEEkEbZlpkc24mJOmyHcpVl3sv5lBa4cUku4ErwLsX899lp+ wB4KFXRMzWrY1n+qRYOEnySXWfLiy3Bd7RVxlkG7kj3EKBjH12QKQaW8SnUMBeAswcDk DEJi+QysPr5ig5/1QbLwDigxKVa3bd2ocPfNXFROKBsWc+1grwlm8001/HFaz3YFwnPR VGADzg2ZVBO+Y3p1Nvjq0nYj+nf2ouLoCdU6GxsXrOoey4bbmTGeaY2zBpPFTM/xp7SY AnVw== X-Gm-Message-State: AKS2vOxwtvHBf5T/oazR7NkYUUras3lr3Qn6mqsw31OBvK+R4QoAQO97 +AlivlU1aZp0fu4dfFQ+ShouuCOuKIPH X-Received: by 10.31.252.3 with SMTP id a3mr3230504vki.31.1497537163180; Thu, 15 Jun 2017 07:32:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.150.74 with HTTP; Thu, 15 Jun 2017 07:32:42 -0700 (PDT) From: Adrian Hope-Bailie Date: Thu, 15 Jun 2017 16:32:42 +0200 Message-ID: To: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="94eb2c14944aa697d90552008ad7" Archived-At: Subject: [Ledger] Workshop report X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 14:32:46 -0000 --94eb2c14944aa697d90552008ad7 Content-Type: text/plain; charset="UTF-8" Hi all, I put the following short blog together about the workshop and hackathon. In it are links to the slides and some photos and demo code. https://adrian.hopebailie.com/making-history-in-berlin-78f1533787f0 The videos are not yet ready but will be shared as soon as they are! Adrian --94eb2c14944aa697d90552008ad7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I put the f= ollowing short blog together about the workshop and hackathon. In it are li= nks to the slides and some photos and demo code.

https://adrian= .hopebailie.com/making-history-in-berlin-78f1533787f0

The = videos are not yet ready but will be shared as soon as they are!

Adrian

--94eb2c14944aa697d90552008ad7-- From nobody Tue Jun 20 03:03:17 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89C513196E for ; Tue, 20 Jun 2017 03:03:16 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 icR5XQ858fOP for ; Tue, 20 Jun 2017 03:03:09 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 857FD131976 for ; Tue, 20 Jun 2017 03:03:09 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id j53so62337205uaa.2 for ; Tue, 20 Jun 2017 03:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=JQOJWkIn59+r3Zr45KEzy4wRt6iaVb4qUTSv1GAnRUs=; b=fDnID+aQhXp7fRzAN0UdFl1P7unymalJful/WtZUzHPwIEL/DA2x1232/gyh6+fRS3 FM7pDL+yCCNNDSWLKR5EaBGyxV7zuV6JDCaeyepKICX24Or3FWy7k3Qxm0moMNPL0H/6 GCgtnpjvBfUnei93b+uEZynDwpdD6n37T2kw0= 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=JQOJWkIn59+r3Zr45KEzy4wRt6iaVb4qUTSv1GAnRUs=; b=FJqgoraQgJDU+lF/QwN5V5h0s5eEu1b8quIuH+5TfHePYVGwPuliDohHUDyFQQW980 fL07CqBsX+/bieZyawD8ZuKthpEamZyRgTRNmXedc5oaJlNQX3XNMOpD6L3rs98qi8/n nbPdX1IWRZIHSlmFt0N5juQpSPVnO6YLlp/ktVDSDudjqPuW1TCNirM/j7DQzBUaDxXq 6qLyqeaUe3StAUpCJpsBtuSMS7+HgE2JM0CIs5fgLv1XMkOyviNUV03OZx6UqM+oSzkv DGq0uSIdEk0EiUvJxiekZEA3LsdlXIVbSobeso4Rr+Mfc91tj+/iufoWqtwbTOxpLvcM NWig== X-Gm-Message-State: AKS2vOy5+tbkCvfpjw6wvlsyVhyoBzs0Fxl+AQpipmvFgTAqYpnTgxIn z+f1kq8Q0+s149Q+nTyiLcPoMHcMUWiL X-Received: by 10.176.85.20 with SMTP id t20mr5836266uaa.28.1497952988558; Tue, 20 Jun 2017 03:03:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.150.74 with HTTP; Tue, 20 Jun 2017 03:03:08 -0700 (PDT) From: Adrian Hope-Bailie Date: Tue, 20 Jun 2017 12:03:08 +0200 Message-ID: To: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="f403045dd964c6109f0552615be2" Archived-At: Subject: [Ledger] Proposed Interledger RFC process X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 10:03:17 -0000 --f403045dd964c6109f0552615be2 Content-Type: text/plain; charset="UTF-8" As discussed before we have an issue whereby our Interledger RFCs are regularly changing and it's not possible for someone to refer to a static version of the document and be sure that the content won't substantially change the next time they visit the URL. I had initially proposed that we introduce semantic versioning on the RFCs but we decided against this on the basis that we should: a) Differentiate between specs that are incubating (similar to IETF Internet Drafts) and those that are mature (similar to IETF RFCs) b) Assign an RFC number to stable specs and a new number to revisions of that As such my proposal is that we adopt the following process for the Interledger RFCs going forward (this is something of a hybrid between the IETF and W3C processes and is in keeping with the process defined for us as a W3C Community Group): 1. There are two document types *Working Drafts* and *Candidate Specifications*. 2. Interledger RFCs are living documents that start as *Working Drafts*. 3. Working Drafts have an RFC number AND a draft number starting at 0 and increasing by 1 each time the content is changed. Attempting to merge changes to a Working Draft without incrementing the draft number should result in a build failure of the publishing process. 4. When a *Working Draft* is considered stable there is a call for review from the community to publish the document as a *Candidate Specification* 5. Assuming there is consensus to publish, the document becomes a *Candidate Specification* and no further substantive changes are allowed under the same RFC number. NOTES: - Candidate Specifications SHOULD also be published as W3C Community Group reports. - Candidate Specifications MAY be published as IETF Internet Drafts. - A different template should be used for Working Drafts and Candidate Specifications to help readers differentiate between them. - An explanation of this process should be available on the website and linked from the RFCs --f403045dd964c6109f0552615be2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As discussed before we = have an issue whereby our Interledger RFCs are regularly changing and it= 9;s not possible for someone to refer to a static version of the document a= nd be sure that the content won't substantially change the next time th= ey visit the URL.

I had initially proposed that we intro= duce semantic versioning on the RFCs but we decided against this on the bas= is that we should:

a) Differentiate between specs that are inc= ubating (similar to IETF Internet Drafts) and those that are mature (simila= r to IETF RFCs)
b) Assign an RFC number to stable specs and a new = number to revisions of that

As such my proposal is that we ado= pt the following process for the Interledger RFCs going forward (this is so= mething of a hybrid between the IETF and W3C processes and is in keeping wi= th the process defined for us as a W3C Community Group):

= 1. There are two document types Working Drafts and Candidate Spec= ifications.
2. Interledger RFCs are living documents that star= t as Working Drafts.
3. Working Drafts have an RFC number AND a = draft number starting at 0 and increasing by 1 each time the content is cha= nged. Attempting to merge changes to a Working Draft without incrementing t= he draft number should result in a build failure of the publishing process.=
4. When a Working Draft is considered stable there is a call for= review from the community to publish the document as a Candidate Specif= ication
5. Assuming there is consensus to publish, the do= cument becomes a Candidate Specification and no further substantive = changes are allowed under the same RFC number.

NOTES:
=
  • Candidate Specifications SHOULD also be published as W3C= Community Group reports.
  • Candidate Specifications MAY be published= as IETF Internet Drafts.
  • A different template should be used for W= orking Drafts and Candidate Specifications to help readers differentiate be= tween them.
  • An explanation of this process should be available on t= he website and linked from the RFCs

--f403045dd964c6109f0552615be2-- From nobody Wed Jun 21 06:54:55 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C313129B1E for ; Wed, 21 Jun 2017 06:54:54 -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, 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 (1024-bit key) header.d=ripple.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 traE4t8o5Jup for ; Wed, 21 Jun 2017 06:54:52 -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 84B21129AEB for ; Wed, 21 Jun 2017 06:54:51 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id 77so136184911wrb.1 for ; Wed, 21 Jun 2017 06:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ripple.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8FGXm5gMDuXoCjvhwScQzzDl/IFGEniWv5LLatwhCmc=; b=SgLuOTCjCn63dR3Mzh6QgQP7UEzuHCAM0ljD4yugg4z30rjbYKw3rXfMVpqA1dhPrz aXhJt1wmCN64wgL2iqGQxaWOJVfPiwtdTH/yCOfEYtxodBOziER+pdPhwfJqrl4JdJYc q3hyElIyZHJrmHI7DzubqRJQRUxgLWMUy/VXw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8FGXm5gMDuXoCjvhwScQzzDl/IFGEniWv5LLatwhCmc=; b=Sz9Z7zQGbDZD2vvVuCbTfBQfdE0H1B1FW/ds5tWLV5M3DY97FRbbwJLQHwEhzAlBmV 0IPgulx+UzRqud8KI+v9xPtzLCSUkWyKflhHuzyq9Kd4fm8AUC5BY+QcwjBFx65xWgYm fBh8RFzxDMl6lobeF/8E/gBeJ/t2wV0tYXgUqDqarYld9mr2rCp+GGEapBa2wAj4WHev 3posXfPtnEVRqbgPA0ZxlAmd03z3fIUaDG7WgHI0jYtzt85Jwyl3B3rWK+jvIm2acGFL GuB4fTaUkiItPf8Lhd/aJZhf2C/oCf+ah9j15VaBuhlA9tTmKBsnLFXdSJkylQTJvIL1 CW+w== X-Gm-Message-State: AKS2vOxAs9NbpxLDJHjMvd/9ppqkUgXlnfDxRZZi0HLrqoBvh0CWQb7T 58TCMBRWR3aXaf6X7EWm2UWbmXz9h4ORa5U= X-Received: by 10.223.172.231 with SMTP id o94mr24464351wrc.201.1498053290014; Wed, 21 Jun 2017 06:54:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Evan Schwartz Date: Wed, 21 Jun 2017 13:54:39 +0000 Message-ID: To: Adrian Hope-Bailie , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a113c42dc34c670055278b68c" Archived-At: Subject: Re: [Ledger] Proposed Interledger RFC process X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 13:54:55 -0000 --001a113c42dc34c670055278b68c Content-Type: text/plain; charset="UTF-8" Just to clarify: - Would working drafts and candidate specifications live in different places? Which one would github.com/interledger/rfcs hold? - If I have a new Interledger-related idea, would I just submit a PR to the RFCs repo and claim the next available number? Or should I submit a PR with no number and have a maintainer assign the number (got that idea from Yarnjs ). - Is "version 1" of ILQP, for example, always going to "live" in the same numbered RFC? Would "version 2" then be a different RFC number and minor updates to the original one just increment the draft number? - Trickier question: what defines "consensus to publish"? Who are the stakeholders that need to agree? On Tue, Jun 20, 2017 at 12:03 PM Adrian Hope-Bailie wrote: > As discussed before we have an issue whereby our Interledger RFCs are > regularly changing and it's not possible for someone to refer to a static > version of the document and be sure that the content won't substantially > change the next time they visit the URL. > > I had initially proposed that we introduce semantic versioning on the RFCs > but we decided against this on the basis that we should: > > a) Differentiate between specs that are incubating (similar to IETF > Internet Drafts) and those that are mature (similar to IETF RFCs) > b) Assign an RFC number to stable specs and a new number to revisions of > that > > As such my proposal is that we adopt the following process for the > Interledger RFCs going forward (this is something of a hybrid between the > IETF and W3C processes and is in keeping with the process defined for us as > a W3C Community Group): > > 1. There are two document types *Working Drafts* and *Candidate > Specifications*. > 2. Interledger RFCs are living documents that start as *Working Drafts*. > 3. Working Drafts have an RFC number AND a draft number starting at 0 and > increasing by 1 each time the content is changed. Attempting to merge > changes to a Working Draft without incrementing the draft number should > result in a build failure of the publishing process. > 4. When a *Working Draft* is considered stable there is a call for review > from the community to publish the document as a *Candidate Specification* > 5. Assuming there is consensus to publish, the document becomes a *Candidate > Specification* and no further substantive changes are allowed under the > same RFC number. > > NOTES: > > - Candidate Specifications SHOULD also be published as W3C Community > Group reports. > - Candidate Specifications MAY be published as IETF Internet Drafts. > - A different template should be used for Working Drafts and Candidate > Specifications to help readers differentiate between them. > - An explanation of this process should be available on the website > and linked from the RFCs > > > _______________________________________________ > Ledger mailing list > Ledger@ietf.org > https://www.ietf.org/mailman/listinfo/ledger > -- Evan Schwartz Software Engineer Managing Director of Ripple Luxembourg --001a113c42dc34c670055278b68c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to clarify:

  • Would working = drafts and candidate specifications live in different places? Which one wou= ld github.com/interledger/rf= cs hold?
  • If I have a new Interledger-related idea, would I = just submit a PR to the RFCs repo and claim the next available number? Or s= hould I submit a PR with no number and have a maintainer assign the number = (got that idea from Yarnjs).
  • Is "version 1" of ILQP, for exa= mple, always going to "live" in the same numbered RFC? Would &quo= t;version 2" then be a different RFC number and minor updates to the o= riginal one just increment the draft number?
  • Trickier question: wha= t defines "consensus to publish"? Who are the stakeholders that n= eed to agree?

On Tue, Jun 20, 2017 at 12:03 PM Adrian Hope-Bailie <adrian@hopebailie.com> wro= te:
As discussed before we have an issue whereby our Inter= ledger RFCs are regularly changing and it's not possible for someone to= refer to a static version of the document and be sure that the content won= 't substantially change the next time they visit the URL.

=
I had initially proposed that we introduce semantic versioning on the= RFCs but we decided against this on the basis that we should:

a) Differentiate between specs that are incubating (similar to IETF Intern= et Drafts) and those that are mature (similar to IETF RFCs)
b) Ass= ign an RFC number to stable specs and a new number to revisions of that
=
As such my proposal is that we adopt the following process for th= e Interledger RFCs going forward (this is something of a hybrid between the= IETF and W3C processes and is in keeping with the process defined for us a= s a W3C Community Group):

1. There are two document types= Working Drafts and Candidate Specifications.
2. Int= erledger RFCs are living documents that start as Working Drafts. 3. Working Drafts have an RFC number AND a draft number starting at 0 and = increasing by 1 each time the content is changed. Attempting to merge chang= es to a Working Draft without incrementing the draft number should result i= n a build failure of the publishing process.
4. When a Working Draft<= /b> is considered stable there is a call for review from the community to p= ublish the document as a Candidate Specification
5. As= suming there is consensus to publish, the document becomes a Candidate S= pecification and no further substantive changes are allowed under the s= ame RFC number.

NOTES:
  • Candidate Sp= ecifications SHOULD also be published as W3C Community Group reports.
    • <= li>Candidate Specifications MAY be published as IETF Internet Drafts.<= li>A different template should be used for Working Drafts and Candidate Spe= cifications to help readers differentiate between them.
  • An explanat= ion of this process should be available on the website and linked from the = RFCs

_______________________________________________
Ledger mailing list
Ledger@ietf.org https://www.ietf.org/mailman/listinfo/ledger
--

<= div dir=3D"ltr">
Software Engineer
Managing Director of Ripple Luxembourg
=
--001a113c42dc34c670055278b68c-- From nobody Wed Jun 21 09:01:24 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69B212EC00 for ; Wed, 21 Jun 2017 09:01:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 1mgzugpPJu60 for ; Wed, 21 Jun 2017 09:01:15 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 266F812EBE0 for ; Wed, 21 Jun 2017 09:00:57 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id z22so22240039uah.1 for ; Wed, 21 Jun 2017 09:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kxAJTdFTYvL6rUwiK6/I8p+9/s/L17pLHE9HeM2Fb18=; b=JW7xG7gqerE1k6cF/iGg6O54coHcvwPa7XwrfjkzBbJvijfw07pjSzy2L1f3g8tVQS vqY8phMdC6QDUKqf2Znxu21Kao+aGa2AQ8Wy5zvsriqOD7SDa75YLLtxXVM6rrFf2HUw mLIJLkAJgUFdYYk2LSZ8m7GyaSMy87VO/WqjI= 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=kxAJTdFTYvL6rUwiK6/I8p+9/s/L17pLHE9HeM2Fb18=; b=bjCe9bu+8b5uU/QIjv9jCsR6EyAXS10fNC+vqKXh+8MFmfGeWkGhMpdrt3kseDwZk+ Khn8kNinHxas5dsR2Cc2+/Q3kIcN3eUrOxTAlUi0SMzXtEjFrjr7m5Xavo4ZAHvuzLKW 2PFS+1T7AuT55E3mbQyP1Du3paRJkM1a3QC9iZkcfPywhHkqueGj7FydLY7ghv1SEK0c h/ry509kXFQTsXJD+8gT95tM+3s7HSSxUaoCUKw3Fm9dcnFXR5s2IV6OSddQzTa//9rg JXzJlVoXkLJf8WCCcAA2pvPwaTaHOTVhQcI0iOwPFOcaWVYso6Rrrh7lKDYBI/FyDznx IxHw== X-Gm-Message-State: AKS2vOx8jwRzIyrFFaGkVApdEXJk/vsch/3VXnIy1BDcF2qkghE5UQ7J LgP6nGybWGLVe/X4LSKJagCVOwgbzL3O X-Received: by 10.159.41.196 with SMTP id s62mr25351016uas.136.1498060856080; Wed, 21 Jun 2017 09:00:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.150.74 with HTTP; Wed, 21 Jun 2017 09:00:55 -0700 (PDT) In-Reply-To: References: From: Adrian Hope-Bailie Date: Wed, 21 Jun 2017 18:00:55 +0200 Message-ID: To: Evan Schwartz Cc: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="94eb2c061ec02e2aba05527a7987" Archived-At: Subject: Re: [Ledger] Proposed Interledger RFC process X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:01:19 -0000 --94eb2c061ec02e2aba05527a7987 Content-Type: text/plain; charset="UTF-8" On 21 June 2017 at 15:54, Evan Schwartz wrote: > Just to clarify: > > > - Would working drafts and candidate specifications live in different > places? Which one would github.com/interledger/rfcs hold? > > No, same place but they'd render on the website with a different template (similar to W3C specs). Once an RFC becomes a Candidate Spec attempting to merge changes will result in test errors so unless a maintainer overrides they should never change. > > - > - If I have a new Interledger-related idea, would I just submit a PR > to the RFCs repo and claim the next available number? Or should I submit a > PR with no number and have a maintainer assign the number (got that idea > from Yarnjs ). > > Good question. I like that suggestion. Will document i that way. To submit a draft you submit a PR with the draft. If a maintainer accepts it they'll add a commit to the PR renaming it to claim an RFC number. > > - > - Is "version 1" of ILQP, for example, always going to "live" in the > same numbered RFC? Would "version 2" then be a different RFC number and > minor updates to the original one just increment the draft number? > > That's the idea. Unless we start documenting v2 before v1 is stable and moved to Candidate Spec. > > - Trickier question: what defines "consensus to publish"? Who are the > stakeholders that need to agree? > > I'd consider consensus to mean nobody has objected strongly. W3C has a formal process which we can use and that's roughly it. Dimi and I as the chairs are responsible for getting and evaluating consensus. Given the current makeup of the group and level of participation from various people I expect we'd weight the opinion of the maintainers and major contributors highly. > > > On Tue, Jun 20, 2017 at 12:03 PM Adrian Hope-Bailie > wrote: > >> As discussed before we have an issue whereby our Interledger RFCs are >> regularly changing and it's not possible for someone to refer to a static >> version of the document and be sure that the content won't substantially >> change the next time they visit the URL. >> >> I had initially proposed that we introduce semantic versioning on the >> RFCs but we decided against this on the basis that we should: >> >> a) Differentiate between specs that are incubating (similar to IETF >> Internet Drafts) and those that are mature (similar to IETF RFCs) >> b) Assign an RFC number to stable specs and a new number to revisions of >> that >> >> As such my proposal is that we adopt the following process for the >> Interledger RFCs going forward (this is something of a hybrid between the >> IETF and W3C processes and is in keeping with the process defined for us as >> a W3C Community Group): >> >> 1. There are two document types *Working Drafts* and *Candidate >> Specifications*. >> 2. Interledger RFCs are living documents that start as *Working Drafts*. >> 3. Working Drafts have an RFC number AND a draft number starting at 0 and >> increasing by 1 each time the content is changed. Attempting to merge >> changes to a Working Draft without incrementing the draft number should >> result in a build failure of the publishing process. >> 4. When a *Working Draft* is considered stable there is a call for >> review from the community to publish the document as a *Candidate >> Specification* >> 5. Assuming there is consensus to publish, the document becomes a *Candidate >> Specification* and no further substantive changes are allowed under the >> same RFC number. >> >> NOTES: >> >> - Candidate Specifications SHOULD also be published as W3C Community >> Group reports. >> - Candidate Specifications MAY be published as IETF Internet Drafts. >> - A different template should be used for Working Drafts and >> Candidate Specifications to help readers differentiate between them. >> - An explanation of this process should be available on the website >> and linked from the RFCs >> >> >> _______________________________________________ >> Ledger mailing list >> Ledger@ietf.org >> https://www.ietf.org/mailman/listinfo/ledger >> > -- > > Evan Schwartz > Software Engineer > Managing Director of Ripple Luxembourg > --94eb2c061ec02e2aba05527a7987 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 21 June 2017 at 15:54, Evan Schwartz <evan@ripple.com> wrote:
Just to clarify= :


No, same place but= they'd render on the website with a different template (similar to W3C= specs).
Once an RFC becomes a Candidate Spec attempting to m= erge changes will result in test errors so unless a maintainer overrides th= ey should never change.
  • If I have a new Interledger-related idea, would= I just submit a PR to the RFCs repo and claim the next available number? O= r should I submit a PR with no number and have a maintainer assign the numb= er (got that idea from Yarnjs).

Good question. I like that suggestion. Will docum= ent i that way. To submit a draft you submit a PR with the draft. If a main= tainer accepts it they'll add a commit to the PR renaming it to claim a= n RFC number.
=C2=A0
  • Is "version 1" of ILQP, for ex= ample, always going to "live" in the same numbered RFC? Would &qu= ot;version 2" then be a different RFC number and minor updates to the = original one just increment the draft number?
That's the idea. Unless we start documenting v2 before v1 is = stable and moved to Candidate Spec.
  • Trickier question: what defines "conse= nsus to publish"? Who are the stakeholders that need to agree?
I'd consider consensus to mean nobo= dy has objected strongly. W3C has a formal process which we can use and tha= t's roughly it. Dimi and I as the chairs are responsible for getting an= d evaluating consensus.

Given the current makeup of the g= roup and level of participation from various people I expect we'd weigh= t the opinion of the maintainers and major contributors highly.
= =C2=A0

On Tue, Jun 20, 2017 at 1= 2:03 PM Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
<= div>
As discussed before we have an issue whereby o= ur Interledger RFCs are regularly changing and it's not possible for so= meone to refer to a static version of the document and be sure that the con= tent won't substantially change the next time they visit the URL.

I had initially proposed that we introduce semantic versionin= g on the RFCs but we decided against this on the basis that we should:
<= br>
a) Differentiate between specs that are incubating (similar to IET= F Internet Drafts) and those that are mature (similar to IETF RFCs)
b) Assign an RFC number to stable specs and a new number to revisions of = that

As such my proposal is that we adopt the following proces= s for the Interledger RFCs going forward (this is something of a hybrid bet= ween the IETF and W3C processes and is in keeping with the process defined = for us as a W3C Community Group):

1. There are two docume= nt types Working Drafts and Candidate Specifications.
2. Interledger RFCs are living documents that start as Working Drafts<= /b>.
3. Working Drafts have an RFC number AND a draft number starting a= t 0 and increasing by 1 each time the content is changed. Attempting to mer= ge changes to a Working Draft without incrementing the draft number should = result in a build failure of the publishing process.
4. When a Workin= g Draft is considered stable there is a call for review from the commun= ity to publish the document as a Candidate Specification
5. Assuming there is consensus to publish, the document becomes a Can= didate Specification and no further substantive changes are allowed und= er the same RFC number.

NOTES:
  • Cand= idate Specifications SHOULD also be published as W3C Community Group report= s.
  • Candidate Specifications MAY be published as IETF Internet Draft= s.
  • A different template should be used for Working Drafts and Candi= date Specifications to help readers differentiate between them.
  • An = explanation of this process should be available on the website and linked f= rom the RFCs

_______________________________________________
Ledger mailing list
Ledger@ietf.org https://www.ietf.org/mailman/listinfo/ledger
--

Evan Schwar= tz

Software Eng= ineer
Managing Director of Ripple Luxembourg
<= /div>

--94eb2c061ec02e2aba05527a7987-- From nobody Thu Jun 22 05:26:58 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9EC1287A0 for ; Thu, 22 Jun 2017 05:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ripple.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 AgnNV7V6gEGq for ; Thu, 22 Jun 2017 05:26:54 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 008DC127077 for ; Thu, 22 Jun 2017 05:26:53 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id k67so21234391wrc.2 for ; Thu, 22 Jun 2017 05:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ripple.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=ky70S3BLxlWIVA5Rz/yy8/yIZO1T/gs1fBufwVa0VqI=; b=OnhUYZZ6Putnzk+ZINyLYeFy+Uqh6UfqDeTOITaBnQBfZjbMKpnoTu31o4mgc8gTC+ +b7qlM03444gYFA7s3vZVpi0O2ZqpHqJaXaDxtrYwxazeHpSq8vLSZtdJMEDr1My3E5z gm5J+beT9B0OanlGGUNjS9EwAq++0CH6pl9rw= 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=ky70S3BLxlWIVA5Rz/yy8/yIZO1T/gs1fBufwVa0VqI=; b=DauInZMTnf9UA1pdSLgNIkX9YOb0tq1gpFqKPPHch1Q3awN6BgcZekUDTSyt/TC1S5 QcAfmLR4uj+bN+CD+JhaEvD7Cic/OdPJr0j46pCek0lA+j42z+OqpwyR1KDOO47uGMaG WW+f4uMScNnb4+LtX85tKrBFDqn4VRX6R3WYUYV4kRX7bt2aSGe17lf+IAR4TiEctNjB vwfbyUXmLLdM0OtCg0vX72+Nk0QMu/ghBTH6ChkWBVX7+Is961QgRBk2DmXs8B1IJyTu EI9zywI9qPN1hKk/bTRft3QusdyviMywDRhsm+eIZ1OIplHazadWhqRycoSat7LkrE1x /upQ== X-Gm-Message-State: AKS2vOykJtDZrgulYcxsm9fto6UkI6/YCdCPUZQmRNuchXjJ3qNykoBK KtcrtETgN0vfY11V+8yWKaKU9IYDA4/g X-Received: by 10.28.22.4 with SMTP id 4mr1624385wmw.68.1498134412220; Thu, 22 Jun 2017 05:26:52 -0700 (PDT) MIME-Version: 1.0 From: Evan Schwartz Date: Thu, 22 Jun 2017 12:26:41 +0000 Message-ID: To: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/mixed; boundary="001a1147028477b65205528b99be" Archived-At: Subject: [Ledger] Forming a Routing Working Group X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 12:26:57 -0000 --001a1147028477b65205528b99be Content-Type: multipart/alternative; boundary="001a1147028477b64c05528b99bc" --001a1147028477b64c05528b99bc Content-Type: text/plain; charset="UTF-8" There are a number of people who have expressed particular interest in Interledger routing. I'd like to propose creating a working group focused on this topic. The structure, goals, outputs etc are TBD but I could imagine a group like this having calls on a regular basis to discuss ongoing research on routing and generally working to figure out how the next version(s) of Interledger routing should work. If you are interested in this topic, please join the *first call at 3pm UTC on July 5th*. Details for joining the call below. If you have ideas for discussion topics or other suggestions, please respond to this thread with them! *Interledger Routing Working Group Call* For more info and to join the mailing lists visit: https://interledger.org/community To join or start the meeting, go to: https://bluejeans.com/795795755 (Also works on iPhone or Android phone) To connect directly from a room system? 1) Dial: 199.48.152.152 or bjn.vc 2) Enter Meeting ID: 795795755 -or- use the pairing code Dial-in numbers: http://bluejeans.com/numbers (use Meeting ID: 795795755) -- Evan Schwartz Software Engineer Managing Director of Ripple Luxembourg --001a1147028477b64c05528b99bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are a number of people who have expressed particular= interest in Interledger routing. I'd like to propose creating a workin= g group focused on this topic.

The structure, goals, out= puts etc are TBD but I could imagine a group like this having calls on a re= gular basis to discuss ongoing research on routing and generally working to= figure out how the next version(s) of Interledger routing should work.

If you are interested in this topic, please join the = first call at 3pm UTC on July 5th. Details for joining the call belo= w.

If you have ideas for discussion topics or othe= r suggestions, please respond to this thread with them!

= Interledger Routing Working Group Call

For = more info and to join the mailing lists visit: https://interledger.org/community

To join or start the meeting, go to:
(Also w= orks on iPhone or Android phone)

To connect direct= ly from a room system?
1) Dial: 199.48.152.152 or bjn.vc
2) Enter Meeting ID: 795795755 -or- use the= pairing code

Dial-in numbers: http://bluejeans.com/numbers (use Meeting ID: 795= 795755)

--

= Evan Schwartz

Software= Engineer
Managing Director of Ripple Luxembourg<= /span>
--001a1147028477b64c05528b99bc-- --001a1147028477b65205528b99be Content-Type: text/calendar; charset="US-ASCII"; name="interledger-routing-working-group.ics" Content-Disposition: attachment; filename="interledger-routing-working-group.ics" Content-Transfer-Encoding: base64 Content-ID: <15ccfbb3bf391733b3f1> X-Attachment-Id: 15ccfbb3bf391733b3f1 QkVHSU46VkNBTEVOREFSDQpWRVJTSU9OOjIuMA0KQ0FMU0NBTEU6R1JFR09SSUFODQpNRVRIT0Q6 UFVCTElTSA0KQkVHSU46VkVWRU5UClVJRDpyb3V0aW5nQGludGVybGVkZ2VyLm9yZw0KRFRTVEFS VDoyMDE3MDcwNVQxNTAwMDBaDQpEVEVORDoyMDE3MDcwNVQxNjAwMDBaDQpSUlVMRTpGUkVRPVdF RUtMWTtJTlRFUlZBTD0yO0JZREFZPVdFDQpEVFNUQU1QOjIwMTcwNjIyVDE2MDI0OFoNCkNSRUFU RUQ6MjAxNzA2MjJUMTAyOTE2Wg0KREVTQ1JJUFRJT046VGhpcyBpcyB0aGUgYmktd2Vla2x5IGNh bGwgb2YgdGhlIEludGVybGVkZ2VyIFJvdXRpbmcgV29ya2luZyBHcm91cC5cblxuRm9yIA0KIG1v cmUgaW5mbyBhbmQgdG8gam9pbiB0aGUgbWFpbGluZyBsaXN0cyB2aXNpdDogaHR0cHM6Ly9pbnRl cmxlZGdlci5vcmcvY29tbQ0KIHVuaXR5XG5cblRvIGpvaW4gb3Igc3RhcnQgdGhlIG1lZXRpbmdc LCBnbyB0bzpcbmh0dHBzOi8vYmx1ZWplYW5zLmNvbS83OTU3OQ0KIDU3NTVcbihBbHNvIHdvcmtz IG9uIGlQaG9uZSBvciBBbmRyb2lkIHBob25lKVxuXG5UbyBjb25uZWN0IGRpcmVjdGx5IGZybw0K IG0gYSByb29tIHN5c3RlbT9cbjEpIERpYWw6IDE5OS40OC4xNTIuMTUyIG9yIGJqbi52Y1xuMikg RW50ZXIgTWVldGluZyBJRDogNw0KIDk1Nzk1NzU1IC1vci0gdXNlIHRoZSBwYWlyaW5nIGNvZGVc blxuRGlhbC1pbiBudW1iZXJzOiBodHRwOi8vYmx1ZWplYW5zLmNvbQ0KIC9udW1iZXJzICh1c2Ug TWVldGluZyBJRDogNzk1Nzk1NzU1KQpMT0NBVElPTjpodHRwczovL2JsdWVqZWFucy5jb20vNzk1 Nzk1NzU1DQpVUkw6aHR0cHM6Ly9ibHVlamVhbnMuY29tLzc5NTc5NTc1NQ0KU0VRVUVOQ0U6MA0K U1RBVFVTOkNPTkZJUk1FRA0KU1VNTUFSWTpJbnRlcmxlZGdlciBSb3V0aW5nIFdvcmtpbmcgR3Jv dXAgQmktV2Vla2x5IENhbGwNClRSQU5TUDpPUEFRVUUNCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5E QVIK --001a1147028477b65205528b99be-- From nobody Thu Jun 22 16:23:19 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F8D129BA0 for ; Thu, 22 Jun 2017 16:23:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=ryanfugger-com.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 fWuBuaelxAy8 for ; Thu, 22 Jun 2017 16:23:15 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 05E2A127867 for ; Thu, 22 Jun 2017 16:23:14 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id v20so23677672qtg.1 for ; Thu, 22 Jun 2017 16:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ryanfugger-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PDlN8HyBf7oyHWctBb69DQCdcBPwFe5LPQ+lzZQbi9U=; b=ZStC8L9MSAp2SKbbWHRetsVUw3aGhnkZ2coq5AhuloMddGMqCjSN0Dx7MTLi810Lzv EuURsr/wPL2VpduGM96FneGxKGZoocCxJR+ubbfjjZz9JLNyScpQ8sSfEA5F+XeHTijo N7K/+Ls3L9Q9V/9WhV0+WEiq4Z/Ygwya85bdApPGtTs+L5YMsrwe29CI1v+CLBIzbkRy vN3ghjFSsyAA0TVbwX18j9vmtImc9oaf2Z7aOE39jBnB6l7r6b5fESq4gP6oWyxUuj6F 5OtbgTX6cOUDpfIuS2Z6xeQTBwww9ZB+FxWqvCy9cLT3+Hx263+/u7g9xFKJZ5TRt3c7 izOA== 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=PDlN8HyBf7oyHWctBb69DQCdcBPwFe5LPQ+lzZQbi9U=; b=FEe65FSfS98w8XztaBqUROusgfyB5kI8SwlkGlO57tM17N/wwsT8beAmAvX0N4UXUz FpB7DhJc9JLiGBBNhDMuNwPo39y1w/g5N3W5E8czyXzkIHSe2UTEaka/CLeaxzFkPstT iBAbcnzYJuAQoTJHXverFb+QxZdnbgSUtRhiYGEA04h0Z1sfiKdPvEfvT1aNHeUVcXR2 4cCxQ+lvpTEepC2UP3EFjc6IMpK/iVxeIN8jR9ch+Ya+gGGSlBKkK53PpcnvPMfckLIm vWZeq+8ZcH2YT5AZy2nzkaFxJt4vaGMGAI6eYMO7RtZATKmxOV0SrbWNWFpfLh5l6K2n EOtw== X-Gm-Message-State: AKS2vOyfz+GV8SZpdG1J5b18q0qUxM4zXF+FmYO/VmIIcFCoaSvQC8Gr N9nNn6IOy6hzDCm7WJFDalU3s+MT0tDE X-Received: by 10.200.46.25 with SMTP id r25mr2943708qta.209.1498173792642; Thu, 22 Jun 2017 16:23:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.151.10 with HTTP; Thu, 22 Jun 2017 16:22:52 -0700 (PDT) In-Reply-To: References: From: Ryan Fugger Date: Thu, 22 Jun 2017 16:22:52 -0700 Message-ID: To: Evan Schwartz Cc: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a1147ea5eb8ffb1055294c409" Archived-At: Subject: Re: [Ledger] Forming a Routing Working Group X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 23:23:17 -0000 --001a1147ea5eb8ffb1055294c409 Content-Type: text/plain; charset="UTF-8" This is a great idea Evan. I am very interested in routing. I don't manage calls well, but I would appreciate being able to observe and hopefully participate a bit over email. Please let us know if/when any new mailing list gets set up for this. Thanks! On Thu, Jun 22, 2017 at 5:26 AM, Evan Schwartz wrote: > There are a number of people who have expressed particular interest in > Interledger routing. I'd like to propose creating a working group focused > on this topic. > > The structure, goals, outputs etc are TBD but I could imagine a group like > this having calls on a regular basis to discuss ongoing research on routing > and generally working to figure out how the next version(s) of Interledger > routing should work. > > If you are interested in this topic, please join the *first call at 3pm > UTC on July 5th*. Details for joining the call below. > > If you have ideas for discussion topics or other suggestions, please > respond to this thread with them! > > *Interledger Routing Working Group Call* > > For more info and to join the mailing lists visit: > https://interledger.org/community > > To join or start the meeting, go to: > https://bluejeans.com/795795755 > (Also works on iPhone or Android phone) > > To connect directly from a room system? > 1) Dial: 199.48.152.152 or bjn.vc > 2) Enter Meeting ID: 795795755 -or- use the pairing code > > Dial-in numbers: http://bluejeans.com/numbers (use Meeting ID: 795795755) > > -- > > Evan Schwartz > Software Engineer > Managing Director of Ripple Luxembourg > > _______________________________________________ > Ledger mailing list > Ledger@ietf.org > https://www.ietf.org/mailman/listinfo/ledger > > --001a1147ea5eb8ffb1055294c409 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is a great idea Evan.=C2=A0 I am very interested in r= outing.=C2=A0 I don't manage calls well, but I would appreciate being a= ble to observe and hopefully participate a bit over email.=C2=A0 Please let= us know if/when any new mailing list gets set up for this.=C2=A0 Thanks!

On Thu, J= un 22, 2017 at 5:26 AM, Evan Schwartz <evan@ripple.com> wrote:=
There are a number of p= eople who have expressed particular interest in Interledger routing. I'= d like to propose creating a working group focused on this topic.

<= /div>
The structure, goals, outputs etc are TBD but I could imagine a g= roup like this having calls on a regular basis to discuss ongoing research = on routing and generally working to figure out how the next version(s) of I= nterledger routing should work.

If you are interes= ted in this topic, please join the first call at 3pm UTC on July 5th= . Details for joining the call below.

If you have = ideas for discussion topics or other suggestions, please respond to this th= read with them!

Interledger Routing Working Group Cal= l

For more info and to join the mailing lists = visit: http= s://interledger.org/community

To join or = start the meeting, go to:
(= Also works on iPhone or Android phone)

To connect = directly from a room system?
1) Dial: 199.48.152.152 or bjn.vc
2) Enter Meeting = ID: 795795755 -or- use the pairing code

Dial-in nu= mbers: http://bl= uejeans.com/numbers (use Meeting ID: 795795755)

--

Evan Schwartz

Software Engineer
Managing Direc= tor of Ripple Luxembourg
<= /div>

_______________________________________________
Ledger mailing list
Ledger@ietf.org
https://www.ietf.org/mailman/listinfo/ledger

--001a1147ea5eb8ffb1055294c409-- From nobody Fri Jun 30 12:10:44 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0F61275AB for ; Fri, 30 Jun 2017 12:10:42 -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=chain-com.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 CE5nyeenxtMR for ; Fri, 30 Jun 2017 12:10:41 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 4A572126B7E for ; Fri, 30 Jun 2017 12:10:41 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id z78so33774556lff.0 for ; Fri, 30 Jun 2017 12:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chain-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jwTcJp6xzz/kW39sO88O12i/8oyE1ivsifTrAg3xlNo=; b=lr1Q9vlZmqfUq10v69bSB3LPo9+LDvvgnvR3Z6EIsyJqeXpEYdfw4IDyDFCtiiGRwf joHypZB0ptEHsMqk7iLGpKE4HPchoLL7rhSXWXmfZerBud6naVtI7HhbCl9w0rO9xCQn uCO00XG9i29aEFM5WS35Lzeu1nuMZGiadhmyPu/KwJDfTsBtbeOyuxYSHU4dJaQU69xt BDWWNhRlyHN4vGhqa2fHTADTDJnYxfu1BuV+Psd4j7gsOzaYNFSokSUq+t2C63eCxH87 lr1xwY4YFXMbH/yuNUhKr1sJhVhbvYjPffYX+1JBQjF3235Nx4wntxhHLrjzdTssV6WF B4zA== 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=jwTcJp6xzz/kW39sO88O12i/8oyE1ivsifTrAg3xlNo=; b=EvffAnJmxOGhhhSAS1ssui7/DatdJq8g+m5NMIam0wRMI/oy9k87iXEUSxXYpKkmK2 Uf37Ck9gYaUiVULwTC3k3UoXhHvqnfy9aFKOBcrZWTnTlV2My59bmRhwBVpxsCTzGwus Af4z4g2jo0WE3icVm1Yh2W6RN6tbM+Y3y/+VLWQ3f1mUSGcGNtLnzZp1ZheLSDJZ9WRQ +2fnwmlPq122Ffiedp/pe2zdv6mQEtTmJKAWBP7bQoZZNB1wfh5r+TlMKvtypWVkgG08 adL+GdbiLS1WR9dMg8byQeGr3AqECyTMMH5u7ifAq9giVWVpr9peP1FTm4KspRXNcPwb uWig== X-Gm-Message-State: AKS2vOzTafPXH0LCEq+1iBIZjopS2Q6ueCHFs+zkmTNiMvO7zANCE0fb DYlb4gn/7VRNro4yNcKa1gPhO3A6XqwS X-Received: by 10.46.69.85 with SMTP id s82mr6825413lja.64.1498849839568; Fri, 30 Jun 2017 12:10:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.19.27 with HTTP; Fri, 30 Jun 2017 12:10:38 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Fri, 30 Jun 2017 12:10:38 -0700 Message-ID: To: Ryan Fugger Cc: Evan Schwartz , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a114b0fce4283720553322c75" Archived-At: Subject: Re: [Ledger] Forming a Routing Working Group X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 19:10:42 -0000 --001a114b0fce4283720553322c75 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 22, 2017 at 4:22 PM, Ryan Fugger wrote: > This is a great idea Evan. I am very interested in routing. I don't > manage calls well, but I would appreciate being able to observe and > hopefully participate a bit over email. Please let us know if/when any new > mailing list gets set up for this. Thanks! > I'm in a similar boat to Ryan: a big fan of things like BGP and layer 3 routing as well as proprietary payment network routing, but would prefer to participate in something like this a bit more asynchronously as opposed to a call. --001a114b0fce4283720553322c75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 22, 2017 at 4:22 PM, Ryan Fugger <arv@ryanfugger.com> wrote:
This is a grea= t idea Evan.=C2=A0 I am very interested in routing.=C2=A0 I don't manag= e calls well, but I would appreciate being able to observe and hopefully pa= rticipate a bit over email.=C2=A0 Please let us know if/when any new mailin= g list gets set up for this.=C2=A0 Thanks!

I'm in a similar boat to Ryan: a big fan of things like BGP and l= ayer 3 routing as well as proprietary payment network routing, but would pr= efer to participate in something like this a bit more asynchronously as opp= osed to a call.=C2=A0
--001a114b0fce4283720553322c75-- From nobody Fri Jun 30 12:13:35 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FED3127867 for ; Fri, 30 Jun 2017 12:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.286 X-Spam-Level: X-Spam-Status: No, score=-1.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ripple.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 shEWN8sCbF5t for ; Fri, 30 Jun 2017 12:13:32 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 C8D16126B7E for ; Fri, 30 Jun 2017 12:13:31 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id f67so1639545wmh.1 for ; Fri, 30 Jun 2017 12:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ripple.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yG03N4HiQTw+WYJf8MV3cKQP7BoqcJjhntQh12gip60=; b=gV+haeaA5DPbeMHEjWpLV5sJX6IioqERr7kyZFn8b7fqT6N2HzdtZVrDMnuwS03SQR WnxIDuC8Hg2KvcOdiZiKT43VhzsW0JmeQSZ0cTUn3sKriMo0j0Qg9XslkAxa01N4R2zB cpk0LklkVl5oDP4+KPjxcsZDYgGuVfOHww09E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yG03N4HiQTw+WYJf8MV3cKQP7BoqcJjhntQh12gip60=; b=X7k59jN5fzQQFU8wWzO/BN1ieHa1pa60JghnFhz29BTE+C7t2CajsEhCKdGO5OcrpU ob54b2DdqqMf9pQ5aFDJzXnyxQU7ieRS/AS8bXiuQcyXVuXHJHt++iZNfkY5uWEWx20i Ou1xqrPRg/uosoOwfYBKLJDjCrkxtZVT7uhjesGxfa4tU2jKk642+f2cWNqbejuAZ2W8 +CAjDoC7y8UBt3OGwtGDHMiFoj4CDUqV0AkV+II2u2ix5daHrj8DPkVFc1krGKbK/+98 1teUKloiay65MqCRZNLPSC2hl5nNzEb/OiHSAQE9Kv2LTxl0IyxkM4cHWHg37x6UQYW9 69jw== X-Gm-Message-State: AKS2vOxRRrz69Pxkx/Rk61pyvSEBKTeK6hZkhouOhnjM6zX/5pQuLATw Z16E3CDWJ/uclKdmBg2RYo3Oiu948dYxZwo= X-Received: by 10.28.22.4 with SMTP id 4mr6777316wmw.68.1498850010337; Fri, 30 Jun 2017 12:13:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Evan Schwartz Date: Fri, 30 Jun 2017 19:13:19 +0000 Message-ID: To: Tony Arcieri , Ryan Fugger Cc: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a114702847038a8055332368d" Archived-At: Subject: Re: [Ledger] Forming a Routing Working Group X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 19:13:34 -0000 --001a114702847038a8055332368d Content-Type: text/plain; charset="UTF-8" Sounds good. I would propose that this type of group should start and work on a shared set of docs that describes options, ongoing research, etc so that others can participate and follow along. On Fri, Jun 30, 2017 at 9:10 PM Tony Arcieri wrote: > On Thu, Jun 22, 2017 at 4:22 PM, Ryan Fugger wrote: > >> This is a great idea Evan. I am very interested in routing. I don't >> manage calls well, but I would appreciate being able to observe and >> hopefully participate a bit over email. Please let us know if/when any new >> mailing list gets set up for this. Thanks! >> > > I'm in a similar boat to Ryan: a big fan of things like BGP and layer 3 > routing as well as proprietary payment network routing, but would prefer to > participate in something like this a bit more asynchronously as opposed to > a call. > -- Evan Schwartz Software Engineer Managing Director of Ripple Luxembourg --001a114702847038a8055332368d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sounds good. I would propose that this type of group shoul= d start and work on a shared set of docs that describes options, ongoing re= search, etc so that others can participate and follow along.

On Fri, Jun 30, 2017 at 9:10 PM Tony = Arcieri <tony@chain.= com> wrote:
On Thu, Jun 22, 2017= at 4:22 PM, Ryan Fugger <arv@ryanfugger.com> wrote:
This is a great idea Evan.=C2= =A0 I am very interested in routing.=C2=A0 I don't manage calls well, b= ut I would appreciate being able to observe and hopefully participate a bit= over email.=C2=A0 Please let us know if/when any new mailing list gets set= up for this.=C2=A0 Thanks!

=
I'm in a similar boat to Ryan: a big fan of things like BGP and la= yer 3 routing as well as proprietary payment network routing, but would pre= fer to participate in something like this a bit more asynchronously as oppo= sed to a call.=C2=A0
--

Evan = Schwartz

Software= Engineer
Managing Director of Ripple Luxembourg<= /span>
--001a114702847038a8055332368d--