From nobody Fri Aug 21 16:35:34 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD123A1455 for ; Fri, 21 Aug 2020 16:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=apple.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 CHLgT7SIq70q for ; Fri, 21 Aug 2020 16:35:30 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 7D8BF3A1454 for ; Fri, 21 Aug 2020 16:35:30 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 07LNXBQ8062066 for ; Fri, 21 Aug 2020 16:35:29 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : content-transfer-encoding : mime-version : subject : message-id : date : to; s=20180706; bh=Kscf6U0rki79MWWkQUsxAxL4VirFFmdxQkOvg+gpBK8=; b=dQUvzhY9hbGEyGgWlW32LyGnRaAt/2RpIzTXaLsZYXMUlUpbg8JMlnqh61qKySls9GDB jTKnHYxPQLnPQjoW2o/S8bft5D7ABqwo6AEkgXqlpyIEjA/CC4HaQg7TKZhxqjLDHZmC b2Oz1XRreHW0pyehuZK6GJeQmrC4pbJYaAkrxvFfiKZ42Xn23GkHtGQ7VUEyCtcTUF/h dPvZ90D0b7M2k1X5zAZLMlh8iIoOdTqW2uTc8gUgMwa5/+gAUoF12y2/jDEwt156Lnal ibLSlJ62s8TSfiPb8AguoVFBMrxVX+07KHXizM/sMbe/iKOXYHZj5/ZicMvr/KXjQLtZ Ew== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 32xepx0m0y-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 21 Aug 2020 16:35:29 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QFF00B3ETJ21Z30@rn-mailsvcp-mta-lapp04.rno.apple.com> for edm@iab.org; Fri, 21 Aug 2020 16:35:26 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QFF00200TGLX600@rn-mailsvcp-mmp-lapp02.rno.apple.com> for edm@iab.org; Fri, 21 Aug 2020 16:35:26 -0700 (PDT) X-Va-A: X-Va-T-CD: 1af8597529a643bc4f908cf463616f6c X-Va-E-CD: 653d3d87d8989147191a78432f607fa5 X-Va-R-CD: dc2ec60a8edf52a4f416443a3510df95 X-Va-CD: 0 X-Va-ID: c2970573-c06f-4f18-981d-e474e30324c6 X-V-A: X-V-T-CD: 1af8597529a643bc4f908cf463616f6c X-V-E-CD: 653d3d87d8989147191a78432f607fa5 X-V-R-CD: dc2ec60a8edf52a4f416443a3510df95 X-V-CD: 0 X-V-ID: 04169d75-29d7-41ad-b099-98ffc20442c6 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-21_10:2020-08-21, 2020-08-21 signatures=0 Received: from [17.234.17.84] (unknown [17.234.17.84]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QFF00CKETJ19I00@rn-mailsvcp-mmp-lapp02.rno.apple.com> for edm@iab.org; Fri, 21 Aug 2020 16:35:26 -0700 (PDT) From: Tommy Pauly Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Message-id: Date: Fri, 21 Aug 2020 16:35:25 -0700 To: edm@iab.org X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-21_10:2020-08-21, 2020-08-21 signatures=0 Archived-At: Subject: [Edm] Welcome to EDM! X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 23:35:33 -0000 Hello all, Welcome to the Evolvability, Deployability, and Maintainability IAB = program.=20 First off, here are a few administrative links: Datatracker: https://datatracker.ietf.org/group/edm/about/ Program summary: = https://www.iab.org/activities/programs/evolvability-deployability-maintai= nability-edm-program/ GitHub: https://github.com/intarchboard/edm Considering the current circumstances, I expect we=E2=80=99ll operate in = virtual discussions for a while. We=E2=80=99ll see what works best, but = I=E2=80=99d like to start with the mailing list and the GitHub issues = list being our primary resources for discussion. We=E2=80=99ll also set = up some WebEx calls to dive into specific topics. To start off our discussions, I=E2=80=99ve written up a few GitHub = issues that raise questions for this group. Please feel free to reply in = GitHub or send email to edm@iab.org. =E2=80=A2 Approaches to tracking implementation interop and = deployment: https://github.com/intarchboard/edm/issues/1 =E2=80=A2 What extension mechanisms are successful? = https://github.com/intarchboard/edm/issues/3 =E2=80=A2 Moving Use-it-or-lose-it forward? = https://github.com/intarchboard/edm/issues/2 =E2=80=A2 How should we coordinate greasing experiments? = https://github.com/intarchboard/edm/issues/4 I also want to coordinate an initial WebEx the week of August 31 - = September 4. The time slots here are chosen to be in the window that = works across many time zones. Please fill out the Doodle if you=E2=80=99d = like to participate! https://doodle.com/poll/t2wgvvtspbafzz8n Best, Tommy From nobody Tue Aug 25 14:47:50 2020 Return-Path: X-Original-To: edm@iab.org Delivered-To: edm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3733A0C26; Tue, 25 Aug 2020 14:47:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IAB Executive Administrative Manager To: Cc: edm@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159839206489.26388.9889652884666821@ietfa.amsl.com> Date: Tue, 25 Aug 2020 14:47:44 -0700 Archived-At: Subject: [Edm] New IAB Program: Evolvability, Deployability, & Maintainability (EDM) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 21:47:45 -0000 A new IAB Program has been formed on Evolvability, Deployability, & Maintainability (EDM). For additional information, please contact the IAB or the Program Lead. Evolvability, Deployability, & Maintainability (EDM) Program ----------------------------------------------------------------------- IAB Lead: Tommy Pauly Mailing list: Address: edm@iab.org To subscribe: https://www.iab.org/mailman/listinfo/edm Archive: https://mailarchive.ietf.org/arch/browse/edm/ Program Page: https://www.iab.org/activities/programs/evolvability-deployability-maintainability-edm-program/ Program Description: This program will focus on how to practically encourage best practices within the IETF to ensure that the IETF’s standards process considers protocol evolution, deployability, and long-term maintainability. This group will work on documents that catalog and analyze successful strategies for protocol evolution, deployment, and maintenance, such as updating and extending RFC 6709. Moreover, it will focus on ways to help promote and increase awareness of these strategies within the IETF via program meetings, workshops, and helping organize efforts within working groups and various IETF teams. The program will include members of the IESG and the tools team to help implement these strategies. The topics this group will consider include: * Evolvability: Encourage protocols to design for extensibility and greasing, and promote the use of extension points to prevent ossification. Make it easy for people, especially those who aren’t steeped in IETF process, to know which extension points are the right ones to use for a given protocol (and which ones should be considered more stable/ossified), and make sure there aren’t high allocation barriers to use those extension points. * Deployability: Focus on how we make “running code” something that is better integrated into the working group process. Look at methods to catalog implementations, tools for tracking interoperability testing on different protocol versions, or repositories of which versions of protocols are implemented and used on the Internet. Discuss how deployments can advertise experiments they are running. * Maintainability: Many working groups have expressed a desire to have ways for the community of protocol designers and implementers to keep track of the current state of affairs in deployment patterns, known errata/bugs, or best practices. Help promote consistent ways to host non-RFC working group output, like FAQs, wikis, and discussion venues. Consider how this community involvement can continue and involve the right experts, even after a working group closes. The program will: * Engage with the IETF community and implementers outside of the IETF to identity successes and problem areas, and collect ideas for improvements. * Work with the IESG and directorates to determine how best practices for evolvability can best be applied during IESG review and IETF last call. * Work with the IESG and tools team on ways to connect implementers and communities that develop and maintain protocols, both while a working group is active, and after a working group has concluded its charter. From nobody Tue Aug 25 14:53:52 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA60C3A0C27; Tue, 25 Aug 2020 14:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZT_8LfSSiZe7; Tue, 25 Aug 2020 14:53:46 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 6CC2A3A0C33; Tue, 25 Aug 2020 14:53:46 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id d19so7749589pgl.10; Tue, 25 Aug 2020 14:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+4ivqI2lqd/3YU4etj7lrvtxytVtpsWr1WMmFxvuVDc=; b=VSgb5lySf0fYqERenbe9I+S7pvaVdLgqJnBjfZtQmNJiEsxQKZaNhvrl2b3LD3SvkA K4igN1hXEc+XhxMhQdLfnC78yQZmxQQKuQm2ZE73a+nXKdfGLbkdvIEWymmwQpTH030U +CuXo/EPsMG9zcGcp3yj7UG7J8m2q38gYvMwk8Gy9YXXNHlhn7QwmtPilrsZa4Q/lWZ/ 7HNSbSdNTngmh+PmtJnyNAXDR7xM9pvJfBbqTVFgfPg3WndQLemlRTv3JeUSdIZC6Wdq z5eBiy5Nre/UHAvjY3z53UYEhpeY+XfxSDZXHtkfnl3dFESO/0HG1iiLfLr9tq8PP7y5 ddwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=+4ivqI2lqd/3YU4etj7lrvtxytVtpsWr1WMmFxvuVDc=; b=lCy5dH19ryZovpKiCJj+Xoyl1GIJBPZzGJLm5W4+N3JXoF44HSKxglYO+Ti4AkehHm w8C2mDLqveso0crvueywbpK//XGHMN9RFUu1mSuN55xa9NqfX3e4Gx+mI6a+WxbagL2h em3q0B9G8W7Qs/mT0+yP6QZNI6HQtkt4jnAq4VSA1JPLguvI0dGx8cs4VEKdTBF0DyXg 9d1aMpfXA0PTibZ8bPS3r3ZBF3mqfAaSbMtcEaxDqce9O2uflM3X6ALIcT0aHCnZpYaE m2Q9k90gNjEzf8c/fOa0OmnPuAcY+PQrnAV2OqmN8Rh9zSd3aJ8n0tjHHl3cMufvLLuD bqzg== X-Gm-Message-State: AOAM530zjQog0UYIfKySPVkb64yu77ZRT74sIOXP+hpLXuQ0B//0kPrN kX5AZukLmM4YllMVljKe7+ID2yoiHeM= X-Google-Smtp-Source: ABdhPJw7xgzaIjFS3vEXoglMczL0CXQXURdMf+ELFIYnG623SlqjZD+JRuKfVcNm8Aik6L6Ak0PmFQ== X-Received: by 2002:a63:f70e:: with SMTP id x14mr6250903pgh.407.1598392425498; Tue, 25 Aug 2020 14:53:45 -0700 (PDT) Received: from [10.95.82.114] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id j13sm201724pfn.166.2020.08.25.14.53.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Aug 2020 14:53:44 -0700 (PDT) Sender: Tony Li Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: tony.li@tony.li In-Reply-To: <159839206489.26388.9889652884666821@ietfa.amsl.com> Date: Tue, 25 Aug 2020 14:53:41 -0700 Cc: architecture-discuss@ietf.org, edm@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <1D675EBC-4AC7-4E01-87CC-4DF4F0D9DD3C@tony.li> References: <159839206489.26388.9889652884666821@ietfa.amsl.com> To: IAB Executive Administrative Manager X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Edm] [arch-d] New IAB Program: Evolvability, Deployability, & Maintainability (EDM) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 21:53:48 -0000 Seems like point 1 should be ignoring pointless IAB programs. There=E2=80=99s work to be done. This isn=E2=80=99t it. Tony > On Aug 25, 2020, at 2:47 PM, IAB Executive Administrative Manager = wrote: >=20 > A new IAB Program has been formed on Evolvability, Deployability, &=20 > Maintainability (EDM). For additional information, please contact the=20= > IAB or the Program Lead. >=20 > Evolvability, Deployability, & Maintainability (EDM) Program > = ----------------------------------------------------------------------- >=20 > IAB Lead: > Tommy Pauly >=20 > Mailing list: > Address: edm@iab.org > To subscribe: https://www.iab.org/mailman/listinfo/edm > Archive: https://mailarchive.ietf.org/arch/browse/edm/ >=20 >=20 > Program Page: = https://www.iab.org/activities/programs/evolvability-deployability-maintai= nability-edm-program/ >=20 > Program Description: >=20 > This program will focus on how to practically encourage best practices=20= > within the IETF to ensure that the IETF=E2=80=99s standards process = considers=20 > protocol evolution, deployability, and long-term maintainability. This=20= > group will work on documents that catalog and analyze successful=20 > strategies for protocol evolution, deployment, and maintenance, such = as=20 > updating and extending RFC 6709. Moreover, it will focus on ways to = help=20 > promote and increase awareness of these strategies within the IETF via=20= > program meetings, workshops, and helping organize efforts within = working=20 > groups and various IETF teams. The program will include members of the=20= > IESG and the tools team to help implement these strategies. >=20 > The topics this group will consider include: >=20 > * Evolvability: Encourage protocols to design for extensibility and=20 > greasing, and promote the use of extension points to prevent=20 > ossification. Make it easy for people, especially those who aren=E2=80=99= t=20 > steeped in IETF process, to know which extension points are the right=20= > ones to use for a given protocol (and which ones should be considered=20= > more stable/ossified), and make sure there aren=E2=80=99t high = allocation=20 > barriers to use those extension points. >=20 > * Deployability: Focus on how we make =E2=80=9Crunning code=E2=80=9D = something that is=20 > better integrated into the working group process. Look at methods to=20= > catalog implementations, tools for tracking interoperability testing=20= > on different protocol versions, or repositories of which versions of=20= > protocols are implemented and used on the Internet. Discuss how=20 > deployments can advertise experiments they are running. >=20 > * Maintainability: Many working groups have expressed a desire to have=20= > ways for the community of protocol designers and implementers to keep=20= > track of the current state of affairs in deployment patterns, known=20= > errata/bugs, or best practices. Help promote consistent ways to host=20= > non-RFC working group output, like FAQs, wikis, and discussion = venues.=20 > Consider how this community involvement can continue and involve the=20= > right experts, even after a working group closes. >=20 > The program will: >=20 > * Engage with the IETF community and implementers outside of the IETF = to=20 > identity successes and problem areas, and collect ideas for=20 > improvements. > * Work with the IESG and directorates to determine how best practices=20= > for evolvability can best be applied during IESG review and IETF last=20= > call. > * Work with the IESG and tools team on ways to connect implementers = and=20 > communities that develop and maintain protocols, both while a working=20= > group is active, and after a working group has concluded its charter. >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Tue Aug 25 23:11:51 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDB73A0DDA; Tue, 25 Aug 2020 23:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=dy7cUXWT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=stNpIhUo 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 99QzLHjdZ1Ua; Tue, 25 Aug 2020 23:11:41 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45E33A0DDE; Tue, 25 Aug 2020 23:11:41 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id A10CAEB4; Wed, 26 Aug 2020 02:11:40 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 26 Aug 2020 02:11:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=6 3Sx16ye2dasZ4UA2ND2jrB08HHGQSXaivdvvhDWYEk=; b=dy7cUXWTVZztWDhqb vWiC/j44i3WCPKxa4BOUdU004nXuG/Meik8Xbq7vlRILcToxGTl8sb25mj8gyj0S EjTJtf8iAj6A4Y4BC9cCa13EJNJKc9KplwyDZayBiUZYk0J1PxvU4lEiflHNzHAF TQxXtoFSo9yz4hitGdCtMUW3xcp2QWGmcCNIRYV00tpxivKuEaZdM9oEhQNFqa/P r4rVnVyoUSux81VyCwWLspA3gvywKjSVFbipBGZP7EQlzjWYjkhst/dmmV1eNZ9Y wRcEi4uRUxhwqxIoO9q/IAd4WutrSCST1f+v6/Nun0KDKOyqnaxcgHHTOvJQ1NiG J0Mug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=63Sx16ye2dasZ4UA2ND2jrB08HHGQSXaivdvvhDWY Ek=; b=stNpIhUo0M+DHXiFhFutW5/86LeOFRdKO0t7sz18rcbYZFcf05fehYn2G jLOd4wB3Sim843CynlfoBQEyO0oeD3ffycnd8bG5qKR8AbHFatqPxeajLMALBw+/ j7DMjfvBmcJ1jQ4BQzTvA1ThofTbQmRHVQrQKnEHGeHsJSal843akcwcz4LiUqFU hKgkpETsHW8VHdR3Tl3LTsm0c+qU0KixOkjmu9ITIRUpjvx6S4gUCuoUMbhHzKoe T+VEntm6+uIJtxRon5BdIqpQrlCpnsqVO2YLbGAlhnUvnJfUyf8gkJh0Ff905Z/b WLxmpTumsyvmhs+MrRFo/SPlR2xzg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvuddguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrth htvghrnhepudfhtddugeeftdefkeevveeghfevveffteejfeekheetgeelhfdvhfffvdef hffgnecuffhomhgrihhnpehirggsrdhorhhgpdhivghtfhdrohhrghdpmhhnohhtrdhnvg htnecukfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 80900328005D; Wed, 26 Aug 2020 02:11:37 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <1D675EBC-4AC7-4E01-87CC-4DF4F0D9DD3C@tony.li> Date: Wed, 26 Aug 2020 16:11:33 +1000 Cc: IAB Executive Administrative Manager , edm@iab.org, architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6BC67FE7-5517-4733-96F1-A7991ABD9AF7@mnot.net> References: <159839206489.26388.9889652884666821@ietfa.amsl.com> <1D675EBC-4AC7-4E01-87CC-4DF4F0D9DD3C@tony.li> To: tony.li@tony.li X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Edm] [arch-d] New IAB Program: Evolvability, Deployability, & Maintainability (EDM) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 06:11:44 -0000 Tony, Do you have any constructive feedback about the program, or other work = that we should focus on? Just calling it 'pointless' doesn't help. > On 26 Aug 2020, at 7:53 am, tony.li@tony.li wrote: >=20 >=20 > Seems like point 1 should be ignoring pointless IAB programs. >=20 > There=E2=80=99s work to be done. This isn=E2=80=99t it. >=20 > Tony >=20 >=20 >> On Aug 25, 2020, at 2:47 PM, IAB Executive Administrative Manager = wrote: >>=20 >> A new IAB Program has been formed on Evolvability, Deployability, &=20= >> Maintainability (EDM). For additional information, please contact the=20= >> IAB or the Program Lead. >>=20 >> Evolvability, Deployability, & Maintainability (EDM) Program >> = ----------------------------------------------------------------------- >>=20 >> IAB Lead: >> Tommy Pauly >>=20 >> Mailing list: >> Address: edm@iab.org >> To subscribe: https://www.iab.org/mailman/listinfo/edm >> Archive: https://mailarchive.ietf.org/arch/browse/edm/ >>=20 >>=20 >> Program Page: = https://www.iab.org/activities/programs/evolvability-deployability-maintai= nability-edm-program/ >>=20 >> Program Description: >>=20 >> This program will focus on how to practically encourage best = practices=20 >> within the IETF to ensure that the IETF=E2=80=99s standards process = considers=20 >> protocol evolution, deployability, and long-term maintainability. = This=20 >> group will work on documents that catalog and analyze successful=20 >> strategies for protocol evolution, deployment, and maintenance, such = as=20 >> updating and extending RFC 6709. Moreover, it will focus on ways to = help=20 >> promote and increase awareness of these strategies within the IETF = via=20 >> program meetings, workshops, and helping organize efforts within = working=20 >> groups and various IETF teams. The program will include members of = the=20 >> IESG and the tools team to help implement these strategies. >>=20 >> The topics this group will consider include: >>=20 >> * Evolvability: Encourage protocols to design for extensibility and=20= >> greasing, and promote the use of extension points to prevent=20 >> ossification. Make it easy for people, especially those who aren=E2=80=99= t=20 >> steeped in IETF process, to know which extension points are the right=20= >> ones to use for a given protocol (and which ones should be considered=20= >> more stable/ossified), and make sure there aren=E2=80=99t high = allocation=20 >> barriers to use those extension points. >>=20 >> * Deployability: Focus on how we make =E2=80=9Crunning code=E2=80=9D = something that is=20 >> better integrated into the working group process. Look at methods to=20= >> catalog implementations, tools for tracking interoperability testing=20= >> on different protocol versions, or repositories of which versions of=20= >> protocols are implemented and used on the Internet. Discuss how=20 >> deployments can advertise experiments they are running. >>=20 >> * Maintainability: Many working groups have expressed a desire to = have=20 >> ways for the community of protocol designers and implementers to keep=20= >> track of the current state of affairs in deployment patterns, known=20= >> errata/bugs, or best practices. Help promote consistent ways to host=20= >> non-RFC working group output, like FAQs, wikis, and discussion = venues.=20 >> Consider how this community involvement can continue and involve the=20= >> right experts, even after a working group closes. >>=20 >> The program will: >>=20 >> * Engage with the IETF community and implementers outside of the IETF = to=20 >> identity successes and problem areas, and collect ideas for=20 >> improvements. >> * Work with the IESG and directorates to determine how best practices=20= >> for evolvability can best be applied during IESG review and IETF last=20= >> call. >> * Work with the IESG and tools team on ways to connect implementers = and=20 >> communities that develop and maintain protocols, both while a working=20= >> group is active, and after a working group has concluded its charter. >>=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 > --=20 > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm -- Mark Nottingham https://www.mnot.net/ From nobody Wed Aug 26 07:37:20 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158A23A0D4D; Wed, 26 Aug 2020 07:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xUvjbEEdiy3o; Wed, 26 Aug 2020 07:37:14 -0700 (PDT) Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (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 6930C3A1532; Wed, 26 Aug 2020 07:37:14 -0700 (PDT) Received: by mail-pg1-f170.google.com with SMTP id g1so1111066pgm.9; Wed, 26 Aug 2020 07:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8m8QpXN/8Zg1H1piYtMy1KWOWjR9z0Qr+rhxWdpOBVU=; b=madRab/X9fJl0l2b7FAh1B3S0XuIaVUhd04xTZLhlyMMhxcEHRmJLHqMJCzEQyWaPu G2CcrETKzljUH/jkUMRFeLWpLpLeKEvynviCkHHQLgtA0ZfDPXEk2UP1bBeeCh+eOrU0 xT8V4ZgNvQcXJpg2M8a5sa65F9TIDwPmt44g65JUG88aZxWuMvS19ygIHB/BFRCeMrTE VFeA1TUi4HeCJ5ArriHt0Nml0uZ9wfUso7HHtgbjJl2XsHBuL0Lue60TwptOKgIOoMtS p04OLDV/dMQWoqMWtLfnbFg8E0y1rjrk1qa3Gpty+T3XNk1K//kIohT+HyxFAPU9kfSp 2R3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=8m8QpXN/8Zg1H1piYtMy1KWOWjR9z0Qr+rhxWdpOBVU=; b=lSZTdGdRz613iuveOyo8awRb3pgBbJ58sdoKLvcP0lSSe2dXh8uUFVuyEy9Ob6R0PU sDik7GFoyUyT/6UGGDsGqrPMjYHTSemQrZX6Kl2/9xpWf/qOSZMUQeQEz1Um/kGR2AuE /71bnG8NIwdz1bOUjDjLaHnUxfxsUj2biXdzc06lOhbrBlbc6q1KjHesJqx8Pct0RcoJ PRE1bVJjLJNaGYOz70sUC79ZA3QIHCRPgQmpRL/4DvJEjoUAo5jNJ5xqaB1fXj8z9UDL 5KPhY1BnbXwNMI0qsH2Y+x35hwMKSOhuVObmISeQEzyAghPc0KsmauFCGtPX6pOZs4jr V5sQ== X-Gm-Message-State: AOAM532Q71CWKF0uQFUWnJizWbgLvjo/EArH2n9FgibXZSQuGVZkS+HA Zuxu7bW3S28qbQMVGcUZO04= X-Google-Smtp-Source: ABdhPJyA2pekcnN1dkKl7LdlnBt7D1rrtxJ1+bXghqqsLfDPlLvfBeXnS3GQuc1e6vG6wAGiooT9Qg== X-Received: by 2002:a63:1457:: with SMTP id 23mr11028526pgu.80.1598452572892; Wed, 26 Aug 2020 07:36:12 -0700 (PDT) Received: from [10.95.80.107] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id v78sm3508920pfc.121.2020.08.26.07.36.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Aug 2020 07:36:12 -0700 (PDT) Sender: Tony Li Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: tony.li@tony.li In-Reply-To: <6BC67FE7-5517-4733-96F1-A7991ABD9AF7@mnot.net> Date: Wed, 26 Aug 2020 07:36:07 -0700 Cc: IAB Executive Administrative Manager , edm@iab.org, architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6B5BBDD0-32F5-4E96-ADB8-813E4EA2A2A9@tony.li> References: <159839206489.26388.9889652884666821@ietfa.amsl.com> <1D675EBC-4AC7-4E01-87CC-4DF4F0D9DD3C@tony.li> <6BC67FE7-5517-4733-96F1-A7991ABD9AF7@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Edm] [arch-d] New IAB Program: Evolvability, Deployability, & Maintainability (EDM) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 14:37:17 -0000 Mark, The starting point should be a clear problem statement. With examples. Tony > On Aug 25, 2020, at 11:11 PM, Mark Nottingham wrote: >=20 > Tony, >=20 > Do you have any constructive feedback about the program, or other work = that we should focus on? Just calling it 'pointless' doesn't help. >=20 >=20 >> On 26 Aug 2020, at 7:53 am, tony.li@tony.li wrote: >>=20 >>=20 >> Seems like point 1 should be ignoring pointless IAB programs. >>=20 >> There=E2=80=99s work to be done. This isn=E2=80=99t it. >>=20 >> Tony >>=20 >>=20 >>> On Aug 25, 2020, at 2:47 PM, IAB Executive Administrative Manager = wrote: >>>=20 >>> A new IAB Program has been formed on Evolvability, Deployability, &=20= >>> Maintainability (EDM). For additional information, please contact = the=20 >>> IAB or the Program Lead. >>>=20 >>> Evolvability, Deployability, & Maintainability (EDM) Program >>> = ----------------------------------------------------------------------- >>>=20 >>> IAB Lead: >>> Tommy Pauly >>>=20 >>> Mailing list: >>> Address: edm@iab.org >>> To subscribe: https://www.iab.org/mailman/listinfo/edm >>> Archive: https://mailarchive.ietf.org/arch/browse/edm/ >>>=20 >>>=20 >>> Program Page: = https://www.iab.org/activities/programs/evolvability-deployability-maintai= nability-edm-program/ >>>=20 >>> Program Description: >>>=20 >>> This program will focus on how to practically encourage best = practices=20 >>> within the IETF to ensure that the IETF=E2=80=99s standards process = considers=20 >>> protocol evolution, deployability, and long-term maintainability. = This=20 >>> group will work on documents that catalog and analyze successful=20 >>> strategies for protocol evolution, deployment, and maintenance, such = as=20 >>> updating and extending RFC 6709. Moreover, it will focus on ways to = help=20 >>> promote and increase awareness of these strategies within the IETF = via=20 >>> program meetings, workshops, and helping organize efforts within = working=20 >>> groups and various IETF teams. The program will include members of = the=20 >>> IESG and the tools team to help implement these strategies. >>>=20 >>> The topics this group will consider include: >>>=20 >>> * Evolvability: Encourage protocols to design for extensibility and=20= >>> greasing, and promote the use of extension points to prevent=20 >>> ossification. Make it easy for people, especially those who aren=E2=80= =99t=20 >>> steeped in IETF process, to know which extension points are the = right=20 >>> ones to use for a given protocol (and which ones should be = considered=20 >>> more stable/ossified), and make sure there aren=E2=80=99t high = allocation=20 >>> barriers to use those extension points. >>>=20 >>> * Deployability: Focus on how we make =E2=80=9Crunning code=E2=80=9D = something that is=20 >>> better integrated into the working group process. Look at methods to=20= >>> catalog implementations, tools for tracking interoperability testing=20= >>> on different protocol versions, or repositories of which versions of=20= >>> protocols are implemented and used on the Internet. Discuss how=20 >>> deployments can advertise experiments they are running. >>>=20 >>> * Maintainability: Many working groups have expressed a desire to = have=20 >>> ways for the community of protocol designers and implementers to = keep=20 >>> track of the current state of affairs in deployment patterns, known=20= >>> errata/bugs, or best practices. Help promote consistent ways to host=20= >>> non-RFC working group output, like FAQs, wikis, and discussion = venues.=20 >>> Consider how this community involvement can continue and involve the=20= >>> right experts, even after a working group closes. >>>=20 >>> The program will: >>>=20 >>> * Engage with the IETF community and implementers outside of the = IETF to=20 >>> identity successes and problem areas, and collect ideas for=20 >>> improvements. >>> * Work with the IESG and directorates to determine how best = practices=20 >>> for evolvability can best be applied during IESG review and IETF = last=20 >>> call. >>> * Work with the IESG and tools team on ways to connect implementers = and=20 >>> communities that develop and maintain protocols, both while a = working=20 >>> group is active, and after a working group has concluded its = charter. >>>=20 >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>=20 >> --=20 >> Edm mailing list >> Edm@iab.org >> https://www.iab.org/mailman/listinfo/edm >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 From nobody Thu Aug 27 13:27:46 2020 Return-Path: X-Original-To: edm@iab.org Delivered-To: edm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7E83A12C0; Thu, 27 Aug 2020 13:27:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IAB Executive Administrative Manager To: "IETF-Announce" Cc: edm@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159856006489.13924.4875489094260747582@ietfa.amsl.com> Date: Thu, 27 Aug 2020 13:27:45 -0700 Archived-At: Subject: [Edm] Evolvability, Deployability, & Maintainability (edm) PROGRAM Virtual Meeting: 2020-09-01 X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 20:27:45 -0000 The Evolvability, Deployability, & Maintainability (edm) Program will hold a virtual interim meeting on 2020-09-01 from 06:30 to 07:30 America/Los_Angeles (13:30 to 14:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m93d7fb29860d4c036e0febf8201c84fc Meeting number: 171 082 4902 Password: Mp4RakAjy46 Join by video system Dial 1710824902@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-650-479-3208 Call-in toll number (US/Canada) Access code: 171 082 4902 From nobody Thu Aug 27 17:34:06 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40EA73A1480 for ; Thu, 27 Aug 2020 17:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=apple.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 DLiOLCIW6u1V for ; Thu, 27 Aug 2020 17:34:03 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 8B5A33A147F for ; Thu, 27 Aug 2020 17:34:03 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 07S0S4rx011877 for ; Thu, 27 Aug 2020 17:34:01 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=JJtM35HCK/wwVByyB49EDTRSZSpi7LTKTEJFbRZwxTg=; b=HTBVA1Mov/BnghmeY5XvdVBah2hCXsTjLd/7tKWorMI5XVcvaN2LJ8ZntShIq+N8BdAp q24RAP6GeKBYxJHLTOdr2GiZejm2fBaFbzchpJ4by+8Fi8MEWZOPaBle9vyWz5TRrXfh I2lEXcJKVfKnegeVfgvGoqLAT5v9oWFb7GGYQIZOna9oYuCXK1/uLwczJyo+gKC9RVU+ 4RWFTReGa0H0+OwnZBN9XgQ8G10u6rinsmgwXxWlXdnZ7t5w2rfJACxMfW0CbXk7/jCZ cj3UEKR9RDq9e1M98N9CD9qZtIYAVYLcNmMfvUs6+P7Nk0hnVjvXZlZ0GUYCPn1Gmzo1 nw== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 3357yw4cnr-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 27 Aug 2020 17:34:01 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QFR00M8408MTGN0@rn-mailsvcp-mta-lapp02.rno.apple.com> for edm@iab.org; Thu, 27 Aug 2020 17:33:59 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QFQ00200ZKNAU00@rn-mailsvcp-mmp-lapp04.rno.apple.com> for edm@iab.org; Thu, 27 Aug 2020 17:33:58 -0700 (PDT) X-Va-A: X-Va-T-CD: 1af8597529a643bc4f908cf463616f6c X-Va-E-CD: c6a38c9de11cd446ca5a7744cef6edd0 X-Va-R-CD: ae17d49471106e0cd83d560329d68745 X-Va-CD: 0 X-Va-ID: e202a9e2-90d3-4ea5-9c0f-a6708a8b484f X-V-A: X-V-T-CD: 1af8597529a643bc4f908cf463616f6c X-V-E-CD: c6a38c9de11cd446ca5a7744cef6edd0 X-V-R-CD: ae17d49471106e0cd83d560329d68745 X-V-CD: 0 X-V-ID: 8cc8419e-9d17-45e1-85c5-d8b4f878f68b X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-27_14:2020-08-27, 2020-08-27 signatures=0 Received: from [17.234.34.56] (unknown [17.234.34.56]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QFR00JAP08IV300@rn-mailsvcp-mmp-lapp04.rno.apple.com> for edm@iab.org; Thu, 27 Aug 2020 17:33:56 -0700 (PDT) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_A1B973D9-7840-4FDB-A37A-B7C96C6DA729" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Thu, 27 Aug 2020 17:33:53 -0700 References: To: edm@iab.org In-reply-to: Message-id: X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-27_14:2020-08-27, 2020-08-27 signatures=0 Archived-At: Subject: Re: [Edm] Welcome to EDM! X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 00:34:05 -0000 --Apple-Mail=_A1B973D9-7840-4FDB-A37A-B7C96C6DA729 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks to those who responded to the Doodle. We=E2=80=99ll have our = initial kickoff call on Tuesday, September 1 from 06:30 to 07:30 = America/Los_Angeles (13:30 to 14:30 UTC). https://ietf.webex.com/ietf/j.php?MTID=3Dm93d7fb29860d4c036e0febf8201c84fc= = Best, Tommy=20 > On Aug 21, 2020, at 4:35 PM, Tommy Pauly = wrote: >=20 > Hello all, >=20 > Welcome to the Evolvability, Deployability, and Maintainability IAB = program.=20 >=20 > First off, here are a few administrative links: >=20 > Datatracker: https://datatracker.ietf.org/group/edm/about/ > Program summary: = https://www.iab.org/activities/programs/evolvability-deployability-maintai= nability-edm-program/ > GitHub: https://github.com/intarchboard/edm >=20 > Considering the current circumstances, I expect we=E2=80=99ll operate = in virtual discussions for a while. We=E2=80=99ll see what works best, = but I=E2=80=99d like to start with the mailing list and the GitHub = issues list being our primary resources for discussion. We=E2=80=99ll = also set up some WebEx calls to dive into specific topics. >=20 > To start off our discussions, I=E2=80=99ve written up a few GitHub = issues that raise questions for this group. Please feel free to reply in = GitHub or send email to edm@iab.org. >=20 > =E2=80=A2 Approaches to tracking implementation interop and = deployment: https://github.com/intarchboard/edm/issues/1 > =E2=80=A2 What extension mechanisms are successful? = https://github.com/intarchboard/edm/issues/3 > =E2=80=A2 Moving Use-it-or-lose-it forward? = https://github.com/intarchboard/edm/issues/2 > =E2=80=A2 How should we coordinate greasing experiments? = https://github.com/intarchboard/edm/issues/4 >=20 > I also want to coordinate an initial WebEx the week of August 31 - = September 4. The time slots here are chosen to be in the window that = works across many time zones. Please fill out the Doodle if you=E2=80=99d = like to participate! >=20 > https://doodle.com/poll/t2wgvvtspbafzz8n >=20 > Best, > Tommy >=20 > --=20 > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm --Apple-Mail=_A1B973D9-7840-4FDB-A37A-B7C96C6DA729 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks to those who responded to the Doodle. We=E2=80=99ll = have our initial kickoff call on Tuesday, September 1 from 06:30 to = 07:30 America/Los_Angeles (13:30 to 14:30 UTC).

https://ietf.webex.com/ietf/j.php?MTID=3Dm93d7fb29860d4c036e0fe= bf8201c84fc

Best,
Tommy 

On Aug = 21, 2020, at 4:35 PM, Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote:

Hello = all,

Welcome to the Evolvability, = Deployability, and Maintainability IAB program.

First off, here are a few administrative links:

Datatracker: https://datatracker.ietf.org/group/edm/about/
Program summary: https://www.iab.org/activities/programs/evolvability-deployabil= ity-maintainability-edm-program/
GitHub: https://github.com/intarchboard/edm

Considering the current circumstances, I expect we=E2=80=99ll = operate in virtual discussions for a while. We=E2=80=99ll see what works = best, but I=E2=80=99d like to start with the mailing list and the GitHub = issues list being our primary resources for discussion. We=E2=80=99ll = also set up some WebEx calls to dive into specific topics.

To start off our discussions, I=E2=80=99ve = written up a few GitHub issues that raise questions for this group. = Please feel free to reply in GitHub or send email to edm@iab.org.

= =E2=80=A2 Approaches to tracking implementation interop and = deployment: https://github.com/intarchboard/edm/issues/1
= =E2=80=A2 What extension mechanisms are successful? https://github.com/intarchboard/edm/issues/3
= =E2=80=A2 Moving Use-it-or-lose-it forward? https://github.com/intarchboard/edm/issues/2
= =E2=80=A2 How should we coordinate greasing experiments? https://github.com/intarchboard/edm/issues/4

I also want to coordinate an initial WebEx the = week of August 31 - September 4. The time slots here are chosen to be in = the window that works across many time zones. Please fill out the Doodle = if you=E2=80=99d like to participate!

https://doodle.com/poll/t2wgvvtspbafzz8n

Best,
Tommy

--
Edm mailing list
Edm@iab.org
https://www.iab.org/mailman/listinfo/edm

= --Apple-Mail=_A1B973D9-7840-4FDB-A37A-B7C96C6DA729-- From nobody Fri Aug 28 08:12:19 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34BA3A0C75 for ; Fri, 28 Aug 2020 08:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 5Fn63GvSj5O5 for ; Fri, 28 Aug 2020 08:12:16 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 D56083A0C7A for ; Fri, 28 Aug 2020 08:12:15 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id ay8so1461859edb.8 for ; Fri, 28 Aug 2020 08:12:15 -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=Jipk0TKaDXlBjrNeJbzC/AHncTNl8Ho7gg9fe0yNJ7g=; b=L7MP7CD2kn92ZPwV//EKaYD6bbzPF0/dEB0okqbQ6QEcHTVyyr4DmolCPrch7VZLu+ 32XYZ9Ny3OJpu9L+zMY0guAX53dR79mJS2xmk5GVoNuTUGRfo/n3APoLEI6bNO6krvAq BlpNG1djLvKMIUSqycLlrVhTIOetzNNaGW3Eq8d7FMF0uQe7LF+XK/ejHerjnnthpkDz BHb5fR7OuHF6v8Kh8t3YHKs/AzfZBHCkPBNrmE2+NWsAT7tsoBEE9u+24E9vt85h6382 PR1OrO9Z8p8qsoRptOtzbICjkXK1EYsKB5J2e93oiSaYOXBjazk8BUC+3BKGrgwU71zq 8hVg== 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=Jipk0TKaDXlBjrNeJbzC/AHncTNl8Ho7gg9fe0yNJ7g=; b=Jrt5OgTkQrk4Eg2OLFSDlcfQbFEzRjYxFlK5MORyj/Rr8U+wBk5J/Ve6IpLCo5rKtZ d9cWnUHH7xAh79qxniJXzdV+afqY5zL9cOTihzkdCD3poaMKZGJNvJxMYEyvCf8o7h8A dH8Er/1RmjNOr7riLCmq2+12iBjzYMpnBMhCGNSnm7jcTTSBkLOwLt9RRfNhAhSXeJem XPGV1SdHK4DBGEMEaXH+YCbcffxM922jIWuU/UZQiHlDDouc0iPdgXvA/ZlmHo+UO8Mm h13esL/OmK3mpg97GLfPbRxMy8by1Xrn8Dscn+qPC/6mYR9+jCdP5OvqwVd5d+U8u6Ds BrSA== X-Gm-Message-State: AOAM530WHERDNoGSHAGfJ35FmW51f1BC5zmOUUtSo+Gn8K3M/6vRdPuI mqFfrBaOH0kOoBWoo5zEz8Bcq23UWQTVQT9h6TR7qVt35JjeYA== X-Google-Smtp-Source: ABdhPJypMWi3uWx40lq6RKvwLn7snJqbVfbyJ3eYts7aQvSofS3O0IDLr7S519UK5fq2d6NQ0aJtbYMvQUSl/PPiez0= X-Received: by 2002:a50:cd08:: with SMTP id z8mr2454028edi.185.1598627533691; Fri, 28 Aug 2020 08:12:13 -0700 (PDT) MIME-Version: 1.0 From: Vijay Gurbani Date: Fri, 28 Aug 2020 10:12:01 -0500 Message-ID: To: edm@iab.org Content-Type: multipart/alternative; boundary="000000000000461ef805adf17a39" Archived-At: Subject: [Edm] A modest proposal (?) for archiving code X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 15:12:18 -0000 --000000000000461ef805adf17a39 Content-Type: text/plain; charset="UTF-8" All: I proposed what I write below in the WG Chairs list; the list saw a good amount of discussion, ranging from summary dismissal to exploring the issue further. One feedback from there was to engage EDM. So here we go. Let me provide some context below, including links to the postings on the WG chairs list for those of you who may be interested in exploring that discussion further. The genesis of what I am trying to affect is simple: We produce standards that describe protocols. As a protocol is being defined in an I-D, there are often implementers implementing the protocol or portions of it. These implementations are important, enough that RFC 7942 [1] recognizes the import of these implementations and exhorts I-D authors to create an"Implementation Section" to document these implementations. RFC 7942 also asks I-D authors to remove this section before the I-D becomes an RFC. My question is if there are implementations that are worthy of being mentioned in an "Implementation Section" of a I-D, why don't we preserve these implementations in an IETF repository and link the repository in the RFC.This way, new implementers of the protocol can quickly bootstrap their implementations, leading to a diversity of implementations, which can only be good for a protocol that is trying to find its footing. Why is this important? Simple: Reaching out to developers outside of those of us who are already in the IETF is my biggest incentive. They are the ultimate consumers of what we produce. When I talk to developers at companies and students at universities, if they have heard of IETF at all, it is mostly through knowing that someorganization called IETF produces these things called RFCs. That's it.Perhaps for them that is enough. And if you buy that argument, then the corollary is that we should do everything in our power to make sure that they have all of the information they need to implement the protocol from the RFC itself. Consider the errata we maintain in an RFC. Imagine instead of us providing the errata, we simply told implementers that it is out there, go find it. The errata is important, so we list it in an RFC.When a protocol is finding its footing, early implementations that allow other developers to understand its behaviour and derive their own implementations from it is also important. So why not formalize the process of archiving implementations that are worthy of being listed as per RFC 7942? People have pointed out that we have WG pages, Wikis, datatrackers, and other such accoutrements for this purpose? WG pages, WG Wiki pages, datatrackers, all make sense to you and me. Many people will like to implement our protocols without burying themselves deep into IETF to know the difference between a WG page and datatracker. Their visibility into the IETF is through the RFC. So, put as much information in there that will make a developer productive. I don't claim that this will be easy; the length of thread discussion in the WG chairs list indicates the passion of the participants around the issue. However, I don't think that the issues raised are insurmountable. The fact that an entire RFC [1] was standardizes around the issue leads credence to the fact that it is an issue deserving some sustained attention. My initial email that started this discussion in the WG chairs list is in [3]. It has more information and context, including how organizations like IEEE and ACM have dealt with similar issues. [1] https://tools.ietf.org/html/rfc7942 [2] https://mailarchive.ietf.org/arch/msg/wgchairs/AGHRTKsDoSF3GJVhB4K2bKYjdWU/ [3] https://mailarchive.ietf.org/arch/msg/wgchairs/8_Or3U-Wwjw35VmLy_uTPID9sTU/ Thanks, - vijay --000000000000461ef805adf17a39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All: I proposed what I write below in the WG Chairs l= ist; the list saw a good amount of discussion, ranging from summary dismiss= al to exploring the issue further.=C2=A0 One feedback from there was to eng= age EDM.=C2=A0 So here we go.

Let me provide some = context below, including links to the postings on the WG chairs list for th= ose of you who may be interested in exploring that discussion further.
<= /div>

The genesis of what I am trying to affect is simpl= e: We produce standards that describe protocols. As a protocol is being def= ined in an I-D, there are often implementers implementing the protocol or p= ortions of it. These implementations are important, enough that RFC 7942 [1= ] recognizes the import of these implementations and exhorts I-D authors to= create an"Implementation Section" to document these implementati= ons. RFC 7942 also asks I-D authors to remove this section before the I-D b= ecomes an RFC. My question is if there are implementations that are worthy = of being mentioned in an "Implementation Section" of a I-D, why d= on't we preserve these implementations in an IETF repository and link t= he repository in the RFC.This way, new implementers of the protocol can qui= ckly bootstrap their implementations, leading to a diversity of implementat= ions, which can only be good for a protocol that is trying to find its foot= ing.

Why is this important? Simple: Reaching out t= o developers outside of those of us who are already in the IETF is my bigge= st incentive. They are the ultimate consumers of what we produce.

When I talk to developers at companies and students at univ= ersities, if they have heard of IETF at all, it is mostly through knowing t= hat someorganization called IETF produces these things called RFCs. That= 9;s it.Perhaps for them that is enough. And if you buy that argument, then = the corollary is that we should do everything in our power to make sure tha= t they have all of the information they need to implement the protocol from= the RFC itself. Consider the errata we maintain in an RFC. Imagine instead= of us providing the errata, we simply told implementers that it is out the= re, go find it. The errata is important, so we list it in an RFC.When a pro= tocol is finding its footing, early implementations that allow other develo= pers to understand its behaviour and derive their own implementations from = it is also important. So why not formalize the process of archiving impleme= ntations that are worthy of being listed as per RFC 7942?

People have pointed out that we have WG pages, Wikis, datatrackers,= and other such accoutrements for this purpose? WG pages, WG Wiki pages, da= tatrackers, all make sense to you and me. Many people will like to implemen= t our protocols without burying themselves deep into IETF to know the diffe= rence between a WG page and datatracker. Their visibility into the IETF is = through the RFC. So, put as much information in there that will make a deve= loper productive.

I don't claim that this will= be easy; the length of thread discussion in the WG chairs list indicates t= he passion of the participants around the issue. However, I don't think= that the issues raised are insurmountable.=C2=A0 The fact that an entire R= FC [1] was standardizes around the issue leads credence to the fact that it= is an issue deserving some sustained attention.

My initial email that started this discussion in the WG chairs list is i= n [3]. It has more information and context, including how organizations lik= e IEEE and ACM have dealt with similar issues.



<= /div> --000000000000461ef805adf17a39-- From nobody Sun Aug 30 00:41:32 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661223A14F6 for ; Sun, 30 Aug 2020 00:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=mnot.net header.b=YAkiCVLo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HFrf3mzL 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 WoLBw9PLhFAI for ; Sun, 30 Aug 2020 00:41:25 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF793A14FA for ; Sun, 30 Aug 2020 00:41:25 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id BE79AD22 for ; Sun, 30 Aug 2020 03:32:27 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 30 Aug 2020 03:32:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm3; bh=n4GuH7ZJLg4nJvujPQh+PfMGUCpmcl2bhg7bDKaESH8=; b=YAkiCVLo BC93NvsOyQEnqYmgtqOThMbilwW1FOuoG0I5RHIIHrKtRlCOCXIVeYfwsJQarRvK G3B4YsH3T6/j1uqKB7gvGeUZaLh09SvrqlCy01RlKyrYh+zkxD85T0k4IUSZlT2G Iejx5SN5hKqcOlJjD9/0aXAt0gaQbvsACtMcrvMIIKVUF4EmufJW9Xp8SeR6Fwt2 MGQYV1Ocu86SulvDWW2KHBDmt/KQqNBnYSxe17CMxv2VCw5mk27pEwtKJ6syguxE ovBs5egGeO6XCkaWNx7lsKkqIlOKFnLFiNaq1WPUeS1RwPmnXtwWzTOX8FutuhNQ Q0aTlCwJzpHGtQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=n4GuH7ZJLg4nJvujPQh+PfMGUCpmc l2bhg7bDKaESH8=; b=HFrf3mzLisUZBRmgyP1tVMyzOoK+gqYzs+xR5fvwzxGqI ZVVg10FK6LLUMIQINBip6wAvbR8dhSDmIz7nqIM/fXaiIDXGnLnPmnGW/9scvIEI 95oaNuQ+BtvX+0hWXNJeCEv2KMRAJ1etySt8HaSL8/U9yRSkGQdfF3fM411XudX4 sLaPZ+u7BkIwpwezD2sr1yWuKfF3fjXinWURqV4uaO8e1a/Oov63k9S5xBZiNUZ1 nXnWxIpyGtCHkaQupFP/NYo7a6v4pl1M+1gzeWcSsE1XIwtPc0fROzNn/etj4ZBR hJm7i/MyVVFVEUxn2g5c9hDmD62MGBZNrDiFjx8mQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudefvddguddujecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrudejjedrudejvd drvddvnecuvehluhhsthgvrhfuihiivgepgeenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az50.internal.cloudapp.net (unknown [52.177.172.22]) by mail.messagingengine.com (Postfix) with ESMTPA id 1782E3280063 for ; Sun, 30 Aug 2020 03:32:27 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============7365431894738119526==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: edm@iab.org Message-Id: <20200830073227.1782E3280063@mailuser.nyi.internal> Date: Sun, 30 Aug 2020 03:32:27 -0400 (EDT) Archived-At: Subject: [Edm] Weekly github digest (EDM Activity Summary) X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 07:41:27 -0000 --===============7365431894738119526== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * intarchboard/edm (+1/-0/=F0=9F=92=AC5) 1 issues created: - How to organise inter-op testing (by mirjak) https://github.com/intarchboard/edm/issues/5=20 4 issues received 5 new comments: - #5 How to organise inter-op testing (2 by mirjak) https://github.com/intarchboard/edm/issues/5=20 - #3 What extension mechanisms are successful? (1 by mirjak) https://github.com/intarchboard/edm/issues/3 [evolvability]=20 - #2 Moving Use-it-or-lose-it forward? (1 by mirjak) https://github.com/intarchboard/edm/issues/2 [evolvability]=20 - #1 Approaches to tracking implementation interop and deployment (1 by m= irjak) https://github.com/intarchboard/edm/issues/1 [deployability]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/intarchboard/edm --===============7365431894738119526== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (EDM Activity Summary)

Sunday August 30, 2020

Issues

intarchboard/edm (+1/-0/=F0=9F=92=AC5)

1 issues created:

4 issues received 5 new comments:

Repositories tracked by this digest:

--===============7365431894738119526==-- From nobody Mon Aug 31 03:25:18 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A923A1208 for ; Mon, 31 Aug 2020 03:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 0N1nLsCexNDv for ; Mon, 31 Aug 2020 03:25:09 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 0B84D3A11F5 for ; Mon, 31 Aug 2020 03:25:08 -0700 (PDT) Received: from p200300dee7459100a0818e4c11d3d616.dip0.t-ipconnect.de ([2003:de:e745:9100:a081:8e4c:11d3:d616]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1kCgzq-0008GJ-II; Mon, 31 Aug 2020 12:25:06 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mirja Kuehlewind In-Reply-To: Date: Mon, 31 Aug 2020 12:25:01 +0200 Cc: edm@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Vijay Gurbani X-Mailer: Apple Mail (2.3608.80.23.2.2) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1598869509;f9a23285; X-HE-SMSGID: 1kCgzq-0008GJ-II Archived-At: Subject: Re: [Edm] A modest proposal (?) for archiving code X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 10:25:13 -0000 Hi Vijay, Thanks for bringing this discussion to this list! I agree with the goal to make it easier or easy for implementors to find = reference implementation or any kind of existing code. However, I'm not = sure if putting this information in the RFC is the right approach. As = you mentioned errata below, this are actually also not part of the RFC = itself but only the metadata and it depends on the page that you look at = if you see them or not. That a separate problem but I just wanted to = underline that putting more information in the metadata might not be the = right/only solution. I guess as a first step it would be nice get a = better understand about how people usually find and use RFCs and maybe = also how to redirect people to the right page then. Mirja =20 > On 28. Aug 2020, at 17:12, Vijay Gurbani = wrote: >=20 > All: I proposed what I write below in the WG Chairs list; the list saw = a good amount of discussion, ranging from summary dismissal to exploring = the issue further. One feedback from there was to engage EDM. So here = we go. >=20 > Let me provide some context below, including links to the postings on = the WG chairs list for those of you who may be interested in exploring = that discussion further. >=20 > The genesis of what I am trying to affect is simple: We produce = standards that describe protocols. As a protocol is being defined in an = I-D, there are often implementers implementing the protocol or portions = of it. These implementations are important, enough that RFC 7942 [1] = recognizes the import of these implementations and exhorts I-D authors = to create an"Implementation Section" to document these implementations. = RFC 7942 also asks I-D authors to remove this section before the I-D = becomes an RFC. My question is if there are implementations that are = worthy of being mentioned in an "Implementation Section" of a I-D, why = don't we preserve these implementations in an IETF repository and link = the repository in the RFC.This way, new implementers of the protocol can = quickly bootstrap their implementations, leading to a diversity of = implementations, which can only be good for a protocol that is trying to = find its footing. >=20 > Why is this important? Simple: Reaching out to developers outside of = those of us who are already in the IETF is my biggest incentive. They = are the ultimate consumers of what we produce. >=20 > When I talk to developers at companies and students at universities, = if they have heard of IETF at all, it is mostly through knowing that = someorganization called IETF produces these things called RFCs. That's = it.Perhaps for them that is enough. And if you buy that argument, then = the corollary is that we should do everything in our power to make sure = that they have all of the information they need to implement the = protocol from the RFC itself. Consider the errata we maintain in an RFC. = Imagine instead of us providing the errata, we simply told implementers = that it is out there, go find it. The errata is important, so we list it = in an RFC.When a protocol is finding its footing, early implementations = that allow other developers to understand its behaviour and derive their = own implementations from it is also important. So why not formalize the = process of archiving implementations that are worthy of being listed as = per RFC 7942? >=20 > People have pointed out that we have WG pages, Wikis, datatrackers, = and other such accoutrements for this purpose? WG pages, WG Wiki pages, = datatrackers, all make sense to you and me. Many people will like to = implement our protocols without burying themselves deep into IETF to = know the difference between a WG page and datatracker. Their visibility = into the IETF is through the RFC. So, put as much information in there = that will make a developer productive. >=20 > I don't claim that this will be easy; the length of thread discussion = in the WG chairs list indicates the passion of the participants around = the issue. However, I don't think that the issues raised are = insurmountable. The fact that an entire RFC [1] was standardizes around = the issue leads credence to the fact that it is an issue deserving some = sustained attention. >=20 > My initial email that started this discussion in the WG chairs list is = in [3]. It has more information and context, including how organizations = like IEEE and ACM have dealt with similar issues. >=20 > [1] https://tools.ietf.org/html/rfc7942 > [2] = https://mailarchive.ietf.org/arch/msg/wgchairs/AGHRTKsDoSF3GJVhB4K2bKYjdWU= / > [3] = https://mailarchive.ietf.org/arch/msg/wgchairs/8_Or3U-Wwjw35VmLy_uTPID9sTU= / >=20 > Thanks, >=20 > - vijay > --=20 > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm From nobody Mon Aug 31 14:57:59 2020 Return-Path: X-Original-To: edm@ietfa.amsl.com Delivered-To: edm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529A53A08DB for ; Mon, 31 Aug 2020 14:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=apple.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 RgIevZA7vPC2 for ; Mon, 31 Aug 2020 14:57:56 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 757FC3A08C3 for ; Mon, 31 Aug 2020 14:57:56 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 07VLrqP1013108; Mon, 31 Aug 2020 14:57:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=ZZzQ3ODByhr7MsBex7mq9nJV/KdCuaxFrjzgXfZje5c=; b=ij5iKdBrZEWX7C+H/W9FHaNYUDreA58i8X7ZJTlsJbir40aBayOefkShCB1aR6YEMemi ZaovjUyfWURwGnM6QFG1b/tB0VpIxbTWW5WiamDlipgHQQXd2rHp0gjsLAh1h+w+ClZ6 qlFBorpU5jGWtVli6DJtClMOEA0P/g4wR/GgZfs8Prffu1elNIt0RNHpKxOOeCloMvo7 BM7j6FcgV7j8eUpEi2fzlknhzvYMl1f1qlh05hlyxVjUupr6YJQ8LLyokuhf2MRU0Qk8 Qf92Df21/q/m7whapg4cfTcoQts1d/sX/6nsn9+Lhc1lqBxyiSNmoycBJF+iG2fLnlc+ 4A== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 337p0u5sa9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 31 Aug 2020 14:57:53 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QFY00NPS7OHIMG0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Mon, 31 Aug 2020 14:57:53 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QFY00O007NNRR00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 31 Aug 2020 14:57:53 -0700 (PDT) X-Va-A: X-Va-T-CD: da535c4073f98b0aaf118f024224a2bc X-Va-E-CD: afe280754a635ec45f4a2165ad073415 X-Va-R-CD: f0b5c6ca852f0fb4c68db7be83cb27e2 X-Va-CD: 0 X-Va-ID: 48cf2d65-cd7a-4351-a290-b683b1eaf2e7 X-V-A: X-V-T-CD: da535c4073f98b0aaf118f024224a2bc X-V-E-CD: afe280754a635ec45f4a2165ad073415 X-V-R-CD: f0b5c6ca852f0fb4c68db7be83cb27e2 X-V-CD: 0 X-V-ID: a88c4e02-bd61-4f97-962c-04fcf5fbe339 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-31_10:2020-08-31, 2020-08-31 signatures=0 Received: from localhost.localdomain (unknown [17.232.161.239]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QFY00A947OFJ800@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Mon, 31 Aug 2020 14:57:52 -0700 (PDT) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\)) From: Tommy Pauly In-reply-to: Date: Mon, 31 Aug 2020 14:57:51 -0700 Cc: edm@iab.org Content-transfer-encoding: quoted-printable Message-id: <3A4FC17C-7BEF-443E-A66F-DD49F98AA784@apple.com> References: To: Mirja Kuehlewind , Vijay Gurbani X-Mailer: Apple Mail (2.3654.0.3.2.26) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-31_10:2020-08-31, 2020-08-31 signatures=0 Archived-At: Subject: Re: [Edm] A modest proposal (?) for archiving code X-BeenThere: edm@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 21:57:58 -0000 RFC 7942 does mention the direction of adding metadata to an RFC in the = tools view: "Later, the IETF Tools may support this functionality, e.g., by including such a link in the HTML file of the document, similar to the IPR link.=E2=80=9D It certainly is frustrating that different views of RFCs show different = metadata, but if we had more formal repositories of implementation = information, I think we=E2=80=99d want to be able to link to them. A step can be figuring out how it would make sense present implementer = information in a standard location and format, and we can figure out how = to best tie it to documents next. Tommy > On Aug 31, 2020, at 3:25 AM, Mirja Kuehlewind = wrote: >=20 > Hi Vijay, >=20 > Thanks for bringing this discussion to this list! >=20 > I agree with the goal to make it easier or easy for implementors to = find reference implementation or any kind of existing code. However, I'm = not sure if putting this information in the RFC is the right approach. = As you mentioned errata below, this are actually also not part of the = RFC itself but only the metadata and it depends on the page that you = look at if you see them or not. That a separate problem but I just = wanted to underline that putting more information in the metadata might = not be the right/only solution. I guess as a first step it would be nice = get a better understand about how people usually find and use RFCs and = maybe also how to redirect people to the right page then. >=20 > Mirja >=20 >=20 >=20 >> On 28. Aug 2020, at 17:12, Vijay Gurbani = wrote: >>=20 >> All: I proposed what I write below in the WG Chairs list; the list = saw a good amount of discussion, ranging from summary dismissal to = exploring the issue further. One feedback from there was to engage EDM. = So here we go. >>=20 >> Let me provide some context below, including links to the postings on = the WG chairs list for those of you who may be interested in exploring = that discussion further. >>=20 >> The genesis of what I am trying to affect is simple: We produce = standards that describe protocols. As a protocol is being defined in an = I-D, there are often implementers implementing the protocol or portions = of it. These implementations are important, enough that RFC 7942 [1] = recognizes the import of these implementations and exhorts I-D authors = to create an"Implementation Section" to document these implementations. = RFC 7942 also asks I-D authors to remove this section before the I-D = becomes an RFC. My question is if there are implementations that are = worthy of being mentioned in an "Implementation Section" of a I-D, why = don't we preserve these implementations in an IETF repository and link = the repository in the RFC.This way, new implementers of the protocol can = quickly bootstrap their implementations, leading to a diversity of = implementations, which can only be good for a protocol that is trying to = find its footing. >>=20 >> Why is this important? Simple: Reaching out to developers outside of = those of us who are already in the IETF is my biggest incentive. They = are the ultimate consumers of what we produce. >>=20 >> When I talk to developers at companies and students at universities, = if they have heard of IETF at all, it is mostly through knowing that = someorganization called IETF produces these things called RFCs. That's = it.Perhaps for them that is enough. And if you buy that argument, then = the corollary is that we should do everything in our power to make sure = that they have all of the information they need to implement the = protocol from the RFC itself. Consider the errata we maintain in an RFC. = Imagine instead of us providing the errata, we simply told implementers = that it is out there, go find it. The errata is important, so we list it = in an RFC.When a protocol is finding its footing, early implementations = that allow other developers to understand its behaviour and derive their = own implementations from it is also important. So why not formalize the = process of archiving implementations that are worthy of being listed as = per RFC 7942? >>=20 >> People have pointed out that we have WG pages, Wikis, datatrackers, = and other such accoutrements for this purpose? WG pages, WG Wiki pages, = datatrackers, all make sense to you and me. Many people will like to = implement our protocols without burying themselves deep into IETF to = know the difference between a WG page and datatracker. Their visibility = into the IETF is through the RFC. So, put as much information in there = that will make a developer productive. >>=20 >> I don't claim that this will be easy; the length of thread discussion = in the WG chairs list indicates the passion of the participants around = the issue. However, I don't think that the issues raised are = insurmountable. The fact that an entire RFC [1] was standardizes around = the issue leads credence to the fact that it is an issue deserving some = sustained attention. >>=20 >> My initial email that started this discussion in the WG chairs list = is in [3]. It has more information and context, including how = organizations like IEEE and ACM have dealt with similar issues. >>=20 >> [1] https://tools.ietf.org/html/rfc7942 >> [2] = https://mailarchive.ietf.org/arch/msg/wgchairs/AGHRTKsDoSF3GJVhB4K2bKYjdWU= / >> [3] = https://mailarchive.ietf.org/arch/msg/wgchairs/8_Or3U-Wwjw35VmLy_uTPID9sTU= / >>=20 >> Thanks, >>=20 >> - vijay >> --=20 >> Edm mailing list >> Edm@iab.org >> https://www.iab.org/mailman/listinfo/edm >=20 > --=20 > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm