From nobody Mon Jul 6 12:02:18 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A733A0A09 for ; Mon, 6 Jul 2020 12:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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 Aa-j9YT0HPyf for ; Mon, 6 Jul 2020 12:02:07 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 53FCF3A09CC for ; Mon, 6 Jul 2020 12:02:06 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 066IjFlk006354 for ; Mon, 6 Jul 2020 12:02:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=yhSYFqY8DOk8nXv0g8H4BcUPTHhZ3onzXSSs1KOr568=; b=k5sZHQq6iNLU1Wo2tejvjPrB8XXtHonDtnIGNj/OJFWSf5kPy0P8llDqro7A0C4dqKjR cyW7nSxD5vf3WA44lOFnvr3ziLUMW8kVY2X3oE9g0ZNcy/DS2/gLq1ZSsGe2OULTzNd2 wJgtR8Z81hYsAhZOIm2v10D22dPR9nF/f6EjjfevYaV0SFaE5IqMHOMn9cHTro4AHE+0 SYhhjBmoGQO8myh66iKgzRIVZPhyOfTtHBji/pKoVAGnUZrISWTVd2bKrRz55NCaFZSA 5M0tVnXG8Io+SU4sgavOvoK+sm1IO1z7xHt2n2R06einZnMxfVt6HuJdYM3tm3DDtUBu 9Q== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 322pescv45-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 06 Jul 2020 12:02:05 -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-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QD200TX2A7A6IL0@rn-mailsvcp-mta-lapp03.rno.apple.com> for architecture-discuss@iab.org; Mon, 06 Jul 2020 12:01: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.5.20200312 64bit (built Mar 12 2020)) id <0QD200E00A7AJX00@rn-mailsvcp-mmp-lapp04.rno.apple.com> for architecture-discuss@iab.org; Mon, 06 Jul 2020 12:01:59 -0700 (PDT) X-Va-A: X-Va-T-CD: f34240ee9f18a8bc9b487d2fa1de37f1 X-Va-E-CD: 80fc74c126ddaebfaa5b4bd5a801094e X-Va-R-CD: bd1804ac603c8166b4722f6ca7eb6779 X-Va-CD: 0 X-Va-ID: 75bd2119-0272-4da3-ac28-34a2b4c03d4a X-V-A: X-V-T-CD: f34240ee9f18a8bc9b487d2fa1de37f1 X-V-E-CD: 80fc74c126ddaebfaa5b4bd5a801094e X-V-R-CD: bd1804ac603c8166b4722f6ca7eb6779 X-V-CD: 0 X-V-ID: d71d17a5-ce46-41d8-9c45-52d9bfe632b6 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-06_16:2020-07-06, 2020-07-06 signatures=0 Received: from [17.235.49.12] (unknown [17.235.49.12]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QD200OJ0A7A8R00@rn-mailsvcp-mmp-lapp04.rno.apple.com> for architecture-discuss@iab.org; Mon, 06 Jul 2020 12:01:59 -0700 (PDT) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_167563D1-F0B3-45C9-92C5-94FA7FE460F6" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Message-id: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> Date: Mon, 06 Jul 2020 12:01:58 -0700 To: "architecture-discuss@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-07-06_16:2020-07-06, 2020-07-06 signatures=0 Archived-At: Subject: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 19:02:16 -0000 --Apple-Mail=_167563D1-F0B3-45C9-92C5-94FA7FE460F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The IAB is considering starting a new program that would look at the = Evolvability, Deployability, and Maintainability of Internet protocols. = The description of the program is included at the bottom of this email. We=E2=80=99d like to get feedback on the proposed program topic and = description. We=E2=80=99ll be considering this over the next few weeks, = and your thoughts and input are welcome! Best, Tommy =3D=3D=3D=3D=3D=3D Evolvability, Deployability, & Maintainability (EDM) Program This program will focus on how to practically encourage best practices = within the IETF to ensure that the IETF=E2=80=99s 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=E2=80=99t= 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 =E2=80=9Crunning code=E2=80=9D = 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: =E2=80=A2 Engage with the IETF community and implementers = outside of the IETF to identity successes and problem areas, and collect = ideas for improvements. =E2=80=A2 Work with the IESG and directorates to determine how = best practices for evolvability can best be applied during IESG review = and IETF last call. =E2=80=A2 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.= --Apple-Mail=_167563D1-F0B3-45C9-92C5-94FA7FE460F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
The IAB is considering starting a new program that would look = at the Evolvability, Deployability, and Maintainability of Internet = protocols. The description of the program is included at the bottom of = this email.

We=E2=80=99d like to get feedback on the proposed program = topic and description. We=E2=80=99ll be considering this over the next = few weeks, and your thoughts and input are welcome!

Best,
Tommy

=3D=3D=3D=3D=3D=3D

Evolvability, Deployability, & Maintainability = (EDM) Program

This program will focus on = how to practically encourage best practices within the IETF to ensure = that the IETF=E2=80=99s 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=E2=80=99t 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 =E2=80=9Crunning code=E2=80=9D 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:
=E2=80=A2 Engage with the IETF = community and implementers outside of the IETF to identity successes and = problem areas, and collect ideas for improvements.
=E2=80=A2 Work with the IESG and = directorates to determine how best practices for evolvability can best = be applied during IESG review and IETF last call.
= =E2=80=A2 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.= --Apple-Mail=_167563D1-F0B3-45C9-92C5-94FA7FE460F6-- From nobody Mon Jul 6 13:01:45 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007D63A0A01 for ; Mon, 6 Jul 2020 13:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 10l6GWQfkqCc for ; Mon, 6 Jul 2020 13:01:39 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A023A0A00 for ; Mon, 6 Jul 2020 13:01:39 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 83B58548441; Mon, 6 Jul 2020 22:01:33 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 76822440043; Mon, 6 Jul 2020 22:01:33 +0200 (CEST) Date: Mon, 6 Jul 2020 22:01:33 +0200 From: Toerless Eckert To: Tommy Pauly Cc: "architecture-discuss@iab.org" Message-ID: <20200706200133.GN13952@faui48f.informatik.uni-erlangen.de> References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 20:01:42 -0000 Thanks, Tommy, inline On Mon, Jul 06, 2020 at 12:01:58PM -0700, Tommy Pauly wrote: > The IAB is considering starting a new program that would look at the Evolvability, Deployability, and Maintainability of Internet protocols. The description of the program is included at the bottom of this email. Std toerless rant#1: The Internet is the 10% above waterline of the iceberg which is IETF protocols. Please do not ignore the remaining other 90% of "private network" use. Maybe use term "ITF protocols" or something similar to make it clear whether you want to target 10% or 100% (or anything in between). > We???d like to get feedback on the proposed program topic and description. We???ll be considering this over the next few weeks, and your thoughts and input are welcome! > > Best, > Tommy > > ====== > > Evolvability, Deployability, & Maintainability (EDM) Program > > 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. I would like to see the work item point: "IESG safe documentation of extension point / behavior / possible benefits" Explanation: i had a painfull IESG review of a draft of mine where we used a simple terminology at the end of sections saying things like "future work may ". The IESG review feedback (primarily from GEN) was that this draft looked unfinished and should not be standardized because of the repeated use of the term "future work". I had to remove all of this text, partially putting things into non-normative appendices, etc.. pp. In later IESG review i had to add some notes about future work with this terminology, Now it is impossible (like in IMHO all other RFC) to easily find extension point documentation in my draft consistently. At the risk of getting into a similar endless debate as Mirja's good intentioned update to "update", maybe there could be terminology like "FUTURE" that allows to formally show / explain extension points. Or anything else to easier document them through the IESG review process. > 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. I think you are listing what likely are the key issues for application/software centric issues with deployability (down to at most host-stack). For deployability on network "equipment", router/switches/gateways with hardware accelerated forwarding and other processing planes, there are additional considerations IMHO most important for this space: Models for internal behavior of forwarding/control-plane against which to assess behavior/scalability/cost of proposed protocols (amount of state, complexity of QoS / packet processing),.. Architecture direction to evolve these type of protocol devices into a more "software centric" model. For example, it took about a decade in my memory before IETF would even include terms like RIB or FIB into routing area protocol RC because "dogmatic" IETF persons did reject them in before as something not externally visible and hence irrelevant to interop behavior. We had last year a session to talk about router forwarding planes where a bit of this was touched, but we never followed up with any documentation in form of BCPs and the like. Obviously this is a lot of work, but IMHO well worth it if not required for future evolution. For example 2: I still have ongoing discussions with IESG about the validity of internal interfaces between SW components in routers in standards track documents, because it supposedly does not impact interoperability (between devices), and the mere thought that these software components could be from different vendors has not entered the mindset of most IESG people working with routers. > 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. Definitely, but... (see below) > 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. This would all be great work to do if it was not executed ONLY via a current IAB program. This is too important work to be subject to the whim of IAB member interest. Its not maintaineable if its only done via an IAB program. IMHO, this should be an IAB AG (architecture group) that has IAB members (like IESG members) as sponsors and creators, but which has AG chairs running a standard RG/WG process, that can persist beyond the terms of individual IAB members interests, and that isn't subject to all the other issues i have with IAB processes. Aka: No need to work on maintaineability if the process to work on maintainability is not maintainable. Cheers Toerless > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Mon Jul 6 15:06:00 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD433A0B71 for ; Mon, 6 Jul 2020 15:05:58 -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, FREEMAIL_FROM=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 LN6pAlAXzGOE for ; Mon, 6 Jul 2020 15:05:57 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 7F5E63A0B72 for ; Mon, 6 Jul 2020 15:05:57 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id i14so1041321pfu.13 for ; Mon, 06 Jul 2020 15:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=L2N1Y1Q2lFe5Y8BGJSogsjaq/aDfTAVpvrKCgpDKq9Y=; b=lalfE21PYdMo9HW1duxO0RnXiN5JiGP29mBG77eUlf76dL0GjOijrvvb4YRFXDaDqZ hx+E8q52oJ9QKyKkzXmS/tQRhhVFCWZE9KxCvv9WKfB2WTRXb6gZcnXvmAoCF5dY6sh8 PDmnijqN6hooD3NCuoJPTPQWifQomBRcKxdXAIQilSGpZGrrCU9rzjD9hnLvZtE+NPPc iNnBLgP8wYyYg9rpWuHnnqG9WrGXzXm1Jb3EiEI84n0cyEcThccYVgj8wnUmDUrQPmeD YRtOO5yz/8MLASQqgMG3x5FedAVDRw3pzrPcBU2QfSJTq/I5aBMbtXzHnn7PcrtG6eQn I45A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=L2N1Y1Q2lFe5Y8BGJSogsjaq/aDfTAVpvrKCgpDKq9Y=; b=Aae5tzvQm3jfBBasF86hF6oPVjjP3S0sM0+Y9GD8dS1C9tz4OqaI8Tbvclmel2h+yI 20mFA3ea/9h3NuYhrYyZRFZg2/QNAU0i/42StWGqXHag/xVmQs07RVv5wmgViY7k3psg Iv0E/niYJXl+gjPsEQ6co9AzYrrh/yO+Jtlhf4wkRIDhZuyel7254z1MH7hpW8n7Hkyl 8KTaachR4/d5cLJBF5uVpzVFBZIM+ro9VAjZYgJcEcMtd85S2yrDMFLQbLY8pu1ycVfg J7bziu1uvJGiD9QLnlDrpS5JBqXyEehBkQ22Yof/qpbyIFq9o5L3CWaLICOK+bFJeElc AlZw== X-Gm-Message-State: AOAM532iMJ/dURefNVef0IeY471bcuEuKhUu7h+a1C8MjbwXfpedKvf0 V34mh/eaRDINHceA93lbvRUIEDvz X-Google-Smtp-Source: ABdhPJxw9YJ2AJs/ebqGQ39w8a9J6fJsjJv0cC/WXrcHJbM9Qf2h+NWFkeE5X2UrSGRiTk9ZjtjnoA== X-Received: by 2002:a62:158d:: with SMTP id 135mr27985433pfv.287.1594073156412; Mon, 06 Jul 2020 15:05:56 -0700 (PDT) Received: from [192.168.178.20] ([151.210.129.236]) by smtp.gmail.com with ESMTPSA id 73sm20573700pfy.24.2020.07.06.15.05.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2020 15:05:55 -0700 (PDT) To: Tommy Pauly , "architecture-discuss@iab.org" References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 7 Jul 2020 10:05:52 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 22:05:59 -0000 Tommy, A good topic. But there's an elephant in the corner of the room and I'm n= ot sure you can ignore it. The same elephant is in the corner of the room= where we're discussing the future role of the RFC Series Editor, althoug= h I've argued that it shouldn't be there because it's an IETF problem. To what extent is the standards process itself the enemy of Evolvability,= Deployability, and Maintainability? In particular, does the way we handl= e document revisions and interdependencies make it harder for implementor= s and operators do decide which features to implement and deploy? Why don= 't we issue many more of what RFC2026 calls "applicability statements"? W= hy don't we issue living documents that define which documents are part o= f a particular standard at a particular time? It's not that we've never done this to some extent. RFC4294->RFC6434->RFC= 8504 is an example, but only 3 versions over 13 years is grossly inadequa= te. An update every 6 months might have been more appropriate. SMTP has been the classical example for many years, and I suspect that RT= CWEB might furnish another good example of this problem before long. Regards Brian Carpenter On 07-Jul-20 07:01, Tommy Pauly wrote: > The IAB is considering starting a new program that would look at the Ev= olvability, Deployability, and Maintainability of Internet protocols. The= description of the program is included at the bottom of this email. >=20 > We=E2=80=99d like to get feedback on the proposed program topic and des= cription. We=E2=80=99ll be considering this over the next few weeks, and = your thoughts and input are welcome! >=20 > Best, > Tommy >=20 > =3D=3D=3D=3D=3D=3D >=20 > Evolvability, Deployability, & Maintainability (EDM) Program >=20 > This program will focus on how to practically encourage best practices = within the IETF to ensure that the IETF=E2=80=99s standards process consi= ders protocol evolution, deployability, and long-term maintainability. Th= is group will work on documents that catalog and analyze successful strat= egies for protocol evolution, deployment, and maintenance, such as updati= ng and extending RFC 6709. Moreover, it will focus on ways to help promot= e and increase awareness of these strategies within the IETF via program = meetings, workshops, and helping organize efforts within working groups a= nd various IETF teams. The program will include members of the IESG and t= he tools team to help implement these strategies. >=20 > The topics this group will consider include: >=20 > Evolvability: Encourage protocols to design for extensibility and g= reasing, and promote the use of extension points to prevent ossification.= Make it easy for people, especially those who aren=E2=80=99t steeped in = IETF process, to know which extension points are the right ones to use fo= r a given protocol (and which ones should be considered more stable/ossif= ied), and make sure there aren't high allocation barriers to use those ex= tension points. >=20 >=20 > Deployability: Focus on how we make =E2=80=9Crunning code=E2=80=9D = something that is better integrated into the working group process. Look = at methods to catalog implementations, tools for tracking interoperabilit= y testing on different protocol versions, or repositories of which versio= ns of protocols are implemented and used on the Internet. Discuss how dep= loyments can advertise experiments they are running. >=20 >=20 > Maintainability: Many working groups have expressed a desire to hav= e ways for the community of protocol designers and implementers to keep t= rack of the current state of affairs in deployment patterns, known errata= /bugs, or best practices. Help promote consistent ways to host non-RFC wo= rking group output, like FAQs, wikis, and discussion venues. Consider how= this community involvement can continue and involve the right experts, e= ven after a working group closes. >=20 >=20 > The program will: > =E2=80=A2 Engage with the IETF community and implementers outside of th= e IETF to identity successes and problem areas, and collect ideas for imp= rovements. > =E2=80=A2 Work with the IESG and directorates to determine how best pra= ctices for evolvability can best be applied during IESG review and IETF l= ast call. > =E2=80=A2 Work with the IESG and tools team on ways to connect implemen= ters and communities that develop and maintain protocols, both while a wo= rking group is active, and after a working group has concluded its charte= r. >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 From nobody Mon Jul 6 15:20:37 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7061B3A0B9B for ; Mon, 6 Jul 2020 15:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 MslxuG2sGGsz for ; Mon, 6 Jul 2020 15:20:27 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB613A0BAE for ; Mon, 6 Jul 2020 15:20:26 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A2783548442; Tue, 7 Jul 2020 00:20:20 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9C302440043; Tue, 7 Jul 2020 00:20:20 +0200 (CEST) Date: Tue, 7 Jul 2020 00:20:20 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Tommy Pauly , "architecture-discuss@iab.org" , warren@kumari.net Message-ID: <20200706222020.GP13952@faui48f.informatik.uni-erlangen.de> References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 22:20:36 -0000 Brian: I thought to remember tht Warren mentioned last year some interest in new processes for "living documents" primarily in OPS. Have not tracked enough mailing lists to know if/what is happening (if anything), but i agree that those different type of document lifecycle models would be crucial to tackle the topics proposed. But i think it would be perfect to simply learn by doing, and not bother too much about FIRST working out the document structure and THEN commit the payload. Aka: this could be a good set of topics for a living-document-hackathon. Cheers Toerless On Tue, Jul 07, 2020 at 10:05:52AM +1200, Brian E Carpenter wrote: > Tommy, > > A good topic. But there's an elephant in the corner of the room and I'm not sure you can ignore it. The same elephant is in the corner of the room where we're discussing the future role of the RFC Series Editor, although I've argued that it shouldn't be there because it's an IETF problem. > > To what extent is the standards process itself the enemy of Evolvability, Deployability, and Maintainability? In particular, does the way we handle document revisions and interdependencies make it harder for implementors and operators do decide which features to implement and deploy? Why don't we issue many more of what RFC2026 calls "applicability statements"? Why don't we issue living documents that define which documents are part of a particular standard at a particular time? > > It's not that we've never done this to some extent. RFC4294->RFC6434->RFC8504 is an example, but only 3 versions over 13 years is grossly inadequate. An update every 6 months might have been more appropriate. > > SMTP has been the classical example for many years, and I suspect that RTCWEB might furnish another good example of this problem before long. > > Regards > Brian Carpenter > > On 07-Jul-20 07:01, Tommy Pauly wrote: > > The IAB is considering starting a new program that would look at the Evolvability, Deployability, and Maintainability of Internet protocols. The description of the program is included at the bottom of this email. > > > > We???d like to get feedback on the proposed program topic and description. We???ll be considering this over the next few weeks, and your thoughts and input are welcome! > > > > Best, > > Tommy > > > > ====== > > > > Evolvability, Deployability, & Maintainability (EDM) Program > > > > 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. > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Mon Jul 6 18:14:16 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003783A0831 for ; Mon, 6 Jul 2020 18:14:14 -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, 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 (1024-bit key) header.d=cs.tcd.ie 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 XiXqz-C2xX5g for ; Mon, 6 Jul 2020 18:14:13 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5AA33A082C for ; Mon, 6 Jul 2020 18:14:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9FBD0BE2C; Tue, 7 Jul 2020 02:14:10 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xvFmJo1ho7u; Tue, 7 Jul 2020 02:14:04 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C9D8FBE1C; Tue, 7 Jul 2020 02:14:03 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1594084444; bh=N/GocLudnj8a6C6WocVOaGEnYQECHDU1ct9qTG2eP4E=; h=Subject:To:References:From:Date:In-Reply-To:From; b=gl4retBd14m5RBJ99HRecKwU9ei7VTTBCXh+fNdlmeTBeklsBUEp+ZzMtXkgDcC0N noWKOCp7Qo90DIPYRL2v6Hj70BA2LkKpe6qxZxiFluSqly5kgIyLekrn8LYT4Os2Sj zsDkUFwWOGQ3CNlBT8oBCSHELrZQiSXjWEMg7wsE= To: Brian E Carpenter , Tommy Pauly , "architecture-discuss@iab.org" References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <393e63e8-85db-755b-4e11-509670ed6332@cs.tcd.ie> Date: Tue, 7 Jul 2020 02:14:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kSeFJb3RwHvyL5mbYytPJqoeWhvIJdYc0" Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 01:14:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kSeFJb3RwHvyL5mbYytPJqoeWhvIJdYc0 Content-Type: multipart/mixed; boundary="A9Ly1zY8NK061QMHThdhoKH4AFZnjtnGc"; protected-headers="v1" From: Stephen Farrell To: Brian E Carpenter , Tommy Pauly , "architecture-discuss@iab.org" Message-ID: <393e63e8-85db-755b-4e11-509670ed6332@cs.tcd.ie> Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability. References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> In-Reply-To: --A9Ly1zY8NK061QMHThdhoKH4AFZnjtnGc Content-Type: multipart/mixed; boundary="------------57B7D8DDAF1E92BADB81B080" Content-Language: en-US This is a multi-part message in MIME format. --------------57B7D8DDAF1E92BADB81B080 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Brian, (Maybe not directly a question for you but...) On 06/07/2020 23:05, Brian E Carpenter wrote: > SMTP has been the classical example for many years, and I suspect > that RTCWEB might furnish another good example of this problem before > long. Do we have evidence as to the (good, bad or neutral) impact of the stately pace of the evolution of email standards- track RFCs? I could imagine the net effect being overall positive or negative but am unsure which may be the case. I suspect it may be more likely that the actual impact is not correlated with RFC numbers at all, but that may also be wrong. Cheers, S. --------------57B7D8DDAF1E92BADB81B080 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------57B7D8DDAF1E92BADB81B080-- --A9Ly1zY8NK061QMHThdhoKH4AFZnjtnGc-- --kSeFJb3RwHvyL5mbYytPJqoeWhvIJdYc0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl8DzFsACgkQWrL68XsX K+r8KhAA00ja0p2VQUPpN1XD6pXK5DqKS6i+/w/favXEKeP43JQA3K5iKQVbr3WX KfmIzrYMCn+Rq8uWJp1zXopHdGBDFW09TjqnuXQKvPGAMSN8mFDR2sH53y42Y/B5 bky4zvofcCTvNd7E/LyMQwgdmGEKbrE2YX1SnN9ix2JxoAuZpk2N/VRrO/15BLyk ngcCTLSRYisrmYbLbv+/FUwON2wEkLhlA4hcfGDqs5a8hUU5KTW8thzPVoSueflF ubYcXPMbP7qV73Jiy9M9H4cTEETx0SNF7D1CMw+IRaVQSpHqqGz9mbDYjoXfKW/q iDk9+u1irSpj5SWhK6hzFsRPWXPbXpnbH2mTm5Vc84qQSn8+9lVytLFAtUXdDiKC PkmC0ZFSNJm/u0w6KIosRmgo8PeYkopISxSSPuQyeuaW44Tvg9akcMUy9iGFcEQQ Akqp8Yc/pHaveFhXp6pnvPZA8HYhrJ/X0/3xK2ER/63qriBYsrLfifWGlxo98BX7 G+9BoiPhjY9gDnejmBoQRVnYnM6mvtFYgovI+XAGRDTgIHEqfIGEDdtTgXszA9TN W/34H/sq4zdl67le8nXxTkSXVbh3Wc34Gr0n8e+cxoyCM3H+onMd7kVAuCHuaMYu 2dBa7vKtHf0+UcQ0wxUJ9lsdbi5ri1yyaqm9T7ohfvPMuJdUpQ0= =Vmy5 -----END PGP SIGNATURE----- --kSeFJb3RwHvyL5mbYytPJqoeWhvIJdYc0-- From nobody Mon Jul 6 20:37:07 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B813A09F0 for ; Mon, 6 Jul 2020 20:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQIxlk-fk6AC for ; Mon, 6 Jul 2020 20:37:04 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 5C55C3A09F2 for ; Mon, 6 Jul 2020 20:37:04 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id k71so14171724pje.0 for ; Mon, 06 Jul 2020 20:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=5rJ22JWSaQ0CFrGDFrl/kI22AzZHEbBCZ5CjpJz2cO0=; b=YDoA8O6uV5va7VgpJjslT71M6CT/+REc6jwmCHf84ua5k5LU7Y27rea5yyk3p1Dxfw O0OLauppxeojukiRFw25X6+yIl//0U7wlDldZdigXDeWhE4kbOsMSY767y9yHdeFuIZL oJhhDydvk0zY0ZCWO8C2S24542WQvHRBIjDM//xxl7gOh4vxcZ7XOutgi8v/Q5Q7HIlY dpdGnyHccwnFy3bgtIzDS1ZrxtHmu9E8PW+pn64noQIcdFg9vpV/x8Ax1o/VsXkpf3gh 47sgRCuRpDjU3d1vmTq/KTUydJRYtS70b5Pw34txMeYdSmcJNz3a6BQn6f9fw0xY3a/D qptA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5rJ22JWSaQ0CFrGDFrl/kI22AzZHEbBCZ5CjpJz2cO0=; b=VVYF4/bpiVa9toy2FDLjO766plGgH2WOddEdZIimDZwbWAlO5O6RsDJt/dNqQtLveF nLxojpuUnWF/ow+vnwwJ/70hl4OdZScXktmS9h7FKN/tpKj23k7vNthb8amfwsOMbs76 91igVgWjer7UJr67wHz8OZE6R/KGkpHTiuHJMV/5QexzLK2dSH+nDceWOckNjRxW4z6x IikCnCMvrMSXrmUYzzackNtteTKfx1qO7Vtx+HTg4kY5LC9IPuTcum+rc9geGAYEff5I q/YUebQmSOTgTg6UtaYWkJp+WDIRl+Y3D3vno+IHQz9UTJmhQFGCMPWLCTAO1jn9Uqvv tncA== X-Gm-Message-State: AOAM531cY3aM8aLjnFk2wtUzkdlCx/Y7GTOnI8UOOFnrvgeG5jEgYOw/ 1QLTcO2W9evUr5KjdfLis0ZybcT3 X-Google-Smtp-Source: ABdhPJyoEKGsB5btrate8HiDp1XB/2UMi3KodIFRvSTzl6uJ1vVourQK0k4HYRW5cukXJr1VGgSaEQ== X-Received: by 2002:a17:90a:8a07:: with SMTP id w7mr2196745pjn.219.1594093023519; Mon, 06 Jul 2020 20:37:03 -0700 (PDT) Received: from [192.168.178.20] ([151.210.129.236]) by smtp.gmail.com with ESMTPSA id f15sm21151405pfk.58.2020.07.06.20.37.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2020 20:37:02 -0700 (PDT) To: Stephen Farrell , Tommy Pauly , "architecture-discuss@iab.org" References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> <393e63e8-85db-755b-4e11-509670ed6332@cs.tcd.ie> From: Brian E Carpenter Message-ID: Date: Tue, 7 Jul 2020 15:36:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <393e63e8-85db-755b-4e11-509670ed6332@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 03:37:06 -0000 On 07-Jul-20 13:14, Stephen Farrell wrote: > > Hi Brian, > > (Maybe not directly a question for you but...) No, there are many people more qualified to answer than me for the SMTP case. I'm pretty sure IPv6 would have gone more smoothly with 6-monthly issues of "Node Requirements", though. There are too many interlocking pieces and developers were left to make their own choices. Brian > > On 06/07/2020 23:05, Brian E Carpenter wrote: >> SMTP has been the classical example for many years, and I suspect >> that RTCWEB might furnish another good example of this problem before >> long. > Do we have evidence as to the (good, bad or neutral) impact > of the stately pace of the evolution of email standards- > track RFCs? I could imagine the net effect being overall > positive or negative but am unsure which may be the case. I > suspect it may be more likely that the actual impact is not > correlated with RFC numbers at all, but that may also be > wrong. > > Cheers, > S. > From nobody Mon Jul 6 20:53:58 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841D23A003B for ; Mon, 6 Jul 2020 20:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=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 (1024-bit key) header.d=joelhalpern.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 8mC5DGlkosrY for ; Mon, 6 Jul 2020 20:53:56 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 412083A0039 for ; Mon, 6 Jul 2020 20:53:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4B17pX09PQz6G8Vq; Mon, 6 Jul 2020 20:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1594094036; bh=Y+ch6x9yvtvaPTMK0gkbJPQ9N/Av65AzQUzTm/xzweo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=UaYjJsyYCo2ddI4iHbRmi+NBoRlbNjSFPldSIEtBnxJ/IDIFyNJ5ue8fHloBadSpL v3BZARIE6BaX8eitPaBy0kvFpyqHAo+wq3kjABXrzokMXsMtKlgBn4jPxse/SNkzXI XG+h7bOsYycW7nmmeI59YXAOJci7dvAIwTqbHHQ0= X-Quarantine-ID: <596sJssUA3-1> X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4B17pW3khFz6G8Vr; Mon, 6 Jul 2020 20:53:55 -0700 (PDT) To: Brian E Carpenter , "architecture-discuss@iab.org" References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> <393e63e8-85db-755b-4e11-509670ed6332@cs.tcd.ie> From: "Joel M. Halpern" Message-ID: <120729a2-b610-c61e-9f12-df1e859add74@joelhalpern.com> Date: Mon, 6 Jul 2020 23:53:54 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 03:53:58 -0000 Brian, I doubt that we could have reached anything resembling rough consensus on changes (to IPv6) every six months. I suspect (although this is very much a subjective guess) that focusing on such six-monthly deliverables would have made it even harder to get agreement on the hard issues that did finally get addressed (however badly) in the revision. Yours, Joel On 7/6/2020 11:36 PM, Brian E Carpenter wrote: > On 07-Jul-20 13:14, Stephen Farrell wrote: >> >> Hi Brian, >> >> (Maybe not directly a question for you but...) > > No, there are many people more qualified to answer than me for the SMTP > case. I'm pretty sure IPv6 would have gone more smoothly with 6-monthly > issues of "Node Requirements", though. There are too many interlocking > pieces and developers were left to make their own choices. > > Brian > >> >> On 06/07/2020 23:05, Brian E Carpenter wrote: >>> SMTP has been the classical example for many years, and I suspect >>> that RTCWEB might furnish another good example of this problem before >>> long. >> Do we have evidence as to the (good, bad or neutral) impact >> of the stately pace of the evolution of email standards- >> track RFCs? I could imagine the net effect being overall >> positive or negative but am unsure which may be the case. I >> suspect it may be more likely that the actual impact is not >> correlated with RFC numbers at all, but that may also be >> wrong. >> >> Cheers, >> S. >> > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > From nobody Mon Jul 6 21:26:28 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F683A0789 for ; Mon, 6 Jul 2020 21:26:27 -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, FREEMAIL_FROM=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 7OZJBnFaort4 for ; Mon, 6 Jul 2020 21:26:26 -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 0212F3A078A for ; Mon, 6 Jul 2020 21:26:25 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id j19so12536908pgm.11 for ; Mon, 06 Jul 2020 21:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=8OD5fgqEmwFCtF/oKaJ6EQZz54HoiW2LO/G/9swLo6U=; b=ZjwocT9VtRePBXDXUao0rEMFRKMYAwPtOPOZBH70T4Bz6VevQ/esYbFtdmyjNOyOdE B6C4gAjo3af4Vxu4Br/tuuBv9Qfnv4/Eu0rrSLinhaxqUaA1yM0cmWNH++iqxT6IJjmt 1DZemwa55wVVcQHK4a9E/nCqy3rfQ4Otj5Y3fxkCjkcy6Nsnau85q4gFc8RwqJNVd75T b0ds/sfwXNYL0dd7HqDAJs0ATQCna8FijByJW5hD6AmD9GlypvmVqF5J36pWYLz3nN0+ FcUtd1Dpw2reQaJAbKGikFlzcazzzgxT9QhZezJLujWEqVhfyqFVXGO5PMMADZ598B32 2pNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8OD5fgqEmwFCtF/oKaJ6EQZz54HoiW2LO/G/9swLo6U=; b=RI8dCnFTwoQHSw8ncA1kTm5TFj1jfvsKYtF3pQG0qKkoc80ImA1uL08W1jM5j7806U pYOarWwbAAjmuzrib7csHmasT4pKeKWNT3WO+nloiEkX61WJoKuUbnNDKcbuYWlEijFh swnAQukb1eAMmwQa4mNW0C2wog6DJVyv5osAv7zC0+IuhVDbo9EiWuk3+dhCPRHaVCli NBe4TtkuDjG0PTzZZr9tKBL3bHu8HIV64YPkLUzzHu2WrsPRekSgrplYKyu/+s8Y32XV zIpLwNGH85lPzcqIzQqTlu4Y+LbCNLq54Of+Z+IUV5DTRL3n4QuS3frmd2GALxnEHjWO 1M8A== X-Gm-Message-State: AOAM5319hpUhd+jU9y2ynOaNu6/rV3r0JhK1YyD9K8V4HeA0o3sIrCMq WrTjkpYin7xtNgrVdyr27/LR5oi6 X-Google-Smtp-Source: ABdhPJw8JwcOHW/u+ibSu9u5bsSFcZev411Lhi/0M6j9Hhoe9L9NLKSxl8KnI89JIm4Hnkb3Y9H6cg== X-Received: by 2002:a62:8608:: with SMTP id x8mr45212189pfd.96.1594095984927; Mon, 06 Jul 2020 21:26:24 -0700 (PDT) Received: from [192.168.178.20] ([151.210.129.236]) by smtp.gmail.com with ESMTPSA id o42sm970395pje.10.2020.07.06.21.26.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2020 21:26:24 -0700 (PDT) To: "Joel M. Halpern" , "architecture-discuss@iab.org" References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> <393e63e8-85db-755b-4e11-509670ed6332@cs.tcd.ie> <120729a2-b610-c61e-9f12-df1e859add74@joelhalpern.com> From: Brian E Carpenter Message-ID: <949cea35-51d5-ece2-a875-5c01f686dce3@gmail.com> Date: Tue, 7 Jul 2020 16:26:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <120729a2-b610-c61e-9f12-df1e859add74@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 04:26:27 -0000 On 07-Jul-20 15:53, Joel M. Halpern wrote: > Brian, I doubt that we could have reached anything resembling rough > consensus on changes (to IPv6) every six months. I suspect (although > this is very much a subjective guess) that focusing on such six-monthly > deliverables would have made it even harder to get agreement on the hard > issues that did finally get addressed (however badly) in the revision. Well yes, it would have been extra work and six-monthly might be too ambitious, but once every 6.5 years was definitely too little. The underlying issue is that we don't have a mechanism for this at all, so either people make one up (like Router Requirements, which also seems to be a little out of date), or we leave implementors and operators on their own with a heap of RFCs. Regards Brian > > Yours, > Joel > > On 7/6/2020 11:36 PM, Brian E Carpenter wrote: >> On 07-Jul-20 13:14, Stephen Farrell wrote: >>> >>> Hi Brian, >>> >>> (Maybe not directly a question for you but...) >> >> No, there are many people more qualified to answer than me for the SMTP >> case. I'm pretty sure IPv6 would have gone more smoothly with 6-monthly >> issues of "Node Requirements", though. There are too many interlocking >> pieces and developers were left to make their own choices. >> >> Brian >> >>> >>> On 06/07/2020 23:05, Brian E Carpenter wrote: >>>> SMTP has been the classical example for many years, and I suspect >>>> that RTCWEB might furnish another good example of this problem before >>>> long. >>> Do we have evidence as to the (good, bad or neutral) impact >>> of the stately pace of the evolution of email standards- >>> track RFCs? I could imagine the net effect being overall >>> positive or negative but am unsure which may be the case. I >>> suspect it may be more likely that the actual impact is not >>> correlated with RFC numbers at all, but that may also be >>> wrong. >>> >>> Cheers, >>> S. >>> >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> > From nobody Mon Jul 6 21:28:05 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4213A078A for ; Mon, 6 Jul 2020 21:28:03 -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_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=lowentropy.net header.b=UpOksEvQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SWxeKTYp 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 Q_olZ_F30_9u for ; Mon, 6 Jul 2020 21:28:02 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5B8F3A0789 for ; Mon, 6 Jul 2020 21:28:02 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id F03305C00A8 for ; Tue, 7 Jul 2020 00:28:01 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 07 Jul 2020 00:28:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=hJYm+qg+kkyP7HbN4VJ8O+P4kJ6t+QC xc8j1tMzYZc4=; b=UpOksEvQvzXh3MJew6RJdTwmR8xiMTdONLcaH1TsgMmpLbK dFQYNQvsqWJkotAg2yb9GgDfgdqYfn8OEMhh25tYL/sduJaC51lag+1ovjbyoJGD Opuoys60ISgbWiNcCj+mjNFbfeDWXeslATmplJHCG+xeu8hXrJThSsPTMuxMePy7 CylQbSsVgM30MhjVML8S6po5BHTCzg9s+qWTN5gUdtmHc8wSVVHNVc/8JQWnO/0w L4ADaXArEtoW7GljrGJq+18TqU5SNyHDmQJweSr4TnAxsQZ1Ka/vAOpAxD82NTLs 5MoU1oelXfQqMUYWiy3umD4zQvSdCzOriXEcPYg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=hJYm+q g+kkyP7HbN4VJ8O+P4kJ6t+QCxc8j1tMzYZc4=; b=SWxeKTYpeRABqL9Z713kZQ LBs496NxIOgfl5xrAqOmBqJELBlH+yrbAmeHxX8irpnDzMpDXAKwk4JkI40OTA78 6Wbe9Gs9//SUwjjdep+UqmaeouQOen1mUUXEY6kxQYpaOZJhcHM4zhcwJnyuOG18 gkJ5jGd0qLJ1shSDo7Te95TRyb8L8k5VJpK+yXq3O6KwjJEGDpuVrKwcxPS14GbT 9fzLCaaRmnFX8SS5UCLYVIoFZYJvJgnz0Bwxzz58X3rVSn+U1k3vKlL9D6twg+jV 2RoYBGOdpURuWzHxPPMkiFIPbOMYmfubI88CNAwee14iKMiU7op+//Fr5zd31EBg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeggdekiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepheefteduudduhedtkefhvd fhteelffdujeegjeffheffveekudeigfeuveekfeelnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 90972E00B3; Tue, 7 Jul 2020 00:28:01 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> Date: Tue, 07 Jul 2020 14:27:40 +1000 From: "Martin Thomson" To: architecture-discuss@ietf.org Content-Type: text/plain Archived-At: Subject: [arch-d] =?utf-8?b?PT9VVEYtOD9RP1JlOl9fUHJvcG9zZWRfSUFCX3Byb2dy?= =?utf-8?q?am=3A=5FEvolvability=2C_=5FDeployability=3F=3D_=2C_=26_Maintain?= =?utf-8?q?ability=2E?= X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 04:28:04 -0000 Hi Tommy, This looks like a good initiative. If there is something the IAB can do to pave the way for multiple protocol communities, then that is good. There are commonalities in the problems we face, so collating different means of managing those problems is valuable. On Tue, Jul 7, 2020, at 08:05, Brian E Carpenter wrote: > To what extent is the standards process itself the enemy of > Evolvability, Deployability, and Maintainability? >From my perspective, this is a relevant question for such a program. But I don't see this program as having anything more than an input into other (parallel) work that examines this problem more closely. More concretely, if this group decides that publishing an RFC is anathema to a particular goal, that is information for others to consider, and a problem to engineer around for this group. This would seem to support the view that the IAB are well positioned to manage both processes :) From nobody Tue Jul 7 00:39:19 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC293A09B5 for ; Tue, 7 Jul 2020 00:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 DBWUXDCUbaBO for ; Tue, 7 Jul 2020 00:39:13 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id BED9D3A09B4 for ; Tue, 7 Jul 2020 00:39:04 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.204.255]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 0677co2o023739 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2020 00:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1594107543; x=1594193943; i=@elandsys.com; bh=aeLZjqd3o58l9Ypk20M5Y8S0Zo4GNsMzZ4lO/mgo+cw=; h=Date:To:From:Subject:In-Reply-To:References; b=XAIBTyMXW22/IWdmTBhq+i/5U0gspQeckWdT6jPyTEv9UzBQybFgjsboknkSY5ry/ jJu3T01dtVQRAtEVatHLDdRCRNc3NcJwfrsghBKd2v87QmX94AlQGxgd28jxQG+Gzb LaeSC++sD0FpFcIwD1iOY/82h/5l5WrSCxiR3Y6w= Message-Id: <6.2.5.6.2.20200706152350.0ace2bd8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 06 Jul 2020 16:18:36 -0700 To: Tommy Pauly , architecture-discuss@iab.org From: S Moonesamy In-Reply-To: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 07:39:17 -0000 Hi Tommy, At 12:01 PM 06-07-2020, Tommy Pauly wrote: >The IAB is considering starting a new program that would look at the >Evolvability, Deployability, and Maintainability of Internet >protocols. The description of the program is included at the bottom >of this email. > >We'd like to get feedback on the proposed program topic and >description. We'll be considering this over the next few weeks, and >your thoughts and input are welcome! One of the roles of the Internet Architecture Board (IAB) is to "provide oversight of the architecture for the protocols and procedures used by the Internet". It is not a good idea, in my opinion, to stray too far from that role by, for example, replicating the role of the Internet Engineering Steering Group (IESG) or being involved in matters which are not under its (RFC) policy authority. I doubt that it is possible to make "running code" part of the working group process unless "running code" is interpreted as implementing a specification as software-in-the-lab. In 2017, the IAB issued a response to FCC-17-89. It stated that "The IETF TRANS working group is nearing completion of work on a revision to Certificate Transparency". The work is still incomplete. Is setting up a program to tackle a people problem is not a good recipe for success? I suggest giving some thought to that. Regards, S. Moonesamy From nobody Tue Jul 7 08:47:55 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AB53A0EBC for ; Tue, 7 Jul 2020 08:47:54 -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 cNY3SeV6BmvW for ; Tue, 7 Jul 2020 08:47:52 -0700 (PDT) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 37FDC3A0EB2 for ; Tue, 7 Jul 2020 08:47:48 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 067FcD2n061853; Tue, 7 Jul 2020 08:47:41 -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=GvSx0CYG9U4044lRwuG9/KfCwol51YYfk3qY9fG2BPk=; b=i/zeMkeGHN/3HZODKKp5b2FCdnAWqX3tzkHBFw0BG/e2JagifIX2Dw85az0dqseKThC+ P3gzSFPDP+CVxzDPFbg11JiGgahQ9E6UM5UqxN7h82QPh3Y77g9ZNKX2ymPRQnr6OXgI bfFxNOd0U67r6qJ3m+9GJht63rtQa0+HoHHm76ttLxIrwBGYV1TMGKeisS6J33eeLo5H zjIL6IeuLlJXk4UmAzRPoF0WBx4WG9S5LLfosjSieGWz87oGOw0kXusDaIGGJtzQkfJc 68ftgUTKB7j5vWfzLIGtrzCDqo920sEiCo2tKDzc+0QQmVCCoCvKDrD1JvZtXTK2ajEz +Q== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by nwk-aaemail-lapp03.apple.com with ESMTP id 3239fpd45q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 07 Jul 2020 08:47:41 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QD300JWRVVGR740@rn-mailsvcp-mta-lapp04.rno.apple.com>; Tue, 07 Jul 2020 08:47:41 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QD300K00VP56Z00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 07 Jul 2020 08:47:41 -0700 (PDT) X-Va-A: X-Va-T-CD: b7d31c02c886c19cbc2b09bcac99d6f7 X-Va-E-CD: bcd61776ccdadbe608423dce34dca614 X-Va-R-CD: bac555b35f687522e43a301dfa6af0af X-Va-CD: 0 X-Va-ID: b325e389-abba-477d-82e6-f9f64a1718c2 X-V-A: X-V-T-CD: b7d31c02c886c19cbc2b09bcac99d6f7 X-V-E-CD: bcd61776ccdadbe608423dce34dca614 X-V-R-CD: bac555b35f687522e43a301dfa6af0af X-V-CD: 0 X-V-ID: 41685eef-f0a3-477b-a2f6-0e2e636b1667 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-07_08:2020-07-07, 2020-07-07 signatures=0 Received: from [17.235.29.10] (unknown [17.235.29.10]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QD300O3JVVFYD00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 07 Jul 2020 08:47:40 -0700 (PDT) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) From: Tommy Pauly In-reply-to: <20200706200133.GN13952@faui48f.informatik.uni-erlangen.de> Date: Tue, 07 Jul 2020 08:47:39 -0700 Cc: "architecture-discuss@iab.org" Content-transfer-encoding: quoted-printable Message-id: References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> <20200706200133.GN13952@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert 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-07-07_08:2020-07-07, 2020-07-07 signatures=0 Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 15:47:54 -0000 Hi Toerless, > On Jul 6, 2020, at 1:01 PM, Toerless Eckert wrote: >=20 > Thanks, Tommy, >=20 > inline >=20 > On Mon, Jul 06, 2020 at 12:01:58PM -0700, Tommy Pauly wrote: >> The IAB is considering starting a new program that would look at the = Evolvability, Deployability, and Maintainability of Internet protocols. = The description of the program is included at the bottom of this email. >=20 > Std toerless rant#1: The Internet is the 10% above waterline of the = iceberg which is IETF protocols. Please do not ignore the remaining = other 90% of "private network" use. Maybe use term "ITF protocols" or = something similar to make it clear whether you want to target 10% or = 100% (or anything in between). Sure! =E2=80=9CIETF protocols=E2=80=9D can be used here=E2=80=94or = perhaps just =E2=80=9Cnetworking protocols=E2=80=9D. This should be = inclusive. >=20 >> We???d like to get feedback on the proposed program topic and = description. We???ll be considering this over the next few weeks, and = your thoughts and input are welcome! >>=20 >> Best, >> Tommy >>=20 >> =3D=3D=3D=3D=3D=3D >>=20 >> Evolvability, Deployability, & Maintainability (EDM) Program >>=20 >> 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. >>=20 >> The topics this group will consider include: >>=20 >> 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. >=20 > I would like to see the work item point: > "IESG safe documentation of extension point / behavior / possible = benefits" >=20 > Explanation: i had a painfull IESG review of a draft of mine where we = used > a simple terminology at the end of sections saying things like=20 >=20 > "future work may ". >=20 > The IESG review feedback (primarily from GEN) was that this draft = looked > unfinished and should not be standardized because of the repeated use = of the > term "future work". I had to remove all of this text, partially = putting > things into non-normative appendices, etc.. pp. >=20 > In later IESG review i had to add some notes about future work with = this > terminology,=20 >=20 > Now it is impossible (like in IMHO all other RFC) to easily find = extension > point documentation in my draft consistently. >=20 > At the risk of getting into a similar endless debate as Mirja's good = intentioned > update to "update", maybe there could be terminology like "FUTURE" = that > allows to formally show / explain extension points. Or anything else = to > easier document them through the IESG review process. This is a useful point to bring up. I think discussing ways of = highlighting extension points, either via standard text in documents, or = by highlighting in a registry like IANA, would be a valuable tool to = have across protocols. >=20 >> 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. >=20 > I think you are listing what likely are the key issues for = application/software > centric issues with deployability (down to at most host-stack). >=20 > For deployability on network "equipment", router/switches/gateways = with > hardware accelerated forwarding and other processing planes, there > are additional considerations IMHO most important for this space: Yes, this language is a bit focused on end-hosts, but analogous = considerations for routers, etc, would be good to include. >=20 > Models for internal behavior of forwarding/control-plane against which = to > assess behavior/scalability/cost of proposed protocols (amount of = state, > complexity of QoS / packet processing),.. Architecture direction to = evolve > these type of protocol devices into a more "software centric" model. >=20 > For example, it took about a decade in my memory before IETF would = even > include terms like RIB or FIB into routing area protocol RC because > "dogmatic" IETF persons did reject them in before as something not > externally visible and hence irrelevant to interop behavior. >=20 > We had last year a session to talk about router forwarding planes = where > a bit of this was touched, but we never followed up with any = documentation > in form of BCPs and the like. Obviously this is a lot of work, but > IMHO well worth it if not required for future evolution. >=20 > For example 2: I still have ongoing discussions with IESG about the = validity > of internal interfaces between SW components in routers in standards = track > documents, because it supposedly does not impact interoperability = (between > devices), and the mere thought that these software components could be > from different vendors has not entered the mindset of most IESG people = working > with routers. >=20 >> 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. >=20 > Definitely, but... (see below) >=20 >> 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. >=20 > This would all be great work to do if it was not executed ONLY via a = current > IAB program. This is too important work to be subject to the whim of > IAB member interest. Its not maintaineable if its only done via an > IAB program. >=20 > IMHO, this should be an IAB AG (architecture group) that has IAB > members (like IESG members) as sponsors and creators, but which has > AG chairs running a standard RG/WG process, that can persist beyond > the terms of individual IAB members interests, and that isn't subject > to all the other issues i have with IAB processes. >=20 > Aka: No need to work on maintaineability if the process to work on > maintainability is not maintainable. The work of maintaining mechanisms here long-term probably doesn=E2=80=99t= belong in an IAB program or group, but rather as something that is run = by the IESG or a WG. This program could certainly recommend such a = function. Best, Tommy >=20 > Cheers > Toerless >=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 >=20 > --=20 > --- > tte@cs.fau.de From nobody Tue Jul 7 09:14:02 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E673A0EAE for ; Tue, 7 Jul 2020 09:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_H4=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 IKNck5w1lslQ for ; Tue, 7 Jul 2020 09:13:59 -0700 (PDT) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 3FBB23A0EEA for ; Tue, 7 Jul 2020 09:13:59 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 067GBoQs012760; Tue, 7 Jul 2020 09:13:58 -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=/DVS1Zx4hdzhlskvl8cQKcHOgTsnZopRU0pn8J3l0Sg=; b=Lfy2BvikfakSQtDIm5xDxdJzKCPCinfokRuXHJcKu4BXVKrt2mO5aqpl7TewgJZclcAR kKt9psSaObU2eI75C9vcjKniN7hRxw3R4XClcLrWrTnsnEFw2osLYNw1ZdKxfvh0B3qZ +VqNDIGgC0ikVbY/sbNUz69s5TDijQU/4uxButcynUf7mIsUB38/s7drZyeXVXbawxmv v4EfJMnJAmJD1pZ1BEfDuxL62gYGhwBEZ1tEZk+vgYwSOZL3c5++yieaOuzpv+H0fH2W 7J2e/B9eqmFPnl+A9bZ3g+NC7quZAbsHT/IJ/fJqxDi+/3FPlOlO5FsReVSKVa1Q8ARj eQ== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by nwk-aaemail-lapp02.apple.com with ESMTP id 322pbgpey4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 07 Jul 2020 09:13:58 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QD300PG8X36E540@rn-mailsvcp-mta-lapp03.rno.apple.com>; Tue, 07 Jul 2020 09:13:54 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QD300C00WWVIL00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 07 Jul 2020 09:13:54 -0700 (PDT) X-Va-A: X-Va-T-CD: 12fa274a8ac4bdea3545590c5a22954d X-Va-E-CD: bcd61776ccdadbe608423dce34dca614 X-Va-R-CD: bac555b35f687522e43a301dfa6af0af X-Va-CD: 0 X-Va-ID: b297e4e9-7c48-4e42-8e9f-cda9dc0643b7 X-V-A: X-V-T-CD: 12fa274a8ac4bdea3545590c5a22954d X-V-E-CD: bcd61776ccdadbe608423dce34dca614 X-V-R-CD: bac555b35f687522e43a301dfa6af0af X-V-CD: 0 X-V-ID: 4f3febc9-9f69-426a-9f71-f2f14495eeb3 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-07_09:2020-07-07, 2020-07-07 signatures=0 Received: from [17.235.29.10] (unknown [17.235.29.10]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QD3010FNX35U200@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 07 Jul 2020 09:13:54 -0700 (PDT) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) From: Tommy Pauly In-reply-to: Date: Tue, 07 Jul 2020 09:13:53 -0700 Cc: "architecture-discuss@iab.org" Content-transfer-encoding: quoted-printable Message-id: <9739A5CA-7EE4-4215-9A9C-50E375747AFE@apple.com> References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> To: Brian E Carpenter 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-07-07_09:2020-07-07, 2020-07-07 signatures=0 Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 16:14:01 -0000 Hi Brian, Thanks for your thoughts. I definitely do see the elephant there=E2=80=94b= ut I think there is some good work to do that may in time let us better = address the elephant. I think our processes around standards can, at times, be stumbling = blocks to these goals Evolvability, Deployability, and Maintainability. = That being said, I don=E2=80=99t think they are fundamentally at odds. = The RFC process we have works well for the pieces of work that need to = be carefully reviewed, and =E2=80=9Cset in stone=E2=80=9D. Having these = stable references is good. But, as you point out, that same process and = same format can be less conducive to the more =E2=80=9Cfluid=E2=80=9D = work we do, such as applicability statements, surveys of current = deployments, etc. I hope that discussions in this area can explore methods to complement = our RFCs, without requiring an overhaul such as adding RFC-series living = documents. For example, we already have choices when we set up IANA registries to = set a difficult bar (RFC required) or a very easy bar = (first-come-first-served). That kind of choice has a large impact on how = a protocol can develop and be used. I=E2=80=99ve also seen fantastic work being done in some working groups = to coordinate implementation testing and deployments, but this is ad-hoc = and not easily found from within IETF tools like datatracker. It may be that the discussions end up determining we need to update our = relationship with the RFC process, but I think we can also point to = successful ways to complement our standards documents with practices and = resources that make our protocols safer to evolve, easier to evolve, and = clearer to the community. Best, Tommy > On Jul 6, 2020, at 3:05 PM, Brian E Carpenter = wrote: >=20 > Tommy, >=20 > A good topic. But there's an elephant in the corner of the room and = I'm not sure you can ignore it. The same elephant is in the corner of = the room where we're discussing the future role of the RFC Series = Editor, although I've argued that it shouldn't be there because it's an = IETF problem. >=20 > To what extent is the standards process itself the enemy of = Evolvability, Deployability, and Maintainability? In particular, does = the way we handle document revisions and interdependencies make it = harder for implementors and operators do decide which features to = implement and deploy? Why don't we issue many more of what RFC2026 calls = "applicability statements"? Why don't we issue living documents that = define which documents are part of a particular standard at a particular = time? >=20 > It's not that we've never done this to some extent. = RFC4294->RFC6434->RFC8504 is an example, but only 3 versions over 13 = years is grossly inadequate. An update every 6 months might have been = more appropriate. >=20 > SMTP has been the classical example for many years, and I suspect that = RTCWEB might furnish another good example of this problem before long. >=20 > Regards > Brian Carpenter >=20 > On 07-Jul-20 07:01, Tommy Pauly wrote: >> The IAB is considering starting a new program that would look at the = Evolvability, Deployability, and Maintainability of Internet protocols. = The description of the program is included at the bottom of this email. >>=20 >> We=E2=80=99d like to get feedback on the proposed program topic and = description. We=E2=80=99ll be considering this over the next few weeks, = and your thoughts and input are welcome! >>=20 >> Best, >> Tommy >>=20 >> =3D=3D=3D=3D=3D=3D >>=20 >> Evolvability, Deployability, & Maintainability (EDM) Program >>=20 >> This program will focus on how to practically encourage best = practices within the IETF to ensure that the IETF=E2=80=99s 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. >>=20 >> The topics this group will consider include: >>=20 >> 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=E2=80=99t= 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. >>=20 >>=20 >> Deployability: Focus on how we make =E2=80=9Crunning code=E2=80=9D = 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. >>=20 >>=20 >> 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. >>=20 >>=20 >> The program will: >> =E2=80=A2 Engage with the IETF community and implementers outside of = the IETF to identity successes and problem areas, and collect ideas for = improvements. >> =E2=80=A2 Work with the IESG and directorates to determine how best = practices for evolvability can best be applied during IESG review and = IETF last call. >> =E2=80=A2 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. >>=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >>=20 >=20 From nobody Tue Jul 7 09:41:23 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13D63A08C6 for ; Tue, 7 Jul 2020 09:41:21 -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_H4=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 YMjDvO9kL_Fg for ; Tue, 7 Jul 2020 09:41:20 -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 08DD23A08D4 for ; Tue, 7 Jul 2020 09:41:19 -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 067GaPco055734; Tue, 7 Jul 2020 09:41:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=1ecgVNqCVgV4UIT8dpYlQhgFjZurcpwCIZT7M4Kwqzk=; b=klwhd24xAuA+K4MSJ3KoP7I4bxHavLSn5TOW7FdgnBim7S7WZaQjPv6xCwe6/YIqi5+p IucA8aghVuvmKK8OedBQf6By80LHAosxMxukIWJLrvoMXbDxEMMFdDosy5gJjQCyyECI df5YPScqMG3r4aQ39yA8dRbm5Hyc8hppSr050uagiDj4uhxQaREWhf65NZnGmR+THTyq N58SEr9FRTVftxH/p1o1Gtaqn1H3XAcAehUsVkgBNVrSJaIatuEte8GkDMglDq03wH6G YRgXv5bxTyGcx6dwOv5C2n8buBzsYRonGafAwoZyJch3fjR+I+hYypqY9GgwwV1L2wfA sA== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 322re2futm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 07 Jul 2020 09:41:05 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QD3005NUYCGPX50@rn-mailsvcp-mta-lapp03.rno.apple.com>; Tue, 07 Jul 2020 09:41:04 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QD300T00XX87H00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 07 Jul 2020 09:41:04 -0700 (PDT) X-Va-A: X-Va-T-CD: 9ef1c94aca2a985c968936d4baa34f4e X-Va-E-CD: e09119d25ab8b07de2747025f15c7ff3 X-Va-R-CD: 28b4ff53863a9a590a7a640f753ab2c8 X-Va-CD: 0 X-Va-ID: cc05fcc8-8ec4-4f5e-8ad1-606a0d5bf9ce X-V-A: X-V-T-CD: 9ef1c94aca2a985c968936d4baa34f4e X-V-E-CD: e09119d25ab8b07de2747025f15c7ff3 X-V-R-CD: 28b4ff53863a9a590a7a640f753ab2c8 X-V-CD: 0 X-V-ID: a7cce3ed-67d8-45ff-85c5-b349383244fd X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-07_09:2020-07-07, 2020-07-07 signatures=0 Received: from [17.235.29.10] (unknown [17.235.29.10]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QD300QG2YCEXP00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Tue, 07 Jul 2020 09:41:03 -0700 (PDT) From: Tommy Pauly Message-id: <97106DE6-5F23-4490-9271-8E397EEEAEC7@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_2953DA2D-91CB-44B3-A6F3-1C67E0DB82C4" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Tue, 07 Jul 2020 09:41:02 -0700 In-reply-to: <6.2.5.6.2.20200706152350.0ace2bd8@elandnews.com> Cc: architecture-discuss@iab.org To: S Moonesamy References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> <6.2.5.6.2.20200706152350.0ace2bd8@elandnews.com> 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-07-07_09:2020-07-07, 2020-07-07 signatures=0 Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 16:41:22 -0000 --Apple-Mail=_2953DA2D-91CB-44B3-A6F3-1C67E0DB82C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello S. Moonesamy, Thanks for expressing your concern. I want to assure you that this = program is not trying to replicate the role of the IESG or any working = group, but rather to help coordinate conversations with the IESG, = working groups, IETF community, and external communities. The specific = focus of these discussions is to look at how we can achieve the = architectural goals of an evolvable and maintainable protocol stack. The problems we are trying to address are indeed architectural: can we = avoid or mitigate the ossification of protocols? Can we promote the = reuse and extension of IETF protocols and avoid duplication and = non-interoperable proprietary solutions? However, the solution-space involves improving how protocols are = defined, how their extension points and allocation spaces are defined, = and how working groups communicate and engage with implementer = communities. The proposed program would include IESG members, tools team members, WG = chairs, implementers, etc. Those would be the bodies that actually enact = changes. The role of the IAB here is to organize the discussions and = highlight the impact on architecture. Here are some references to highlight how this organizational role is = indeed within the charter and role of the IAB: =E2=80=9C[The IAB] is also expected to play a role in assuring that the people responsible for evolving the Internet and its technology are aware of the essential elements of the Internet architecture.=E2=80= =9D (https://www.iab.org/about/charter/ = ) "The IAB also helps connect different fields of expertise when this is = needed to understand the full situation affecting the evolution of the = Internet.=E2=80=9D (https://www.iab.org/about/iab-overview/ = ) Best, Tommy > On Jul 6, 2020, at 4:18 PM, S Moonesamy wrote: >=20 > Hi Tommy, > At 12:01 PM 06-07-2020, Tommy Pauly wrote: >> The IAB is considering starting a new program that would look at the = Evolvability, Deployability, and Maintainability of Internet protocols. = The description of the program is included at the bottom of this email. >>=20 >> We'd like to get feedback on the proposed program topic and = description. We'll be considering this over the next few weeks, and your = thoughts and input are welcome! >=20 > One of the roles of the Internet Architecture Board (IAB) is to = "provide oversight of the architecture for the protocols and procedures = used by the Internet". It is not a good idea, in my opinion, to stray = too far from that role by, for example, replicating the role of the = Internet Engineering Steering Group (IESG) or being involved in matters = which are not under its (RFC) policy authority. >=20 > I doubt that it is possible to make "running code" part of the working = group process unless "running code" is interpreted as implementing a = specification as software-in-the-lab. >=20 > In 2017, the IAB issued a response to FCC-17-89. It stated that "The = IETF TRANS working group is nearing completion of work on a revision to = Certificate Transparency". The work is still incomplete. >=20 > Is setting up a program to tackle a people problem is not a good = recipe for success? I suggest giving some thought to that. >=20 > Regards, > S. Moonesamy =20 --Apple-Mail=_2953DA2D-91CB-44B3-A6F3-1C67E0DB82C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= S. Moonesamy,

Thanks = for expressing your concern. I want to assure you that this program is = not trying to replicate the role of the IESG or any working group, but = rather to help coordinate conversations with the IESG, working groups, = IETF community, and external communities. The specific focus of these = discussions is to look at how we can achieve the architectural goals of = an evolvable and maintainable protocol stack.

The problems we are trying to address = are indeed architectural: can we avoid or mitigate the ossification of = protocols? Can we promote the reuse and extension of IETF protocols and = avoid duplication and non-interoperable proprietary solutions?

However, the = solution-space involves improving how protocols are defined, how their = extension points and allocation spaces are defined, and how working = groups communicate and engage with implementer communities.

The proposed program = would include IESG members, tools team members, WG chairs, implementers, = etc. Those would be the bodies that actually enact changes. The role of = the IAB here is to organize the discussions and highlight the impact on = architecture.

Here are some references to highlight how this organizational = role is indeed within the charter and role of the IAB:

=E2=80=9C[The IAB] is = also expected to play a role in assuring that
  =  the people responsible for evolving the Internet and its = technology
   are aware of the essential = elements of the Internet architecture.=E2=80=9D
(https://www.iab.org/about/charter/)

"The IAB also helps = connect different fields of expertise when this is needed to understand = the full situation affecting the evolution of the Internet.=E2=80=9D = (https://www.iab.org/about/iab-overview/)

Best,
Tommy

On Jul 6, 2020, at 4:18 PM, S = Moonesamy <sm+ietf@elandsys.com> wrote:

Hi = Tommy,
At 12:01 PM 06-07-2020, Tommy Pauly wrote:
The IAB is considering = starting a new program that would look at the Evolvability, = Deployability, and Maintainability of Internet protocols. The = description of the program is included at the bottom of this email.

We'd like to get feedback on the proposed = program topic and description. We'll be considering this over the next = few weeks, and your thoughts and input are welcome!

One of the roles of the Internet = Architecture Board (IAB) is to "provide oversight of the architecture = for the protocols and procedures used by the Internet".  It is not = a good idea, in my opinion, to stray too far from that role by, for = example, replicating the role of the Internet Engineering Steering Group = (IESG) or being involved in matters which are not under its (RFC) policy = authority.

I doubt that it is possible to = make "running code" part of the working group process unless "running = code" is interpreted as implementing a specification as = software-in-the-lab.

In 2017, the IAB = issued a response to FCC-17-89.  It stated that "The IETF TRANS = working group is nearing completion of work on a revision to Certificate = Transparency".  The work is still incomplete.

Is setting up a program to tackle a people problem is not a = good recipe for success?  I suggest giving some thought to that.

Regards,
S. Moonesamy  

= --Apple-Mail=_2953DA2D-91CB-44B3-A6F3-1C67E0DB82C4-- From nobody Tue Jul 7 10:38:01 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696983A00DF for ; Tue, 7 Jul 2020 10:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 ZwBmteQzXtef for ; Tue, 7 Jul 2020 10:37:57 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8667D3A0062 for ; Tue, 7 Jul 2020 10:37:57 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 75CA5548442; Tue, 7 Jul 2020 19:37:52 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 6CF8B440043; Tue, 7 Jul 2020 19:37:52 +0200 (CEST) Date: Tue, 7 Jul 2020 19:37:52 +0200 From: Toerless Eckert To: Tommy Pauly Cc: "architecture-discuss@iab.org" Message-ID: <20200707173752.GC13952@faui48f.informatik.uni-erlangen.de> References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> <20200706200133.GN13952@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 17:37:59 -0000 On Tue, Jul 07, 2020 at 08:47:39AM -0700, Tommy Pauly wrote: > > For deployability on network "equipment", router/switches/gateways with > > hardware accelerated forwarding and other processing planes, there > > are additional considerations IMHO most important for this space: > > Yes, this language is a bit focused on end-hosts, but analogous considerations for routers, etc, would be good to include. Happy to help, let me know if/when you want to go refining text. > > This would all be great work to do if it was not executed ONLY via a current > > IAB program. This is too important work to be subject to the whim of > > IAB member interest. Its not maintaineable if its only done via an > > IAB program. > > > > IMHO, this should be an IAB AG (architecture group) that has IAB > > members (like IESG members) as sponsors and creators, but which has > > AG chairs running a standard RG/WG process, that can persist beyond > > the terms of individual IAB members interests, and that isn't subject > > to all the other issues i have with IAB processes. > > > > Aka: No need to work on maintaineability if the process to work on > > maintainability is not maintainable. > > The work of maintaining mechanisms here long-term probably doesn???t belong in an IAB program or group, but rather as something that is run by the IESG or a WG. This program could certainly recommend such a function. Well, this is a more generic criticism on my behalf on the structure and IAB processes: IETF WGs are not mean to work on long term architecture topics. thats for IAB. IRTF GGs are not mean to work on long term architecture topics. thats for IAB. Aka: Why are there no architecture groups equalling WG/RGs ? IMHO we clearly see limits to the current process of IAB programs, and IMHO RG/WGs working better. All the things you bring up ar goin to be long-term architecture work items, i just can't see this to work well within IAB programs and it does not belong into RG/WGs, we need AGs too IMHO Cheers Toerless From nobody Tue Jul 7 12:01:51 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B714B3A0BEE for ; Tue, 7 Jul 2020 12:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 GmwcJmkZ22oe for ; Tue, 7 Jul 2020 12:01:40 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB553A0A0B for ; Tue, 7 Jul 2020 12:01:25 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.204.255]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 067J19Ab022069 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2020 12:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1594148482; x=1594234882; i=@elandsys.com; bh=/90ZpJ7hOq+yXGEtEpIlJL7S+lvqETOXo0lsbnn6Vz4=; h=Date:To:From:Subject:In-Reply-To:References; b=13RqFItfFS1jJ8xIqIR31UZmmV2u/yFSrn7l3BEGzaa0k//wHGZNqPNuQMlYGwDHG X0NYMRcJvooystQfFBKgVzKx8+zsCkL+PF2/jsN43OFGIYHTFE4lXVfEtdoRymhhvi 1j+NFzQQ6xWu0wPBXjoLaCcy6KF4eBhYHyplJcU4= Message-Id: <6.2.5.6.2.20200707113659.0adc3eb8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 Jul 2020 11:59:22 -0700 To: Tommy Pauly , architecture-discuss@iab.org From: S Moonesamy In-Reply-To: <97106DE6-5F23-4490-9271-8E397EEEAEC7@apple.com> References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> <6.2.5.6.2.20200706152350.0ace2bd8@elandnews.com> <97106DE6-5F23-4490-9271-8E397EEEAEC7@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 19:01:49 -0000 Hi Tommy, Thanks for the response. I'll comment below. At 09:41 AM 07-07-2020, Tommy Pauly wrote: >Thanks for expressing your concern. I want to assure you that this >program is not trying to replicate the role of the IESG or any >working group, but rather to help coordinate conversations with the >IESG, working groups, IETF community, and external communities. The >specific focus of these discussions is to look at how we can achieve >the architectural goals of an evolvable and maintainable protocol stack. That may not be the intent of the IAB. However, that is what will happen as you (used in general terms) get in working group details. >The problems we are trying to address are indeed architectural: can >we avoid or mitigate the ossification of protocols? Can we promote >the reuse and extension of IETF protocols and avoid duplication and >non-interoperable proprietary solutions? Ok. >However, the solution-space involves improving how protocols are >defined, how their extension points and allocation spaces are >defined, and how working groups communicate and engage with >implementer communities. If you ask about that during a review (unrelated to the proposed program) you'll most likely get the "it's the consensus" or some other answer which does not explain the how. The implementers, with some exceptions, do not have much of a say in deployment. >The proposed program would include IESG members, tools team members, >WG chairs, implementers, etc. Those would be the bodies that >actually enact changes. The role of the IAB here is to organize the >discussions and highlight the impact on architecture. Ok. >Here are some references to highlight how this organizational role >is indeed within the charter and role of the IAB: > > "[The IAB] is also expected to play a role in assuring that > the people responsible for evolving the Internet and its technology > are aware of the essential elements of the Internet architecture." >(https://www.iab.org/about/charter/) > >"The IAB also helps connect different fields of expertise when this >is needed to understand the full situation affecting the evolution >of the Internet." >(https://www.iab.org/about/iab-overview/) Who are the people responsible for evolving the Internet? Regards, S. Moonesamy From nobody Wed Jul 8 06:26:54 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA88E3A0AEF for ; Wed, 8 Jul 2020 06:26:52 -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 rPejLlBJfBEa for ; Wed, 8 Jul 2020 06:26:50 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7F73A0AEC for ; Wed, 8 Jul 2020 06:26:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9271C6601B0 for ; Wed, 8 Jul 2020 16:26:49 +0300 (EEST) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSFwNm93n8hB for ; Wed, 8 Jul 2020 16:26:48 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 44985660166 for ; Wed, 8 Jul 2020 16:26:48 +0300 (EEST) From: Jari Arkko Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Wed, 8 Jul 2020 16:26:47 +0300 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [arch-d] Musings on Internet evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 13:26:53 -0000 Colin, Tommy, Alissa and me wrote some thoughts on COVID-19 impacts, = Internet evolution, and future challenges. See here: = http://www.circleid.com/posts/20200707-evolving-the-internet-through-covid= -19-and-beyond/ But what do you think? What do you think has fuelled evolution, what do = you see in store in these processes in the future, and what bigger = challenges do you think we face in the Internet? Do you see other = changes that functional aspects, e.g., about the way evolution happens? = (We=E2=80=99ve seen some movement from standards to open source-based = interoperability, for instance.) Jari From nobody Wed Jul 8 08:26:00 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E423A0DDC for ; Wed, 8 Jul 2020 08:25:58 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6JFYKbits7a for ; Wed, 8 Jul 2020 08:25:57 -0700 (PDT) Received: from mail.pch.net (keriomail.pch.net [206.220.231.84]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49B83A0DD7 for ; Wed, 8 Jul 2020 08:25:56 -0700 (PDT) X-Footer: cGNoLm5ldA== Received: from [10.19.48.14] ([69.166.14.2]) by mail.pch.net (Kerio Connect 9.2.7 patch 3) with ESMTPS (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Wed, 8 Jul 2020 08:25:54 -0700 From: Bill Woodcock Message-Id: <801C2DD7-9AD5-4486-8071-454CB9100A9D@pch.net> Content-Type: multipart/signed; boundary="Apple-Mail=_D4E4F3C8-B63F-458C-9FE8-77984ABD0CBF"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 8 Jul 2020 17:25:50 +0200 In-Reply-To: Cc: architecture-discuss@ietf.org To: Jari Arkko References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] Musings on Internet evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 15:25:58 -0000 --Apple-Mail=_D4E4F3C8-B63F-458C-9FE8-77984ABD0CBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 8, 2020, at 3:26 PM, Jari Arkko wrote: >=20 > Colin, Tommy, Alissa and me wrote some thoughts on COVID-19 impacts, = Internet evolution, and future challenges. See here: >=20 > = http://www.circleid.com/posts/20200707-evolving-the-internet-through-covid= -19-and-beyond/ >=20 > But what do you think? What do you think has fuelled evolution, what = do you see in store in these processes in the future, and what bigger = challenges do you think we face in the Internet? Do you see other = changes that functional aspects, e.g., about the way evolution happens? = (We=E2=80=99ve seen some movement from standards to open source-based = interoperability, for instance.) I assume you saw this: = http://www.oecd.org/coronavirus/policy-responses/keeping-the-internet-up-a= nd-running-in-times-of-crisis-4017c4c9/ We had quite a lot of expert input which didn=E2=80=99t make it into the = report, as well, which I can summarize, if people are interested. =46rom my point of view, I think the most interesting finding is that = this is the end of network-to-network (i.e. routed subnet) VPNs for = home-office situations. While that was supportable for a few = executives, it doesn=E2=80=99t work if most of your workforce is WFH. One of the big positives in the =E2=80=9Cnew normal=E2=80=9D has been = the democratization of Internet governance meetings=E2=80=A6 My = colleagues Sara Alamin and Ga=C3=ABl Hernandez have a brief article = coming out shortly on that topic. When meetings happen online, = they=E2=80=99re less dominated by people from countries which issue each = other travel visas and which have inexpensive and frequent air travel = between each other. That=E2=80=99s good news, in a = more-eyes-on-the-problem sense, and in a = design-that-works-better-for-everybody-works-better-for-everybody sense. The main conclusion I=E2=80=99ve been seeing people draw from the Zoom = situation is that we=E2=80=99ve passed some sort of tipping-point of = ridiculousness in the everything-as-a-service, in-the-cloud shitshow, = and that governments, particularly, need to get back to a point where = they=E2=80=99re capable of standing on their own feet and operating the = services they need, using code they=E2=80=99re familiar with. So, good = news for open-source and open-standards, if people pay attention to = that. -Bill --Apple-Mail=_D4E4F3C8-B63F-458C-9FE8-77984ABD0CBF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEm6XJ0FdpKWJHso4lb6RwSyiLf4cFAl8F5X4ACgkQb6RwSyiL f4f/QA/7B//hBO56NfXSplDhJCSB2/xdgoYcmocspGvQiZ1In2m0REnzY67FxH7q ZYW3lrXcUnGP2tPh9CQ/a0XcHgcxE6FFat+JjfEipYWyb6pCDGolY+aQv7Egk/ZD 8WfGs38psJB37Bt8ewZb9YVS/fesWgxaoKIDSfEKE10xxvuc4Rvg45SpKVeJ1htz ddxSNgZ7UbiUOyjjoTYf5AMK3heLoQdc2sI/l3NO/7JOz/aWiiY5ks0Itr7WCAFW vZUEQr0w7vRLJ/jUweKWxMPYSbA36zOCNluc5x9/WuRdGDfhOE/zBGMMsv2+uM5G FAa/CQ2+0VpqOo5HTeWbvcnPTR8DD6RT0WcpLezktOUZdDu3vhaMCRcnuR2Xvjr0 5cbS8aIS1fly2Pt5M5U8IS2oCi0TUdzD0Gb6n71fV/gvxnpVBATh1JSHFCZwe9Tw RxgyPULpeToPi5t9jN21iQGW7FuGoEPdJnRH974dboeHlWQwd42zyeRIz7dgjEV+ O2jAKFagAG/q11AvxPWvsN2X6TOSYdlWEEPKavIjnWfnhXzWwqLNmWul26so+C77 3q69AGOv5kYW9u/dZfnzz/Y9Yfx4OJR1evgKYlWeIiGyv0Uo4mZaxlQZwkn95WWD jU+Pjixzc/HnF0oM+Xm/oUTB9ExPjgo17tNZAvUTwYh51dqiwOc= =ADK5 -----END PGP SIGNATURE----- --Apple-Mail=_D4E4F3C8-B63F-458C-9FE8-77984ABD0CBF-- From nobody Wed Jul 8 09:41:50 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1551E3A0F3A for ; Wed, 8 Jul 2020 09:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=open-xchange.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 qYkE06M4gPr9 for ; Wed, 8 Jul 2020 09:41:47 -0700 (PDT) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 621A53A0F38 for ; Wed, 8 Jul 2020 09:41:46 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 334CC6A310; Wed, 8 Jul 2020 18:41:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1594226501; bh=6PqI6tdyiYmm21vcSzMcYnbfg46LS0rRC6ri3bPUAc0=; h=Date:From:To:In-Reply-To:References:Subject:From; b=Gs248U+lQWTcVnTUrafEqhTRBjRDZropBPB6FAZxCzN5LtoY6nS7BycjlZ0TaxWab nNbaVX4SYwDhTtbHPi/GqOxJ3pUzQATek9LS2FTk2md+zHB4CjIKyIyhtq70f4TeMX vMMWXVy1urabEQEaKhXmLL+X71sN3dLJ8+rFjNeAMHs7cWuaIqClp6UiGTZv1j4H6m hja7ktlIMsins2hj+Z9e8GZz+keRgNcaOdvGsWWriJbxRA1HGHL178o6m0tz/MGBSC Odw+Gi9HLvdXtwEHb/oxBu2mJlDmt2K1J34D4yImh9Xev+5uEEOHnnWjM+6yuAMOrC kH/o/h9gTHR+A== Received: from appsuite-dev-gw1.open-xchange.com (appsuite-dev-gw1.open-xchange.com [10.20.30.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 24AD73C0666; Wed, 8 Jul 2020 18:41:41 +0200 (CEST) Date: Wed, 8 Jul 2020 18:41:40 +0200 (CEST) From: Vittorio Bertola To: Jari Arkko , architecture-discuss@ietf.org Message-ID: <130601149.1026.1594226501049@appsuite-dev-gw1.open-xchange.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.4-Rev2 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [arch-d] Musings on Internet evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 16:41:49 -0000 > Il 08/07/2020 15:26 Jari Arkko ha scritto: >=20 > =20 > Colin, Tommy, Alissa and me wrote some thoughts on COVID-19 impacts, Inte= rnet evolution, and future challenges. See here: >=20 > http://www.circleid.com/posts/20200707-evolving-the-internet-through-covi= d-19-and-beyond/ >=20 > But what do you think? What do you think has fuelled evolution, what do y= ou see in store in these processes in the future, and what bigger challenge= s do you think we face in the Internet? Do you see other changes that funct= ional aspects, e.g., about the way evolution happens? (We=E2=80=99ve seen s= ome movement from standards to open source-based interoperability, for inst= ance.) Understandably, your article is focused on the ability of the Internet to c= ope with evolution at the technical level, which is excellent. But you seem= to miss the evolution at the societal level, where two big and interconnec= ted topics have emerged (at least in Europe) in the last 2-3 years: 1) centralization: in practice, much of the Internet is now decentralized t= echnically but centralized economically and in terms of control into the ha= nds of a few immense and unaccountable businesses;=20 2) digital sovereignty: how can national governments restore some degree of= non-negotiable control over the consequences that the Internet has on thei= r societies, and fulfill their strategic need for the Internet to continue = working even in the face of strained international relations. The last 2-3 decades were an age of globalization, but as the pendulum swin= gs and many social groups are increasingly unhappy, the next ones could aga= in be an age of nationalism. If so, the borderless technical nature of the = Internet could get increasingly strained by the attempts to counter #1 and = accomplish #2, if it failed to adapt to the new political climate. --=20 Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com=20 Office @ Via Treviso 12, 10144 Torino, Italy From nobody Wed Jul 8 14:24:24 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A713A003E for ; Wed, 8 Jul 2020 14:24:23 -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, 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 (1024-bit key) header.d=btinternet.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 xRQJ-ZZGekQy for ; Wed, 8 Jul 2020 14:24:17 -0700 (PDT) Received: from rgout0706.bt.lon5.cpcloud.co.uk (rgout0706.bt.lon5.cpcloud.co.uk [65.20.0.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDAB3A0044 for ; Wed, 8 Jul 2020 14:24:16 -0700 (PDT) X-OWM-Source-IP: 10.110.12.2 () X-OWM-Env-Sender: wjgo_10009@btinternet.com X-RazorGate-Vade-Classification: clean X-RazorGate-Vade-Verdict: clean 0 X-VadeSecure-score: verdict=clean score=0/300, class=clean X-SNCR-VADESECURE: CLEAN X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedrudejgdduieduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefvkfgjfhfugggtfghihfffsegrtdersgdtreejnecuhfhrohhmpedffihjghhopgdutddttdelsegsthhinhhtvghrnhgvthdrtghomhdfuceofihjghhopgdutddttdelsegsthhinhhtvghrnhgvthdrtghomheqnecuggftrfgrthhtvghrnhepffeluefhhfekkeeiveeiuedtkeegfeelkeegieegueeuvdelleegveekjeettefgnecuffhomhgrihhnpehglhhosggrlhhnvghtrdgtohdruhhkpdgtihhrtghlvghiugdrtghomhdpihgvthhfrdhorhhgnecukfhppedutddruddutddruddvrddvpdekiedrudeftddrudejuddrheehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepfigvsghmrghilhdtiedrsghtrdgvgihtrdgtphgtlhhouhgurdgtohdruhhkpdhinhgvthepuddtrdduuddtrdduvddrvddpmhgrihhlfhhrohhmpeeofihjghhopgdutddttdelsegsthhinhhtvghrnhgvthdrtghomheqpdhrtghpthhtohepoegrrhgthhhithgvtghtuhhrvgdqughishgtuhhsshesihgvthhfrdhorhhgqedprhgtphhtthhopeeojhgrrhhirdgrrhhkkhhosehpihhuhhgrrdhnvghtqedprhgt phhtthhopeeofihjghhopgdutddttdelsegsthhinhhtvghrnhgvthdrtghomheq Received: from webmail06.bt.ext.cpcloud.co.uk (10.110.12.2) by rgout07.bt.lon5.cpcloud.co.uk (9.0.019.26-1) (authenticated as wjgo_10009@btinternet.com) id 5C65093614731A19; Wed, 8 Jul 2020 22:24:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=btcpcloud; t=1594243456; bh=k4gaANLvDZ+LTNkP3WZ5D21wMbntp+YxjZqXZ7ksjR4=; h=To:Cc:Message-ID:In-Reply-To:References:Subject:MIME-Version:From:Date; b=gYSLukJOOUSSFhuMst3qqHMw3qkM8ij57LGsr0R/EvylJS6a5YqhkICgalonXOW3J3dkMWhGKjn8HlSa3BrV9gV9MRMiDzHm2ngi0aVpfp/VnnI47MYbhKHB4JiLGHhWrys9SKK/33GkieukJn0+Nx46vKCi6Dd/m2rQnLPAemw= Received: from [86.130.171.55] by ux.btmail.bt.com with HTTP; Wed, 8 Jul 2020 22:24:11 +0100 To: Jari Arkko , architecture-discuss@ietf.org Message-ID: <4d999e56.af2.17330508c84.Webtop.45@btinternet.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_21388_1287572986.1594243451962" User-Agent: OWM Mail 3 X-SID: 45 X-Originating-IP: [86.130.171.55] From: "wjgo_10009@btinternet.com" Date: Wed, 8 Jul 2020 22:24:11 +0100 (BST) Archived-At: Subject: Re: [arch-d] Musings on Internet evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2020 21:24:23 -0000 ------=_Part_21388_1287572986.1594243451962 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Would my research on localizable sentences be of any interest in=20 relation to this? It is open source. Originally intended for human to human communication through the=20 language barrier in some circumstances, it could also be used for human=20 to thing, thing to human, and thing to thing communication. http://www.users.globalnet.co.uk/~ngo/localizable_sentences_research.htm http://www.users.globalnet.co.uk/~ngo/ William Overington Wednesday 8 July 2020 ------ Original Message ------ From: "Jari Arkko" To: architecture-discuss@ietf.org Sent: Wednesday, 2020 Jul 8 At 14:26 Subject: [arch-d] Musings on Internet evolution Colin, Tommy, Alissa and me wrote some thoughts on COVID-19 impacts,=20 Internet evolution, and future challenges. See here: http://www.circleid.com/posts/20200707-evolving-the-internet-through-covid-= 19-and-beyond/=20 But what do you think? What do you think has fuelled evolution, what do=20 you see in store in these processes in the future, and what bigger=20 challenges do you think we face in the Internet? Do you see other=20 changes that functional aspects, e.g., about the way evolution happens?=20 (We=E2=80=99ve seen some movement from standards to open source-based=20 interoperability, for instance.) Jari _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www.ietf.org/mailman/listinfo/architecture-discuss=20 ------=_Part_21388_1287572986.1594243451962 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

<= br>

Would my research on localizable sentences be of any interest in = relation to this?


It is open source.


Orig= inally intended for human to human communication through the language barri= er in some circumstances, it could also be used for human to thing, thing t= o human, and thing to thing communication.


http://www.user= s.globalnet.co.uk/~ngo/localizable_sentences_research.htm


http://www.users.globalnet.co.uk/~ngo/


William Ove= rington


Wednesday 8 July 2020



=






= ------ Original Message ------
From: "Jari Arkko" <jari.ark= ko@piuha.net>
To: architecture-discuss@ietf.org
Sent: Wednesday, 2= 020 Jul 8 At 14:26
Subject: [arch-d] Musings on Internet evolution
Colin, Tommy, Alissa and me wrote some thoughts on COVID-19 impacts, Inte= rnet evolution, and future challenges. See here:



http://www.circleid.com/posts/2020070= 7-evolving-the-internet-through-covid-19-and-beyond/



B= ut what do you think? What do you think has fuelled evolution, what do you = see in store in these processes in the future, and what bigger challenges d= o you think we face in the Internet? Do you see other changes that function= al aspects, e.g., about the way evolution happens? (We=E2=80=99ve seen some= movement from standards to open source-based interoperability, for instanc= e.)



Jari



________________________________= _______________

Architecture-discuss mailing list

Architecture-discuss@ietf.org

<= a href=3D"https://www.ietf.org/mailman/listinfo/architecture-discuss" targe= t=3D"_blank">https://www.ietf.org/mailman/listinfo/architecture-discuss=

------=_Part_21388_1287572986.1594243451962-- From nobody Wed Jul 8 20:49:32 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BE03A0E94 for ; Wed, 8 Jul 2020 20:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 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, HTML_OBFUSCATE_10_20=0.093, 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 bJqKpoJAb3Ec for ; Wed, 8 Jul 2020 20:49:29 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::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 231723A0E8C for ; Wed, 8 Jul 2020 20:49:28 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id l63so768737oih.13 for ; Wed, 08 Jul 2020 20:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eQCVa2AFvOYe3MhDI7WaPOKLuSp5+BX5NsL4Tqdd5zo=; b=XIrgGGobootvJAdus2LQ8OYwA0ou9gNRBnTaMzkc0v3RNn5Bf/yLlzLzMxY5SBPWnP S+jtszAnhe3cixwK8AoWH852HwAhq3MPELRHj+awOq4s4G5HajMC55PwaSfcWrh1hE2G PIp8eY9qpqv7fYm4jxaD9D+TI38+swSwdhIYDqt0BK4wc3B8zGrnzQ2KG6sXx1pdYppE GawYgThHcBrkJExdsfyuRXARMjdIOTsnLyEW+G0mt0ya69YT6i25aMtTIZzq/R8ocMTJ m+Qt/XtHyBX1nHMj5qvMEIDK1P97XFhMlXw600lcwqzPHG6STnMze+gQDbUxXhpsObT5 E0Xw== 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=eQCVa2AFvOYe3MhDI7WaPOKLuSp5+BX5NsL4Tqdd5zo=; b=MJVAjKA15EjK4TaDHTPDTQxnKF4iQshNM/qVX4M5wVNRmfULkqQJ/jbCI68oG3AvOt VVkVyesH8ONdlLmtwmyX4EK/WKgA2E7j+DlJbXqmA8GrRD6oMcMUngDOjuKwTrN0dRK3 PQvXLvyEXTwjfazs+u6D2dW1bwgS985wVTyxjLNckQ91W4kIW2GWAf2Sm5xNE02w5606 Xj/h1DuV1BXqHRvlraY8Ti57cyspo2blYWzGh1+U7jLstecdyM2FdQN3lYwiQ+xYtaby z86pCkIFzE+KILi5mfsD/frBt6WFYnzAhcRaZwirs40UnpC50f9S97z4bABvvkHFS5/6 ZdGA== X-Gm-Message-State: AOAM531zygNQRN/aAXoEnylWQW09X8HuJwQ0Syqy0H6ZBU2l0780Izg8 1mYyvDqYVtmvtNQfNfQaExoCEh0xv6mMRCN+fphhMw== X-Google-Smtp-Source: ABdhPJwUeM/0V5PNZ6+zNAeyRWO67rbtObbG3qIxK0u9vKDegunzLhF/HGCQeTgOISu7qAMgiG/2lBh7MRKUUsEVOu4= X-Received: by 2002:aca:3c07:: with SMTP id j7mr3860874oia.143.1594266568059; Wed, 08 Jul 2020 20:49:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:6a46:0:0:0:0:0 with HTTP; Wed, 8 Jul 2020 20:49:27 -0700 (PDT) In-Reply-To: <801C2DD7-9AD5-4486-8071-454CB9100A9D@pch.net> References: <801C2DD7-9AD5-4486-8071-454CB9100A9D@pch.net> From: Guntur Wiseno Putra Date: Thu, 9 Jul 2020 10:49:27 +0700 Message-ID: To: Bill Woodcock Cc: Jari Arkko , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000776eb705a9fa1c5c" Archived-At: Subject: [arch-d] Musings on Internet evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 03:49:31 -0000 --000000000000776eb705a9fa1c5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Jarri, Bill & architecture-discuss, (Beside "emergency telecommunication" of which the Internet is to be part of in relation with "emergency response" to the pandemic Covid-19/Corona virus I mentioned in this architecture-discuss times ago https://mailarchive.ietf.org/arch/msg/architecture-discuss/thlgeoDJElb71D1j= jq4X9hKgyFU/ ,) it seems to be a way of evolvability/evolution --a typically collaborative one and at least a potential one as I imagine with no a careful reading-- the Internet take: how the Internet of Things inspires the Web of Things among which there is a concern with agriculture where there are initiatives on E-Agriculture considering "big data for disaster resilience" and "working and studying from home" while Research Data Alliance regarding with agriculture and the current global pandemic Covid-19/Corona virus. A thread at the Public-AgriW3C Community Group mailing list "WoT Collaboration" reflects that mind above: https://www.w3.org/mid/507fd4a3-896c-0310-b0ba-655513fcc24e@ affrc.go.jp;list=3Dpublic-agri To summarize, it is about initiatives: - The Web of Things for The Internet of Things (section Introduction of the document "WoT Architecture"); & the section 4.1.8. Agriculture https://www.w3.org/TR/2020/REC-wot-architecture-20200409/#agriculture - publications on E-Agriculture published by the International Telecommunication Union (ITU): https://www.itu.int/en/ITU-D/I CT-Applications/Pages/e-agriculture.aspx - (In relation with the current pandemic Covid 19, this may have such a relevance:) Case Study 1. "Big Data Ecosystem for Disaster Resilience" in "E-Agriculture in Action: Big Data for Agriculture" (ed. G. Sylvester, pp. 37-44) https://www.itu.int/en/ITU-D/ICT-Applications/Documents/Publ ications/Big%20Data%20for%20Agriculture.pdf - Research Data Alliance activities on fata engineering: "RDA Covid-19" and "agrisemantics" readings referring to the RDA also. https://www.rd-alliance.org/group/rda-covid19-rda-covid19-omics-rda-covid19= - epidemiology-rda-covid19-clinical-rda-covid19-0 https://www.rd-alliance.org/groups/agrisemantics-wg.html - (While there is the "Big Data for Disaster Resilience" mentioned above,) I finded this initiative on agriculture in times of home-based activities of which there was a relevance of the current pandemic Covid-19: "Working and Studying from Home? FAO Has A Lot to Share" http://www.fao.org/publications/highlights-detail/en/c/1269559/ Regard, Guntur Wiseno Putra Pada Rabu, 08 Juli 2020, Bill Woodcock menulis: > > > > On Jul 8, 2020, at 3:26 PM, Jari Arkko wrote: > > > > Colin, Tommy, Alissa and me wrote some thoughts on COVID-19 impacts, > Internet evolution, and future challenges. See here: > > > > http://www.circleid.com/posts/20200707-evolving-the-internet > -through-covid-19-and-beyond/ > > > > But what do you think? What do you think has fuelled evolution, what do > you see in store in these processes in the future, and what bigger > challenges do you think we face in the Internet? Do you see other changes > that functional aspects, e.g., about the way evolution happens? (We=E2=80= =99ve seen > some movement from standards to open source-based interoperability, for > instance.) > > I assume you saw this: http://www.oecd.org/coronavir > us/policy-responses/keeping-the-internet-up-and-running-in-t > imes-of-crisis-4017c4c9/ > > We had quite a lot of expert input which didn=E2=80=99t make it into the = report, > as well, which I can summarize, if people are interested. > > From my point of view, I think the most interesting finding is that this > is the end of network-to-network (i.e. routed subnet) VPNs for home-offic= e > situations. While that was supportable for a few executives, it doesn=E2= =80=99t > work if most of your workforce is WFH. > > One of the big positives in the =E2=80=9Cnew normal=E2=80=9D has been the= democratization > of Internet governance meetings=E2=80=A6 My colleagues Sara Alamin and G= a=C3=ABl > Hernandez have a brief article coming out shortly on that topic. When > meetings happen online, they=E2=80=99re less dominated by people from cou= ntries > which issue each other travel visas and which have inexpensive and freque= nt > air travel between each other. That=E2=80=99s good news, in a > more-eyes-on-the-problem sense, and in a design-that-works-better-for-e > verybody-works-better-for-everybody sense. > > The main conclusion I=E2=80=99ve been seeing people draw from the Zoom si= tuation > is that we=E2=80=99ve passed some sort of tipping-point of ridiculousness= in the > everything-as-a-service, in-the-cloud shitshow, and that governments, > particularly, need to get back to a point where they=E2=80=99re capable o= f standing > on their own feet and operating the services they need, using code they= =E2=80=99re > familiar with. So, good news for open-source and open-standards, if peop= le > pay attention to that. > > -Bill > > --000000000000776eb705a9fa1c5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Jarri, Bill &
architecture-discuss,

(Be= side "emergency telecommunication" of which the Internet is to be= part of in relation with "emergency response" to the pandemic Co= vid-19/Corona virus I mentioned in this architecture-discuss times ago


,) it seems to be a way of evolvability/evolution --a typi= cally collaborative one and at least a potential one as I imagine with no a= careful reading-- the Internet take: how the Internet of Things inspires t= he Web of Things among which there is a concern with agriculture where ther= e are initiatives on E-Agriculture considering "big data for disaster = resilience" and "working and studying from home" while Resea= rch Data Alliance regarding with agriculture and the current global pandemi= c Covid-19/Corona virus.

A thread at the Public-Ag= riW3C Community Group mailing list=C2=A0"WoT Collaboration" refle= cts that mind above:



To summarize, it is about initiatives:

=
- The Web of Things for The Internet of Things (section Introduction o= f the document "WoT Architecture"); & the section 4.1.8. Agri= culture https://www.w3.org/TR/2020/REC-wot-ar= chitecture-20200409/#agriculture=C2=A0

- = publications on E-Agriculture published by the International Telecommunicat= ion Union (ITU): https://www.itu.int/en/ITU-D/ICT-Applications/Pages/e-agriculture.aspx

- (In relation with the current pandemic Covid 19, this may have suc= h a relevance:)=C2=A0
Case Study 1. "Big Data Ecosystem for = Disaster Resilience" in "E-Agriculture in Action: Big Data for Ag= riculture" (ed. G. Sylvester, pp. 37-44) https://www.itu.int/en/ITU-D/ICT-Applica= tions/Documents/Publications/Big%20Data%20for%20Agriculture.pdf


https://www.rd-alliance.org/group/rda-covid19-rda-covid1= 9-omics-rda-covid19- epidemiology-rda-covid19-clinical-rda-co= vid19-0=C2=A0


- (While ther= e is the "Big Data for Disaster Resilience" mentioned above,) I f= inded this initiative on agriculture in times of home-based activities of w= hich there was a relevance of the current pandemic Covid-19: "Working = and Studying from Home? FAO Has A Lot to Share" htt= p://www.fao.org/publications/highlights-detail/en/c/1269559/= =C2=A0


Regard,=C2=A0
= Guntur Wiseno Putra

Pada Rabu, 08 Juli 2020, Bill Woodcock <woody@pch.net> menulis= :


> On Jul 8, 2020, at 3:26 PM, Jari Arkko <jari.arkko@piuha.net> wrote:
>
> Colin, Tommy, Alissa and me wrote some thoughts on COVID-19 impacts, I= nternet evolution, and future challenges. See here:
>
> http://www.circleid.com/p= osts/20200707-evolving-the-internet-through-covid-19-and-beyond/<= /a>
>
> But what do you think? What do you think has fuelled evolution, what d= o you see in store in these processes in the future, and what bigger challe= nges do you think we face in the Internet? Do you see other changes that fu= nctional aspects, e.g., about the way evolution happens? (We=E2=80=99ve see= n some movement from standards to open source-based interoperability, for i= nstance.)

I assume you saw this:=C2=A0 =C2=A0http://www.oecd.org/coronavirus/policy-re= sponses/keeping-the-internet-up-and-running-in-times-of-crisis-40= 17c4c9/

We had quite a lot of expert input which didn=E2=80=99t make it into the re= port, as well, which I can summarize, if people are interested.

>From my point of view, I think the most interesting finding is that this is= the end of network-to-network (i.e. routed subnet) VPNs for home-office si= tuations.=C2=A0 While that was supportable for a few executives, it doesn= =E2=80=99t work if most of your workforce is WFH.

One of the big positives in the =E2=80=9Cnew normal=E2=80=9D has been the d= emocratization of Internet governance meetings=E2=80=A6=C2=A0 My colleagues= Sara Alamin and Ga=C3=ABl Hernandez have a brief article coming out shortl= y on that topic.=C2=A0 When meetings happen online, they=E2=80=99re less do= minated by people from countries which issue each other travel visas and wh= ich have inexpensive and frequent air travel between each other.=C2=A0 That= =E2=80=99s good news, in a more-eyes-on-the-problem sense, and in a design-= that-works-better-for-everybody-works-better-for-everybody sense.=

The main conclusion I=E2=80=99ve been seeing people draw from the Zoom situ= ation is that we=E2=80=99ve passed some sort of tipping-point of ridiculous= ness in the everything-as-a-service, in-the-cloud shitshow, and that govern= ments, particularly, need to get back to a point where they=E2=80=99re capa= ble of standing on their own feet and operating the services they need, usi= ng code they=E2=80=99re familiar with.=C2=A0 So, good news for open-source = and open-standards, if people pay attention to that.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -Bill

--000000000000776eb705a9fa1c5c-- From nobody Thu Jul 9 01:02:23 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AF23A08A5 for ; Thu, 9 Jul 2020 01:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ablVDphM2pmU for ; Thu, 9 Jul 2020 01:02:18 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id E73DF3A089B for ; Thu, 9 Jul 2020 01:02:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 90C416601DA; Thu, 9 Jul 2020 11:02:16 +0300 (EEST) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxWiJJWUFz33; Thu, 9 Jul 2020 11:02:15 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 11799660166; Thu, 9 Jul 2020 11:02:15 +0300 (EEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C2ACC9BE-41E4-4DF2-8D48-EFE501FC178D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko X-Priority: 3 In-Reply-To: <130601149.1026.1594226501049@appsuite-dev-gw1.open-xchange.com> Date: Thu, 9 Jul 2020 11:02:14 +0300 Cc: architecture-discuss@ietf.org Message-Id: <1B50425D-6F59-42C9-A3AF-8A51FC769291@piuha.net> References: <130601149.1026.1594226501049@appsuite-dev-gw1.open-xchange.com> To: Vittorio Bertola X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [arch-d] Musings on Internet evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 08:02:21 -0000 --Apple-Mail=_C2ACC9BE-41E4-4DF2-8D48-EFE501FC178D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Vittorio, > 1) centralization: in practice, much of the Internet is now = decentralized technically but centralized economically and in terms of = control into the hands of a few immense and unaccountable businesses;=20 I certainly agree. As you say, this was not the focus of this article, = but we do in fact mention consolidation in the challenges section. We = and many others have written separately about the details of = consolidation and centralisation. See for instance [1]. > 2) digital sovereignty: how can national governments restore some = degree of non-negotiable control over the consequences that the Internet = has on their societies, and fulfill their strategic need for the = Internet to continue working even in the face of strained international = relations. That=E2=80=99s a very interesting topic, probably also worth more = thought and writing. Sovereignty is of course also complex, to start with because you on one = hand want global reach and access to information, but you do want some = local control. And when I say control, I don=E2=80=99t mean in the sense = of controlling what the newspapers are allowed to write. Or that the one = in charge should be the government. Rather, I mean for instance the = ability to design your network as resilient, e.g., the ability to = function when breakages occur elsewhere. Or the freedom to use local = Internet infrastructure. Jari [1] Plugging in the recent ISOC-sponsored special issue of Journal of = Cyber Policy here: https://www.tandfonline.com/toc/rcyb20/current = --Apple-Mail=_C2ACC9BE-41E4-4DF2-8D48-EFE501FC178D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Vittorio,

1) = centralization: in practice, much of the Internet is now decentralized = technically but centralized economically and in terms of control into = the hands of a few immense and unaccountable businesses;

I = certainly agree. As you say, this was not the focus of this article, but = we do in fact mention consolidation in the challenges section. We and = many others have written separately about the details of consolidation = and centralisation. See for instance [1].

2) digital sovereignty: how can national = governments restore some degree of non-negotiable control over the = consequences that the Internet has on their societies, and fulfill their = strategic need for the Internet to continue working even in the face of = strained international relations.

That=E2=80=99s a very interesting topic, probably also worth = more thought and writing.

Sovereignty is of course also complex, to start with because = you on one hand want global reach and access to information, but you do = want some local control. And when I say control, I don=E2=80=99t mean in = the sense of controlling what the newspapers are allowed to write. Or = that the one in charge should be the government. Rather, I mean for = instance the ability to design your network as resilient, e.g., the = ability to function when breakages occur elsewhere. Or the freedom to = use local Internet infrastructure.

Jari

[1] Plugging in the recent = ISOC-sponsored special issue of Journal of Cyber Policy here: https://www.tandfonline.com/toc/rcyb20/current

= --Apple-Mail=_C2ACC9BE-41E4-4DF2-8D48-EFE501FC178D-- From nobody Thu Jul 9 01:12:13 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F9D3A08C6 for ; Thu, 9 Jul 2020 01:12:10 -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 iqrzIG1h-W9w for ; Thu, 9 Jul 2020 01:12:09 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id EFCC93A08B9 for ; Thu, 9 Jul 2020 01:12:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 643326601DA; Thu, 9 Jul 2020 11:12:07 +0300 (EEST) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baGTqaLlnxdZ; Thu, 9 Jul 2020 11:12:05 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 88040660166; Thu, 9 Jul 2020 11:12:05 +0300 (EEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <801C2DD7-9AD5-4486-8071-454CB9100A9D@pch.net> Date: Thu, 9 Jul 2020 11:12:05 +0300 Cc: architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3F2A2BB8-39C2-41E6-9DA0-C61ABC2DC96C@piuha.net> References: <801C2DD7-9AD5-4486-8071-454CB9100A9D@pch.net> To: Bill Woodcock X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [arch-d] Musings on Internet evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 08:12:11 -0000 Bill, > I assume you saw this: = http://www.oecd.org/coronavirus/policy-responses/keeping-the-internet-up-a= nd-running-in-times-of-crisis-4017c4c9/ >=20 > We had quite a lot of expert input which didn=E2=80=99t make it into = the report, as well, which I can summarize, if people are interested. Thanks for this - I had actually not seen that before. Very useful. One observation that I have heard from many who have been involved in = practical day-to-day Internet businesses is that while the user = experience may be relatively smooth, that doesn=E2=80=99t mean that = nothing needed to be done. A *lot* of work has happened behind the = scenes, capacity added, issues addressed, things moved, calls made, etc. = etc. > =46rom my point of view, I think the most interesting finding is that = this is the end of network-to-network (i.e. routed subnet) VPNs for = home-office situations. While that was supportable for a few = executives, it doesn=E2=80=99t work if most of your workforce is WFH Ok. > One of the big positives in the =E2=80=9Cnew normal=E2=80=9D has been = the democratization of Internet governance meetings=E2=80=A6 My = colleagues Sara Alamin and Ga=C3=ABl Hernandez have a brief article = coming out shortly on that topic. When meetings happen online, = they=E2=80=99re less dominated by people from countries which issue each = other travel visas and which have inexpensive and frequent air travel = between each other. That=E2=80=99s good news, in a = more-eyes-on-the-problem sense, and in a = design-that-works-better-for-everybody-works-better-for-everybody sense. Yes, that has been very good! > The main conclusion I=E2=80=99ve been seeing people draw from the Zoom = situation is that we=E2=80=99ve passed some sort of tipping-point of = ridiculousness in the everything-as-a-service, in-the-cloud shitshow, = and that governments, particularly, need to get back to a point where = they=E2=80=99re capable of standing on their own feet and operating the = services they need, using code they=E2=80=99re familiar with. So, good = news for open-source and open-standards, if people pay attention to = that. I certainly hope so. (Cautiously optimistic but lets see in few years.) Anyway, I think this has been a part of a more general realisation in = the society, e.g., critical supplies and services availability. And it = applies to companies as well, not just governments. Business continuity. Jari From nobody Thu Jul 9 21:32:32 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574AA3A0C5C for ; Thu, 9 Jul 2020 21:32:31 -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, FREEMAIL_FROM=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 yXvpACl5yBgx for ; Thu, 9 Jul 2020 21:32:29 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 6B5393A0C4E for ; Thu, 9 Jul 2020 21:32:29 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id p1so1735406pls.4 for ; Thu, 09 Jul 2020 21:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=nu9vV+rF61lLcao6QG3leb6ELDDwOXzCvqZ+BvnhWwQ=; b=mZMQd5/xOAKsrK/Ivc/fI8DTjhBjyk6uXGRjH6GT43fbwzmlV6+b6G31mDixNz4Sq0 h08sN+tR6QKVTe0cbOEtFgIYdL0pngrOECGpln4AqRc+HQnjIhtLvZnWc/cFE4eBGocy OPRP84SdnrJ04BB8grxOceFcRFOo3d+9Dy4A0PxFhCMJLjjdhsTyJ9gjfJyrtWFawq40 yzxMy6qORklPlYDXNsNyxE5QtpwbJ24i7y+pbSQKU7LZgoLxU3PVbN8d1qTNuyH5GHh+ aR+GtzvvD9KLNovcjG48A+Jr3BT+DWAP11IVT0K3Gu1YxAgcDrFRs4BqfRgWZroUiSIO /YGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nu9vV+rF61lLcao6QG3leb6ELDDwOXzCvqZ+BvnhWwQ=; b=PVsUszZzPoXdL2dKVuMe19if+p6joFVbvEd7unh1TsZsED+lW9O6vHtVsm3UE7W2nN WJ9fgT67cE4ZRS0q3TjkGHm5PuWLBVw7GWgGBopZQoMzEf7sEc4nw5UnHuPQ5+TZXGO9 eRxAPx3FfNU1ZupiWq+fnHHwJmxDvsseSJUBnVUqpWVguQT4YhG6u2uSt5EXYwUbyYvP c6TYegBIVBlmjt+v9k8AkFvvOjf0Y1q5+TIm5yCxpo1lofVcJSP0keMUL5XOLGJSwS9P 4fvjha9Id5Y47TKNWdMlBIYLqWpJzPgFwmr1Oe5sLuPIBqEJ9KRJrEvK5HhO3cdtnORO 7rDQ== X-Gm-Message-State: AOAM531CJBEYwvPywxEG8VcCLofdBxLXrFFNTcfEw7yEvE4L5MGuiuDt AAOQ7vUNp8RFwWTiwc+6YCwgWWpT X-Google-Smtp-Source: ABdhPJz68eTqJWkdm4mnUq+bxN6r+/gg24lPe4hjPTvtLNEKIJnZsh6JECD0pmYEa6hndqhtObhyTw== X-Received: by 2002:a17:90a:728d:: with SMTP id e13mr3824687pjg.51.1594355548278; Thu, 09 Jul 2020 21:32:28 -0700 (PDT) Received: from [192.168.178.20] ([151.210.132.13]) by smtp.gmail.com with ESMTPSA id z6sm4274745pfn.173.2020.07.09.21.32.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2020 21:32:27 -0700 (PDT) To: Jari Arkko , Bill Woodcock Cc: architecture-discuss@ietf.org References: <801C2DD7-9AD5-4486-8071-454CB9100A9D@pch.net> <3F2A2BB8-39C2-41E6-9DA0-C61ABC2DC96C@piuha.net> From: Brian E Carpenter Message-ID: <420c5dc0-c8e3-e6a7-156c-4e538c7fbe08@gmail.com> Date: Fri, 10 Jul 2020 16:32:22 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <3F2A2BB8-39C2-41E6-9DA0-C61ABC2DC96C@piuha.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] Musings on Internet evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 04:32:31 -0000 An interesting counter-factual question is: how would it have worked out = with a connection-oriented virtual-circuit technology? The OECD comment about lack of in-country peering rather suggests what th= e answer would have been. Regards Brian On 09-Jul-20 20:12, Jari Arkko wrote: > Bill, >=20 >> I assume you saw this: http://www.oecd.org/coronavirus/policy-respon= ses/keeping-the-internet-up-and-running-in-times-of-crisis-4017c4c9/ >> >> We had quite a lot of expert input which didn=E2=80=99t make it into t= he report, as well, which I can summarize, if people are interested. >=20 > Thanks for this - I had actually not seen that before. Very useful. >=20 > One observation that I have heard from many who have been involved in p= ractical day-to-day Internet businesses is that while the user experience= may be relatively smooth, that doesn=E2=80=99t mean that nothing needed = to be done. A *lot* of work has happened behind the scenes, capacity adde= d, issues addressed, things moved, calls made, etc. etc. >=20 >> From my point of view, I think the most interesting finding is that th= is is the end of network-to-network (i.e. routed subnet) VPNs for home-of= fice situations. While that was supportable for a few executives, it doe= sn=E2=80=99t work if most of your workforce is WFH >=20 > Ok. >=20 >> One of the big positives in the =E2=80=9Cnew normal=E2=80=9D has been = the democratization of Internet governance meetings=E2=80=A6 My colleagu= es Sara Alamin and Ga=C3=ABl Hernandez have a brief article coming out sh= ortly on that topic. When meetings happen online, they=E2=80=99re less d= ominated by people from countries which issue each other travel visas and= which have inexpensive and frequent air travel between each other. That= =E2=80=99s good news, in a more-eyes-on-the-problem sense, and in a desig= n-that-works-better-for-everybody-works-better-for-everybody sense. >=20 > Yes, that has been very good! >=20 >> The main conclusion I=E2=80=99ve been seeing people draw from the Zoom= situation is that we=E2=80=99ve passed some sort of tipping-point of rid= iculousness in the everything-as-a-service, in-the-cloud shitshow, and th= at governments, particularly, need to get back to a point where they=E2=80= =99re capable of standing on their own feet and operating the services th= ey need, using code they=E2=80=99re familiar with. So, good news for ope= n-source and open-standards, if people pay attention to that. >=20 > I certainly hope so. (Cautiously optimistic but lets see in few years.)= >=20 > Anyway, I think this has been a part of a more general realisation in t= he society, e.g., critical supplies and services availability. And it app= lies to companies as well, not just governments. Business continuity. >=20 > Jari >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 From nobody Fri Jul 10 08:51:17 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD043A0E75 for ; Fri, 10 Jul 2020 08:51:15 -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_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=heapingbits.net header.b=EngjHlk+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HF628d8a 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 DYBmT3Rgj0BD for ; Fri, 10 Jul 2020 08:51:13 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5283A0E6E for ; Fri, 10 Jul 2020 08:51:13 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0EB765C0170 for ; Fri, 10 Jul 2020 11:51:13 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Fri, 10 Jul 2020 11:51:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=L6iAT B9YePevt8F6DZf69IT0F60/FHL0R8b+CCFSZLg=; b=EngjHlk+3i1E4Dc9f5czy dZJaxcXtzz+fxtNr02rVW9N902S9iRT7w0vXU3kbFZTFVfHVjAregy4ieptLACGh KvdNMAkKp9jYZkA6MfXcKy884vopzfUmXCRTiCQvfKugvIMkc+7O7BLCZAxnh3uY 7gHREKJbiltIjHqljGRmr4rndN80AzUB8klZwY9zH0q6se8Atb2ynRd3TQCUZ8Pd VEevO3Y8VbFUOtsg17bWrDZPNUzbB511sDqym7xcYMEu9hgVEhzsjMPEpTqHyLPm ntjlNrVsC5AvMKPp1ZzD2Qc4kKjuYuHxmwOXjoeXbe8K0zMFtx/FvuzDC+FrrkB3 w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=L6iATB9YePevt8F6DZf69IT0F60/FHL0R8b+CCFSZ Lg=; b=HF628d8aVDmpJg50/oogjLvZvqclypJkD7kGn0OHK1ilBn0P+v3faMuAy ldYv82Zdk78Gy1+xcMVDy4FH0KisskQ5QnuNgdt6CpXUkoXP6XAV7u4Aat2yPfM1 uCuszaCK/IEAXrznZjeB6AQJYOxDIqmW57fNpUu8z+KE2yu4Te7eCqbPGgP31i+l gFlL98KWup/zP0Nigi2bIuGFpq9eKXktppqesKqywhzjhjrwNJcc0idYAsTalEkl xLgjwFMz1POcEjyi9t5p+oOGPAXswwSFDo+dG4FpHt0afI2tDZsHb9P+wi85Zozt 9iExgj0y4enCvlKxjgyRFtQ+7cMfg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvddugdelkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeffkefhudethf elleeuteelkedvfeehleefvdefieeggeejteevhfegffejffettdenucffohhmrghinhep ghhithhhuhgsrdgtohhmpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8A50D3C00A1; Fri, 10 Jul 2020 11:51:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e Mime-Version: 1.0 Message-Id: In-Reply-To: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> Date: Fri, 10 Jul 2020 08:50:48 -0700 From: "Christopher Wood" To: architecture-discuss@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [arch-d] =?utf-8?b?PT9VVEYtOD9RP1JlOl9fUHJvcG9zZWRfSUFCX3Byb2dy?= =?utf-8?q?am=3A=5FEvolvability=2C_=5FDeployability=3F=3D_=2C_=26_Maintain?= =?utf-8?q?ability=2E?= X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 15:51:16 -0000 Hi Tommy, I think this is a terrific idea. All three areas are certainly worth exp= loring. Deployability and Maintainability in particular might even make = sense as topics of their own program, separate from Evolvability.=20 However we cut it, I'd like to see progress in the proposed areas, espec= ially for the TLS WG. Methods and tooling support to help track ongoing = implementations of protocol extensions would be valuable for the documen= ts we publish and many drafts we have in flight. We have [1] and [2], th= ough they're not well maintained. A common way to track this information= for the community would be great. Best, Chris [1] https://github.com/tlswg/tlswg-wiki/blob/master/IMPLEMENTATIONS.md [2] https://github.com/tlswg/tlswg-wiki/blob/master/TESTING.md On Mon, Jul 6, 2020, at 12:01 PM, Tommy Pauly wrote: > The IAB is considering starting a new program that would look at the=20= > Evolvability, Deployability, and Maintainability of Internet protocols= .=20 > The description of the program is included at the bottom of this email= . >=20 > We=E2=80=99d like to get feedback on the proposed program topic and=20= > description. We=E2=80=99ll be considering this over the next few weeks= , and=20 > your thoughts and input are welcome! >=20 > Best, > Tommy >=20 > =3D=3D=3D=3D=3D=3D >=20 > Evolvability, Deployability, & Maintainability (EDM) Program >=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 co= nsiders=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 a= s=20 > updating and extending RFC 6709. Moreover, it will focus on ways to=20= > help promote and increase awareness of these strategies within the IET= F=20 > via program meetings, workshops, and helping organize efforts within=20= > working groups and various IETF teams. The program will include member= s=20 > of the 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 gr= easing, and promote the use of extension points to prevent ossification.= Make it easy for people, especially those who aren=E2=80=99t 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/os= sified), and make sure there aren't high allocation barriers to use thos= e extension points. > > Deployability: Focus on how we make =E2=80=9Crunning code=E2=80=9D s= omething that is better integrated into the working group process. Look = at methods to catalog implementations, tools for tracking interoperabili= ty testing on different protocol versions, or repositories of which vers= ions 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= =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. > The program will: > =E2=80=A2 Engage with the IETF community and implementers outside of t= he IETF=20 > to identity successes and problem areas, and collect ideas for=20 > improvements. > =E2=80=A2 Work with the IESG and directorates to determine how best pr= actices=20 > for evolvability can best be applied during IESG review and IETF last=20= > call. > =E2=80=A2 Work with the IESG and tools team on ways to connect impleme= nters 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. > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > From nobody Thu Jul 16 10:43:53 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C673A089B for ; Thu, 16 Jul 2020 10:43:52 -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 vGALi9NZaS59 for ; Thu, 16 Jul 2020 10:43:50 -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 7A15D3A0898 for ; Thu, 16 Jul 2020 10:43:50 -0700 (PDT) Received: from p200300dee7007a0038a2a54933143c9a.dip0.t-ipconnect.de ([2003:de:e700:7a00:38a2:a549:3314:3c9a]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jw7v9-0006U4-2v; Thu, 16 Jul 2020 19:43:47 +0200 From: Mirja Kuehlewind Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <7F89574A-F04B-47F9-A0CB-F5676334D90C@kuehlewind.net> Date: Thu, 16 Jul 2020 19:43:44 +0200 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1594921430;a02e69e4; X-HE-SMSGID: 1jw7v9-0006U4-2v Archived-At: Subject: [arch-d] Agenda for IAB Open Meeting at IETF-108 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 17:43:52 -0000 Hi all, The IAB will for the first time hold an open meeting on Tuesday, July = 28, in Session 2: 13:00-13:50 UTC. This session is aiming to provide an opportunity for more direct = interaction and technical discussion between the community and the IAB, = in both directions: providing information about and reporting back on = work done as well as gathering input about on-going work.=20 Find the draft agenda here as well as below for your connivence: https://datatracker.ietf.org/meeting/108/materials/agenda-108-iabopen-01 See you there! Mirja =E2=80=94=E2=80=94=E2=80=94 *When:* Tue 2020-07-28 13:00 UTC *Where:* [Meetecho] *Chairs:* Mirja K=C3=BChlewind, Tommy Pauly ## Topics ### Welcome and Status Update (10 mins) - Tommy and Mirja=20 ### Documents (5 mins) * draft-iab-for-the-users - Mark ### Workshops (5 mins) * DEDR workshop report - Jari * Proposed workshop on COVID-19 Network Impacts - Jari ### Program Status (20 mins) * Model-t - Stephen * Proposed Program on Evolvability, Deployability, and Maintainability = (EDM) - Tommy ### Open Mic (10 mins) From nobody Fri Jul 17 06:15:19 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606B83A081B for ; Fri, 17 Jul 2020 06:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.648 X-Spam-Level: X-Spam-Status: No, score=0.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 qn68KG54rYou for ; Fri, 17 Jul 2020 06:15:17 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 B4DAF3A0814 for ; Fri, 17 Jul 2020 06:15:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 06HDFE9f030394 for ; Fri, 17 Jul 2020 15:15:14 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CCC49205C3E for ; Fri, 17 Jul 2020 15:15:14 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C3421205BC9 for ; Fri, 17 Jul 2020 15:15:14 +0200 (CEST) Received: from [10.11.240.207] ([10.11.240.207]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 06HDFESs032755 for ; Fri, 17 Jul 2020 15:15:14 +0200 To: architecture-discuss@ietf.org References: From: Alexandre Petrescu Message-ID: <4551d406-cb86-c8da-c596-76a7efe2c15e@gmail.com> Date: Fri, 17 Jul 2020 15:15:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [arch-d] ETSI Liaison Work X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 13:15:18 -0000 Le 28/06/2020 à 08:00, Rob Sayre a écrit : > Hi, > > I had some questions about why the IETF might establish a formal > liaison relationship with ETSI, and why that might appear in IAB > minutes, rather than in the IETF/IESG. The document in question is > here: > > https://www.iab.org/documents/minutes/minutes-2020/iab-minutes-2020-05-27/ > > "3. ETSI Liaison Work Zhenbin Li suggested that the IETF might want > to consider trying to establish a formal liaison with ETSI, noting a > concern that there might be overlap between work in the IETF TEAS WG > and the ETSI Industry Specification Group on Zero touch network and > Service Management (ZSM). > > ... > > Zhenbin Li agreed to follow up with Deborah Brungard and the Routing > Area Directors about whether there is need for a formal liaison > relationship with ETSI, and report back to the IAB." > > ETSI had been unfamiliar to me, but I recently reviewed an ETSI > application for a TLS code point assignment: > https://mailarchive.ietf.org/arch/msg/tls/bkx_bXcPSt_TwE7iJRM9acOQkDA/ > > I was surprised that the IETF would entertain a 99-page PDF that no > individual signed their name to, but I do agree that code point > assignment is not meant to be a gatekeeping mechanism. In the IPWAVE WG about vehicular networks (automobiles, trucks, others) there is relationship to ETSI TC ITS 'Intelligent Transport Systems'. Some of the ETSI's documents were referred to by several Internet Drafts in that WG. A person attending both helped a lot pursuing through the relationship. In the 6MAN WG about IPv6 maintenance there are participants to the ETSI ISG IP6, an Industry Study Group on the topic of IPv6 Integration. It might be that a unique liaison to ETSI might need to broadly cover several WGs at IETF, or otherwise be narrower to a particular WG. Alex > > I did more research into ETSI after that, and this article turned > up: > > https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-shouldnt-use-it > > I would like to hear more from Zhenbin Li, Deborah Brungard, and the > Routing Area Directors about this proposal. > > thanks, Rob > > _______________________________________________ Architecture-discuss > mailing list Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > From nobody Fri Jul 17 06:36:59 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD713A08FD for ; Fri, 17 Jul 2020 06:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.648 X-Spam-Level: X-Spam-Status: No, score=0.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 WtC5f2rHMzvU for ; Fri, 17 Jul 2020 06:36:56 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 C9F013A08FB for ; Fri, 17 Jul 2020 06:36:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 06HDarF0003850 for ; Fri, 17 Jul 2020 15:36:53 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B0D91205C65 for ; Fri, 17 Jul 2020 15:36:53 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A7474205C3E for ; Fri, 17 Jul 2020 15:36:53 +0200 (CEST) Received: from [10.11.240.207] ([10.11.240.207]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 06HDarIS012408 for ; Fri, 17 Jul 2020 15:36:53 +0200 To: architecture-discuss@ietf.org References: From: Alexandre Petrescu Message-ID: <683827bb-15f1-0864-8cc5-c94ea8543563@gmail.com> Date: Fri, 17 Jul 2020 15:36:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [arch-d] Musings on Internet evolution X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 13:36:58 -0000 Le 08/07/2020 à 15:26, Jari Arkko a écrit : > Colin, Tommy, Alissa and me wrote some thoughts on COVID-19 impacts, > Internet evolution, and future challenges. See here: > > http://www.circleid.com/posts/20200707-evolving-the-internet-through-covid-19-and-beyond/ > > > > > But what do you think? Hi, Thank you for putting the document together, and for asking. I think I share the view that operating the Internet did not see significant disruption during the frontal COVID crisis. For example, the announced overload of netflix did not materialize. But certainly there might have been other operations that were affected. An additional reason why it is difficult to say now how COVID affect(ed) the Internet is because COVID is not over. It is a wave, now maybe at a second ripple, which can not be understood in just a few months time. We are below the water level, we are not surfing on it. It might last years, like the other pandemics. Let us check the status of that impact periodically. I would like to add another musing, which I do not intend to be provocative at all, but I feel it deserves being part of a complete picture. The musing is the following: it is universally agreed that the Internet helped a lot steering through the crisis, and I fully share the view, having myself experienced the benefits. However, I will dare to ask: did the Internet contribute to the creation of this event? Can we in all confidence answer by the negative? As a tool created by humans, to what extent the existence and use of the Internet contributed to the factors that are now mentioned as potential sources of this crisis? (de-forestation, unbalanced population to areas, and less Nature in general). Musing on this question does not lead me to be certain that Internet did only good in this event. Alex > What do you think has fuelled evolution, what do you see in store in > these processes in the future, and what bigger challenges do you > think we face in the Internet? Do you see other changes that > functional aspects, e.g., about the way evolution happens? (We’ve > seen some movement from standards to open source-based > interoperability, for instance.)> > Jari > > _______________________________________________ Architecture-discuss > mailing list Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > From nobody Tue Jul 21 07:06:32 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FB23A08CC for ; Tue, 21 Jul 2020 07:06:30 -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 nwZerhW9ielp for ; Tue, 21 Jul 2020 07:06:28 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 3FEA43A08CB for ; Tue, 21 Jul 2020 07:06:28 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id o4so11757277lfi.7 for ; Tue, 21 Jul 2020 07:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NK271wVdwma9q5Z75vgc4ha2CK90CuxabnNkxjYkIyU=; b=UVwsElX4x9nGUxlc2krRnzxDvOx78bHueFZx4CWO+6lm8zZddGpZ1DFfgThHcqVCyn Q+Kw5ltvR7SgYxZ+UNS21Nb3E2Dd4JsfXcC+R90iq5g6Wkjfd9C9sxW2ml0WECFR4BpR HJ+9qTPXc1OM/iIPO5l41zf3as3a581z866e9vzO/1zxyWtEx2BjGzQ9juyIpkNY9uZL 3J5c9b7o5pbCT2Z8BIRUuB/YGnDIAajKcZ61vXuI6d2782Yk0Milh2iDtCYAPtQwqFLP J8zZ9HQkhSQDkLIm3X73OMB/Pab2aXqXolwQoKwjaZJbdG+04enFBPOyu0QUJuiLDdEs /5Kg== 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=NK271wVdwma9q5Z75vgc4ha2CK90CuxabnNkxjYkIyU=; b=tL6Qlr3sonEfw5Uus2gz7uFGSDW/aw9GI3ezDbVfk9dvCalL/f8oBECBk/K3hpOFWd P2EbhT63D5RyQKbKu8ipq3xRmcjEv1NTbQ500N+HrGGtAA/3OUoUwfcNErKMtsdpLNQD bE1UIA/ipL43fvXFR7DwrgWXWJ4y0gFInewCxWF8nEOQE55EtlGJqL5kG4JapVrDAJ0L C+kBTMc7d9VryoAZt7m+2q91Fl71mTrjQ/llOuBYifjWvo4j7rQVnPWy9YzKLLzEVHuf U+yIeeC4anThe/7fRclIUafNYNm4DL7vx5zOyk1VwdEYtxFSQXTmz71FwIgU7BJq9DMt FK7Q== X-Gm-Message-State: AOAM5310SyFEFHGlBq8N6V0Mb22GH7UhgxPzkwtipvREJAY9qlZQOwOV Fb0bdxG66S0HPRbU2lBoUDU8YX4kjvYbx95jrN7xN4zB X-Google-Smtp-Source: ABdhPJx+vKTTXR5ZE6c2r6hAE8BqN/6RcUQZtP4GnYKiBnRyYzNY6FMVTI6JHJfvmuXVE9Qt9rH4xsykfkE4uq/WgYg= X-Received: by 2002:ac2:4422:: with SMTP id w2mr13475812lfl.152.1595340386099; Tue, 21 Jul 2020 07:06:26 -0700 (PDT) MIME-Version: 1.0 References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 21 Jul 2020 09:06:00 -0500 Message-ID: To: Christopher Wood Cc: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="00000000000002671e05aaf421d5" Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability , & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 14:06:31 -0000 --00000000000002671e05aaf421d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Because (for reasons I don't understand) I'm involved in AUTH48 processing for RTCWeb, I find myself wondering whether the proposed IAB program might include considering ways to avoid C-238-style protocol specification clusters, whether from the point of view of architectural oversight, standards process oversight, or RFC Editor oversight. If you're not aware of C238, check out https://www.rfc-editor.org/auth48/C238 for a truly amazing picture of what we are doing today. I'm sort of kidding, and sort of not. Best, Spencer On Fri, Jul 10, 2020 at 10:51 AM Christopher Wood wrote: > Hi Tommy, > > I think this is a terrific idea. All three areas are certainly worth > exploring. Deployability and Maintainability in particular might even mak= e > sense as topics of their own program, separate from Evolvability. > > However we cut it, I'd like to see progress in the proposed areas, > especially for the TLS WG. Methods and tooling support to help track > ongoing implementations of protocol extensions would be valuable for the > documents we publish and many drafts we have in flight. We have [1] and > [2], though they're not well maintained. A common way to track this > information for the community would be great. > > Best, > Chris > > [1] https://github.com/tlswg/tlswg-wiki/blob/master/IMPLEMENTATIONS.md > [2] https://github.com/tlswg/tlswg-wiki/blob/master/TESTING.md > > On Mon, Jul 6, 2020, at 12:01 PM, Tommy Pauly wrote: > > The IAB is considering starting a new program that would look at the > > Evolvability, Deployability, and Maintainability of Internet protocols. > > The description of the program is included at the bottom of this email. > > > > We=E2=80=99d like to get feedback on the proposed program topic and > > description. We=E2=80=99ll be considering this over the next few weeks,= and > > your thoughts and input are welcome! > > > > Best, > > Tommy > > > > =3D=3D=3D=3D=3D=3D > > > > Evolvability, Deployability, & Maintainability (EDM) Program > > > > This program will focus on how to practically encourage best practices > > within the IETF to ensure that the IETF=E2=80=99s standards process con= siders > > 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=E2=80=99t steeped in I= ETF > 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 extensio= n > points. > > > Deployability: Focus on how we make =E2=80=9Crunning code=E2=80=9D so= mething 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 protoco= ls > 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: > > =E2=80=A2 Engage with the IETF community and implementers outside of th= e IETF > > to identity successes and problem areas, and collect ideas for > > improvements. > > =E2=80=A2 Work with the IESG and directorates to determine how best pra= ctices > > for evolvability can best be applied during IESG review and IETF last > > call. > > =E2=80=A2 Work with the IESG and tools team on ways to connect implemen= ters and > > communities that develop and maintain protocols, both while a working > > group is active, and after a working group has concluded its charter. > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --00000000000002671e05aaf421d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Because (for reasons I don't understand) I'm invol= ved in AUTH48 processing for RTCWeb, I find myself wondering whether the pr= oposed IAB program might include considering ways to avoid=C2=A0C-238-style= protocol specification clusters, whether from the point of view of archite= ctural oversight, standards process oversight, or RFC Editor oversight.=C2= =A0

If you're not aware of C238, check out=C2=A0https://www.rfc-editor.org/a= uth48/C238=C2=A0for a truly amazing picture of what we are doing today.= =C2=A0

I'm sort of kidding, and sort of not.= =C2=A0

Best,

Spencer

On Fri, Jul 10, 2020 at 10:51 AM Christopher Wood <caw@heapingbits.net> wrote:
Hi Tommy,

I think this is a terrific idea. All three areas are certainly worth explor= ing. Deployability and Maintainability in particular might even make sense = as topics of their own program, separate from Evolvability.

However we cut it, I'd like to see progress in the proposed areas, espe= cially for the TLS WG. Methods and tooling support to help track ongoing im= plementations of protocol extensions would be valuable for the documents we= publish and many drafts we have in flight. We have [1] and [2], though the= y're not well maintained. A common way to track this information for th= e community would be great.

Best,
Chris

[1] https://github.com/tlswg/tlswg= -wiki/blob/master/IMPLEMENTATIONS.md
[2] https://github.com/tlswg/tlswg-wiki/bl= ob/master/TESTING.md

On Mon, Jul 6, 2020, at 12:01 PM, Tommy Pauly wrote:
> The IAB is considering starting a new program that would look at the <= br> > Evolvability, Deployability, and Maintainability of Internet protocols= .
> The description of the program is included at the bottom of this email= .
>
> We=E2=80=99d like to get feedback on the proposed program topic and > description. We=E2=80=99ll be considering this over the next few weeks= , and
> your thoughts and input are welcome!
>
> Best,
> Tommy
>
> =3D=3D=3D=3D=3D=3D
>
> Evolvability, Deployability, & Maintainability (EDM) Program
>
> This program will focus on how to practically encourage best practices=
> within the IETF to ensure that the IETF=E2=80=99s standards process co= nsiders
> 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 a= s
> updating and extending RFC 6709. Moreover, it will focus on ways to > help promote and increase awareness of these strategies within the IET= F
> via program meetings, workshops, and helping organize efforts within <= br> > working groups and various IETF teams. The program will include member= s
> 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=E2=80=99t steeped in IE= TF 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 extens= ion points.
> > Deployability: Focus on how we make =E2=80=9Crunning code=E2=80= =9D something that is better integrated into the working group process. Loo= k at methods to catalog implementations, tools for tracking interoperabilit= y testing on different protocol versions, or repositories of which versions= of protocols are implemented and used on the Internet. Discuss how deploym= ents can advertise experiments they are running.
> > Maintainability: Many working groups have expressed a desire to h= ave
> 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 <= br> > non-RFC working group output, like FAQs, wikis, and discussion venues.=
> Consider how this community involvement can continue and involve the <= br> > right experts, even after a working group closes.
> The program will:
> =E2=80=A2 Engage with the IETF community and implementers outside of t= he IETF
> to identity successes and problem areas, and collect ideas for
> improvements.
> =E2=80=A2 Work with the IESG and directorates to determine how best pr= actices
> for evolvability can best be applied during IESG review and IETF last =
> call.
> =E2=80=A2 Work with the IESG and tools team on ways to connect impleme= nters and
> communities that develop and maintain protocols, both while a working =
> group is active, and after a working group has concluded its charter.<= br> > _______________________________________________
> Architecture-discuss mailing list
> Arc= hitecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo= /architecture-discuss
>

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--00000000000002671e05aaf421d5-- From nobody Tue Jul 21 07:12:28 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772AF3A08EB for ; Tue, 21 Jul 2020 07:12: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, 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 iKLiMS3NgTEn for ; Tue, 21 Jul 2020 07:12:22 -0700 (PDT) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 DB2093A08E9 for ; Tue, 21 Jul 2020 07:12:22 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id k5so1736615pjg.3 for ; Tue, 21 Jul 2020 07:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7mQ0aE9JMhnULUftJhxs+p5kveazmh0M7sxSIPpEiHg=; b=kKWux0KF/dunWHyXsG7Tc7ZuQtAU+RAZj3og2H0kI/XytgPW0ArcjL0JiFuIIS1B/K jwOB2WcPFtEKnSUfYE+Lx0w/5Jxg4OLiXyfc2xGNr1gOXqVDgKT/p2r4n9kyH+FOMtL2 g1TFrBNjaZ6Wz+3kNKaEM6aiT2JlerNCUp/0BnmvDFekEdUlieT1zIvWhbYrOHcAregn A5t8mXj3bApfkwG9VAoAWOnnAOCWmmJ/qMbyWjlR5jJaU47+dPBXsenFr2iiwwD2nNDc L329Qfdz/ZUTA0/jre9Zhw9yufxpaILkHFjTEO9Fa15v2eU7+kPZpnjNGOSWaxCBnDWd RyEA== 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=7mQ0aE9JMhnULUftJhxs+p5kveazmh0M7sxSIPpEiHg=; b=szTdNn3fgu975zpQMgpjp9LYBc/FNNP9oxwicqt1kiezQMMr+cJlHI+fnEME4EzuCe Lt6xmehVEmefuQyn++lGxIfV9Ny/Rs9xfxps8Bbm6lxbVP4uNlsuCQ8IPhBORC15hinG ROq+3fvyBrWyOm0ALZ/Emjx1r7zhiwBqc3mgdAlVAgxsjILHVExyyNi8QFV7pczQkCsi l5gUdi1hg2VaTSVWsqyZZiRihUoGbuaLtZsVqsAF/R/Tu9FbI9ozloDcSVCt58YTwmuu 04weDXKgOkGlnnlhMPJUk8nyNeKJ0Qkt8Sd9Y+iHDKKM+amuOuB4aXsRjdZ3OoMNiqxa PJIA== X-Gm-Message-State: AOAM53310HfF1B0//oVp7Iz/d67SVMjOWyrK1WP3e/mSxcbNRGMjsyTW j3KFKZ/EuPpNqrGBunpSDfBv5I8vkndNy60iZ2o= X-Google-Smtp-Source: ABdhPJx3GuilW2XvnZQMTOa1xXJFvLbzhk6VU7olFMezCx90wcdOJFamC5vxP1QDCY/P6LmNpQrITsTdJTFyNKKU35Q= X-Received: by 2002:a17:902:103:: with SMTP id 3mr23021389plb.195.1595340742286; Tue, 21 Jul 2020 07:12:22 -0700 (PDT) MIME-Version: 1.0 References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> In-Reply-To: From: Mary Barnes Date: Tue, 21 Jul 2020 09:12:10 -0500 Message-ID: To: Spencer Dawkins at IETF Cc: Christopher Wood , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000003d607a05aaf4365d" Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability , & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 14:12:28 -0000 --0000000000003d607a05aaf4365d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You got put on that list because you had one or more documents as shepherd, WG chair of any of the WGs in that cluster or you were an author for any of the documents in the cluster. So, you get to see all the documents in the cluster go through the process (if you so desire). I'm not sure there was a way around it, since changes in some of the docs could have trickled down/up to others. But, perhaps, processing the documents (at the discretion of WG chairs and ADs)and then doing errata and -bises, if there impacts, might have been a more efficient way of handling all of this rather than the usual of waiting for normative dependencies to get published. There were 2 docs I shepherded in this cluster, so I've gotten all these emails. You can get removed from that list if it's bothersome. Regards, Mary. On Tue, Jul 21, 2020 at 9:06 AM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Because (for reasons I don't understand) I'm involved in AUTH48 processin= g > for RTCWeb, I find myself wondering whether the proposed IAB program migh= t > include considering ways to avoid C-238-style protocol specification > clusters, whether from the point of view of architectural oversight, > standards process oversight, or RFC Editor oversight. > > If you're not aware of C238, check out > https://www.rfc-editor.org/auth48/C238 for a truly amazing picture of > what we are doing today. > > I'm sort of kidding, and sort of not. > > Best, > > Spencer > > On Fri, Jul 10, 2020 at 10:51 AM Christopher Wood > wrote: > >> Hi Tommy, >> >> I think this is a terrific idea. All three areas are certainly worth >> exploring. Deployability and Maintainability in particular might even ma= ke >> sense as topics of their own program, separate from Evolvability. >> >> However we cut it, I'd like to see progress in the proposed areas, >> especially for the TLS WG. Methods and tooling support to help track >> ongoing implementations of protocol extensions would be valuable for the >> documents we publish and many drafts we have in flight. We have [1] and >> [2], though they're not well maintained. A common way to track this >> information for the community would be great. >> >> Best, >> Chris >> >> [1] https://github.com/tlswg/tlswg-wiki/blob/master/IMPLEMENTATIONS.md >> [2] https://github.com/tlswg/tlswg-wiki/blob/master/TESTING.md >> >> On Mon, Jul 6, 2020, at 12:01 PM, Tommy Pauly wrote: >> > The IAB is considering starting a new program that would look at the >> > Evolvability, Deployability, and Maintainability of Internet >> protocols.. >> > The description of the program is included at the bottom of this email= .. >> > >> > We=E2=80=99d like to get feedback on the proposed program topic and >> > description. We=E2=80=99ll be considering this over the next few weeks= , and >> > your thoughts and input are welcome! >> > >> > Best, >> > Tommy >> > >> > =3D=3D=3D=3D=3D=3D >> > >> > Evolvability, Deployability, & Maintainability (EDM) Program >> > >> > This program will focus on how to practically encourage best practices >> > within the IETF to ensure that the IETF=E2=80=99s standards process co= nsiders >> > 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 a= s >> > updating and extending RFC 6709. Moreover, it will focus on ways to >> > help promote and increase awareness of these strategies within the IET= F >> > via program meetings, workshops, and helping organize efforts within >> > working groups and various IETF teams. The program will include member= s >> > 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 ossificatio= n. >> Make it easy for people, especially those who aren=E2=80=99t 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 extensi= on >> points. >> > > Deployability: Focus on how we make =E2=80=9Crunning code=E2=80=9D s= omething 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 protoc= ols >> 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: >> > =E2=80=A2 Engage with the IETF community and implementers outside of t= he IETF >> > to identity successes and problem areas, and collect ideas for >> > improvements. >> > =E2=80=A2 Work with the IESG and directorates to determine how best pr= actices >> > for evolvability can best be applied during IESG review and IETF last >> > call. >> > =E2=80=A2 Work with the IESG and tools team on ways to connect impleme= nters and >> > communities that develop and maintain protocols, both while a working >> > group is active, and after a working group has concluded its charter. >> > _______________________________________________ >> > Architecture-discuss mailing list >> > Architecture-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/architecture-discuss >> > >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000003d607a05aaf4365d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You got put on that list because you had one or more docum= ents as shepherd, WG chair of any of the WGs in that cluster or you were an= author for any of the documents in the cluster.=C2=A0 =C2=A0 So, you get t= o see all the documents in the cluster go through the process (if you so de= sire).=C2=A0 I'm not sure there was a way around it, since changes in s= ome of the docs could have trickled down/up to others. But, perhaps, proces= sing the documents (at the discretion of WG chairs and ADs)and then doing e= rrata and -bises, if there impacts, might have been a more efficient way of= handling all of this rather than the usual of=C2=A0 waiting for normative = dependencies to get published.=C2=A0=C2=A0

There were 2 = docs I shepherded in this cluster, so I've gotten all these emails.=C2= =A0 You can get removed from that list if it's bothersome.=C2=A0

Regards,
Mary.

On Tue, Jul 21, 2020= at 9:06 AM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Because (for re= asons I don't understand) I'm involved in AUTH48 processing for RTC= Web, I find myself wondering whether the proposed IAB program might include= considering ways to avoid=C2=A0C-238-style protocol specification clusters= , whether from the point of view of architectural oversight, standards proc= ess oversight, or RFC Editor oversight.=C2=A0

If you'= ;re not aware of C238, check out=C2=A0https://www.rfc-editor.org/auth48/C238= =C2=A0for a truly amazing picture of what we are doing today.=C2=A0

I'm sort of kidding, and sort of not.=C2=A0

Best,

Spencer

On Fri, Jul 10,= 2020 at 10:51 AM Christopher Wood <caw@heapingbits.net> wrote:
Hi Tommy,

I think this is a terrific idea. All three areas are certainly worth explor= ing. Deployability and Maintainability in particular might even make sense = as topics of their own program, separate from Evolvability.

However we cut it, I'd like to see progress in the proposed areas, espe= cially for the TLS WG. Methods and tooling support to help track ongoing im= plementations of protocol extensions would be valuable for the documents we= publish and many drafts we have in flight. We have [1] and [2], though the= y're not well maintained. A common way to track this information for th= e community would be great.

Best,
Chris

[1] https://github.com/tlswg/tlswg= -wiki/blob/master/IMPLEMENTATIONS.md
[2] https://github.com/tlswg/tlswg-wiki/bl= ob/master/TESTING.md

On Mon, Jul 6, 2020, at 12:01 PM, Tommy Pauly wrote:
> The IAB is considering starting a new program that would look at the <= br> > Evolvability, Deployability, and Maintainability of Internet protocols= ..
> The description of the program is included at the bottom of this email= ..
>
> We=E2=80=99d like to get feedback on the proposed program topic and > description. We=E2=80=99ll be considering this over the next few weeks= , and
> your thoughts and input are welcome!
>
> Best,
> Tommy
>
> =3D=3D=3D=3D=3D=3D
>
> Evolvability, Deployability, & Maintainability (EDM) Program
>
> This program will focus on how to practically encourage best practices=
> within the IETF to ensure that the IETF=E2=80=99s standards process co= nsiders
> 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 a= s
> updating and extending RFC 6709. Moreover, it will focus on ways to > help promote and increase awareness of these strategies within the IET= F
> via program meetings, workshops, and helping organize efforts within <= br> > working groups and various IETF teams. The program will include member= s
> 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=E2=80=99t steeped in IE= TF 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 extens= ion points.
> > Deployability: Focus on how we make =E2=80=9Crunning code=E2=80= =9D something that is better integrated into the working group process. Loo= k at methods to catalog implementations, tools for tracking interoperabilit= y testing on different protocol versions, or repositories of which versions= of protocols are implemented and used on the Internet. Discuss how deploym= ents can advertise experiments they are running.
> > Maintainability: Many working groups have expressed a desire to h= ave
> 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 <= br> > non-RFC working group output, like FAQs, wikis, and discussion venues.=
> Consider how this community involvement can continue and involve the <= br> > right experts, even after a working group closes.
> The program will:
> =E2=80=A2 Engage with the IETF community and implementers outside of t= he IETF
> to identity successes and problem areas, and collect ideas for
> improvements.
> =E2=80=A2 Work with the IESG and directorates to determine how best pr= actices
> for evolvability can best be applied during IESG review and IETF last =
> call.
> =E2=80=A2 Work with the IESG and tools team on ways to connect impleme= nters and
> communities that develop and maintain protocols, both while a working =
> group is active, and after a working group has concluded its charter.<= br> > _______________________________________________
> Architecture-discuss mailing list
> Arc= hitecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo= /architecture-discuss
>

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--0000000000003d607a05aaf4365d-- From nobody Tue Jul 21 08:24:36 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566F63A0821 for ; Tue, 21 Jul 2020 08:24:35 -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 67hrYEcbUBJS for ; Tue, 21 Jul 2020 08:24:33 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::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 C2B573A0816 for ; Tue, 21 Jul 2020 08:24:32 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id d17so24531909ljl.3 for ; Tue, 21 Jul 2020 08:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+tpkMrzyvCpHq8QstDB0Pf/A+ccnrsCQQk+2DWi4hHI=; b=bYpLoLZuUyonXZzuUjAsLW3PiNTWAEqvBsc5W2pJfKUXzSqWVqsluH5kb976To0CIs qawVR+YYfesSCOc2NNZcDAFutgtg4STmMXBApchfjtUlf5rxZycPG+x/bSoBKph9v4Ry vqjkO9KRNcRZWXhrldOheC23j9Gvor+1XWTBlWHLgLYTZ5cXPgJ3k9X9DQwncldOEENO P4Gg3Y0A2rfZ2FEEfBqFVlm3uPcJ+sLdoa3vEGJYYd9U+/I1KjZpzVkhoE6ERU/PGdA7 eqRdGc+zKGKRu9zMzgzG0eOocqqMHhILWx5WXYNNY9YOHyXgTmY0JXOE/4Mx3frYeRLc AUWQ== 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=+tpkMrzyvCpHq8QstDB0Pf/A+ccnrsCQQk+2DWi4hHI=; b=XtZVWj/8C6d2/ok4RmL7laJTM5aeZLJo/wDhfGDGdHO3UoAAOeanl47nk51V64qNsg cSmMPWkhWIwDppmJFay4E3G/boB7ydZO1qenF6+jrEpm3S8oYif2iO2z1BT+W1sBy+Jl KVZUPNKi3n0YPce0nsFEi84ls1cSOvcOfBzvTykq2ftiGJTqo8n+RGoeI+avivnq5krS pR/WWOjfv1JGf3fb15BeJAAX7lSJgb3Z0tB+TSOnG4DbgtY5xxHLJr0OMNq/uVFI1V4/ ei4ltt06cG9RE2Rm7Lxh3Jiz86PJG+49HakcfC7NgQCTl7TUqMWRKhYH3vndo4caMp4B B4/w== X-Gm-Message-State: AOAM533njoQ8OKAks8VT9hd1RKVqN4ENtDkleYxFA5gNeJXfLL7o2qS2 cOp/SlXvB2/RayZf7GnCFh60eLg4vuadq5mhzmA= X-Google-Smtp-Source: ABdhPJzvQVTvn3A3F/IBbyhfnHe8vXmpjKooAV+8AY2lBJ8JeYU4tOeU5e64lhciF0E3K7M5CV7Xo8paeR2TdZtK2pk= X-Received: by 2002:a2e:9003:: with SMTP id h3mr13322614ljg.191.1595345070821; Tue, 21 Jul 2020 08:24:30 -0700 (PDT) MIME-Version: 1.0 References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 21 Jul 2020 10:24:04 -0500 Message-ID: To: Mary Barnes Cc: Christopher Wood , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000003d9a9c05aaf538a0" Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability , & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 15:24:35 -0000 --0000000000003d9a9c05aaf538a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Mary, On Tue, Jul 21, 2020 at 9:12 AM Mary Barnes wrote: > You got put on that list because you had one or more documents as > shepherd, WG chair of any of the WGs in that cluster or you were an autho= r > for any of the documents in the cluster. So, you get to see all the > documents in the cluster go through the process (if you so desire). I'm > not sure there was a way around it, since changes in some of the docs cou= ld > have trickled down/up to others. But, perhaps, processing the documents (= at > the discretion of WG chairs and ADs)and then doing errata and -bises, if > there impacts, might have been a more efficient way of handling all of th= is > rather than the usual of waiting for normative dependencies to get > published. > > There were 2 docs I shepherded in this cluster, so I've gotten all these > emails. You can get removed from that list if it's bothersome. > At this point, it's just a marvel to see ;-) Best, Spencer, who is kind of hoping he's not STILL listed as responsible AD for any of these documents, but since everyone is seeing everything, I don't think that really matters! I don't think I'd qualify under any other criteria ... not a WG chair, not a doc shepherd, not an author ... > > Regards, > Mary. > > On Tue, Jul 21, 2020 at 9:06 AM Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >> Because (for reasons I don't understand) I'm involved in AUTH48 >> processing for RTCWeb, I find myself wondering whether the proposed IAB >> program might include considering ways to avoid C-238-style protocol >> specification clusters, whether from the point of view of architectural >> oversight, standards process oversight, or RFC Editor oversight. >> >> If you're not aware of C238, check out >> https://www.rfc-editor.org/auth48/C238 for a truly amazing picture of >> what we are doing today. >> >> I'm sort of kidding, and sort of not. >> >> Best, >> >> Spencer >> >> On Fri, Jul 10, 2020 at 10:51 AM Christopher Wood >> wrote: >> >>> Hi Tommy, >>> >>> I think this is a terrific idea. All three areas are certainly worth >>> exploring. Deployability and Maintainability in particular might even m= ake >>> sense as topics of their own program, separate from Evolvability. >>> >>> However we cut it, I'd like to see progress in the proposed areas, >>> especially for the TLS WG. Methods and tooling support to help track >>> ongoing implementations of protocol extensions would be valuable for th= e >>> documents we publish and many drafts we have in flight. We have [1] and >>> [2], though they're not well maintained. A common way to track this >>> information for the community would be great. >>> >>> Best, >>> Chris >>> >>> [1] https://github.com/tlswg/tlswg-wiki/blob/master/IMPLEMENTATIONS.md >>> [2] https://github.com/tlswg/tlswg-wiki/blob/master/TESTING.md >>> >>> On Mon, Jul 6, 2020, at 12:01 PM, Tommy Pauly wrote: >>> > The IAB is considering starting a new program that would look at the >>> > Evolvability, Deployability, and Maintainability of Internet >>> protocols.. >>> > The description of the program is included at the bottom of this >>> email.. >>> > >>> > We=E2=80=99d like to get feedback on the proposed program topic and >>> > description. We=E2=80=99ll be considering this over the next few week= s, and >>> > your thoughts and input are welcome! >>> > >>> > Best, >>> > Tommy >>> > >>> > =3D=3D=3D=3D=3D=3D >>> > >>> > Evolvability, Deployability, & Maintainability (EDM) Program >>> > >>> > This program will focus on how to practically encourage best practice= s >>> > within the IETF to ensure that the IETF=E2=80=99s standards process c= onsiders >>> > protocol evolution, deployability, and long-term maintainability. Thi= s >>> > 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 ossificati= on. >>> Make it easy for people, especially those who aren=E2=80=99t 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/ossifie= d), >>> and make sure there aren't high allocation barriers to use those extens= ion >>> points. >>> > > Deployability: Focus on how we make =E2=80=9Crunning code=E2=80=9D = 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 proto= cols >>> 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 hav= e >>> > 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: >>> > =E2=80=A2 Engage with the IETF community and implementers outside of = the IETF >>> > to identity successes and problem areas, and collect ideas for >>> > improvements. >>> > =E2=80=A2 Work with the IESG and directorates to determine how best p= ractices >>> > for evolvability can best be applied during IESG review and IETF last >>> > call. >>> > =E2=80=A2 Work with the IESG and tools team on ways to connect implem= enters >>> and >>> > communities that develop and maintain protocols, both while a working >>> > group is active, and after a working group has concluded its charter. >>> > _______________________________________________ >>> > Architecture-discuss mailing list >>> > Architecture-discuss@ietf.org >>> > https://www.ietf.org/mailman/listinfo/architecture-discuss >>> > >>> >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> > --0000000000003d9a9c05aaf538a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Mary,=C2=A0

On Tue, Jul 21, 2020 at 9:= 12 AM Mary Barnes <mary.ie= tf.barnes@gmail.com> wrote:
You got put on that list because you ha= d one or more documents as shepherd, WG chair of any of the WGs in that clu= ster or you were an author for any of the documents in the cluster.=C2=A0 = =C2=A0 So, you get to see all the documents in the cluster go through the p= rocess (if you so desire).=C2=A0 I'm not sure there was a way around it= , since changes in some of the docs could have trickled down/up to others. = But, perhaps, processing the documents (at the discretion of WG chairs and = ADs)and then doing errata and -bises, if there impacts, might have been a m= ore efficient way of handling all of this rather than the usual of=C2=A0 wa= iting for normative dependencies to get published.=C2=A0=C2=A0

There were 2 docs I shepherded in this cluster, so I've gotten a= ll these emails.=C2=A0 You can get removed from that list if it's bothe= rsome.=C2=A0

At this point,= it's just a marvel to see ;-)

Best,

Spencer, who is kind of hoping he's not STILL listed as= responsible AD for any of these documents, but since everyone is seeing ev= erything, I don't think that really matters! I don't think I'd = qualify under any other criteria ... not a WG chair, not a doc shepherd, no= t an author ...
=C2=A0

Regards,
Mary.

On Tue, Jul 21, 2020 at 9:06 AM Spencer Dawkins at IETF= <spe= ncerdawkins.ietf@gmail.com> wrote:
Because (for reasons I don't= understand) I'm involved in AUTH48 processing for RTCWeb, I find mysel= f wondering whether the proposed IAB program might include considering ways= to avoid=C2=A0C-238-style protocol specification clusters, whether from th= e point of view of architectural oversight, standards process oversight, or= RFC Editor oversight.=C2=A0

If you're not aware of = C238, check out=C2=A0https://www.rfc-editor.org/auth48/C238=C2=A0for a truly = amazing picture of what we are doing today.=C2=A0

= I'm sort of kidding, and sort of not.=C2=A0

Be= st,

Spencer

On Fri, Jul 10, 2020 at 10:51 AM = Christopher Wood <caw@heapingbits.net> wrote:
Hi Tommy,

I think this is a terrific idea. All three areas are certainly worth explor= ing. Deployability and Maintainability in particular might even make sense = as topics of their own program, separate from Evolvability.

However we cut it, I'd like to see progress in the proposed areas, espe= cially for the TLS WG. Methods and tooling support to help track ongoing im= plementations of protocol extensions would be valuable for the documents we= publish and many drafts we have in flight. We have [1] and [2], though the= y're not well maintained. A common way to track this information for th= e community would be great.

Best,
Chris

[1] https://github.com/tlswg/tlswg= -wiki/blob/master/IMPLEMENTATIONS.md
[2] https://github.com/tlswg/tlswg-wiki/bl= ob/master/TESTING.md

On Mon, Jul 6, 2020, at 12:01 PM, Tommy Pauly wrote:
> The IAB is considering starting a new program that would look at the <= br> > Evolvability, Deployability, and Maintainability of Internet protocols= ..
> The description of the program is included at the bottom of this email= ..
>
> We=E2=80=99d like to get feedback on the proposed program topic and > description. We=E2=80=99ll be considering this over the next few weeks= , and
> your thoughts and input are welcome!
>
> Best,
> Tommy
>
> =3D=3D=3D=3D=3D=3D
>
> Evolvability, Deployability, & Maintainability (EDM) Program
>
> This program will focus on how to practically encourage best practices=
> within the IETF to ensure that the IETF=E2=80=99s standards process co= nsiders
> 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 a= s
> updating and extending RFC 6709. Moreover, it will focus on ways to > help promote and increase awareness of these strategies within the IET= F
> via program meetings, workshops, and helping organize efforts within <= br> > working groups and various IETF teams. The program will include member= s
> 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=E2=80=99t steeped in IE= TF 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 extens= ion points.
> > Deployability: Focus on how we make =E2=80=9Crunning code=E2=80= =9D something that is better integrated into the working group process. Loo= k at methods to catalog implementations, tools for tracking interoperabilit= y testing on different protocol versions, or repositories of which versions= of protocols are implemented and used on the Internet. Discuss how deploym= ents can advertise experiments they are running.
> > Maintainability: Many working groups have expressed a desire to h= ave
> 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 <= br> > non-RFC working group output, like FAQs, wikis, and discussion venues.=
> Consider how this community involvement can continue and involve the <= br> > right experts, even after a working group closes.
> The program will:
> =E2=80=A2 Engage with the IETF community and implementers outside of t= he IETF
> to identity successes and problem areas, and collect ideas for
> improvements.
> =E2=80=A2 Work with the IESG and directorates to determine how best pr= actices
> for evolvability can best be applied during IESG review and IETF last =
> call.
> =E2=80=A2 Work with the IESG and tools team on ways to connect impleme= nters and
> communities that develop and maintain protocols, both while a working =
> group is active, and after a working group has concluded its charter.<= br> > _______________________________________________
> Architecture-discuss mailing list
> Arc= hitecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo= /architecture-discuss
>

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--0000000000003d9a9c05aaf538a0-- From nobody Tue Jul 21 13:49:02 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24803A0A6A for ; Tue, 21 Jul 2020 13:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-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 2u7PhVwBV7aa for ; Tue, 21 Jul 2020 13:48:59 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 0D6983A0A69 for ; Tue, 21 Jul 2020 13:48:58 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id k27so31259pgm.2 for ; Tue, 21 Jul 2020 13:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sYrAS98FX+bWj/xNu+vA/N3wtdIlbgGYiZI7TgdKq3g=; b=X5eZ0cZLb7hActabl3oaI1bUTEsRSl4npmdUS+3v1i3tAqdMI7+LAR1BrWws4eHeDb R4neEWtDTFnU27m/Igf9Su/1xhFPyKCTX+OOnPuH36UoIFVCYNatmhloTH5s02EVkEFe M+0hajdNiIfgEZj72BKHM3yMSDQaqTcAPRFlOmg/u/ot7qzAxwr9l7BW52EJxfOvq6Bb YAQAzg2D6vKbwKcbfw5NWJI62jCvdfJvrX+JOa+E0cTIxemc0jQPCQLX/yfeexJCyufc OcnXNDrKaPyinMmUy4emr0EO6oT4F7nOD/8C/Da8paM3cuEKMSy4QQrRceSbZA/805BQ nw6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=sYrAS98FX+bWj/xNu+vA/N3wtdIlbgGYiZI7TgdKq3g=; b=lK2/LpP7z2H2mIIMJPiAjxtqb22Ug48qOo8Vts4BMJwtvzFoF9FNsnp7/fGO+isJID EJEiEiQJpggw7MtvxZIjd4t5id7QjXIB/LHe2AXhcEBxpjRVyW2EZ6EFEhLk7kMwuCHG a2U1+kiNdep410nj35FwOWErJ/0cfD4aa+s0gd59uIt85gWs8pIJtb/edjSUiAoWK3mp nSFY0QERgNIV5RvacW91k18AXurzc90k/UDHB1BnrxZf0+Inykocwl7z5WdDhvg22A18 VvAH3YopWfuIomWjma8R5P10wfozAowQXAgI5BeVFmsCnW8zR1oZ+UD31wr//6Je1N5x /Q2A== X-Gm-Message-State: AOAM530WfQ4AkAqjwFMBGu7yVashbE7QeA3ct2huGsdfYOAODcacM45+ L+VD24e5NCQW+0LdPVzdhItinwhj X-Google-Smtp-Source: ABdhPJw7hnXjgoha8DWcpu93pgqjPAvDupcl9fLPLyFlWxnCvI2ayq4wRZ8tbInaQjuLmUBkSxhdng== X-Received: by 2002:a63:d501:: with SMTP id c1mr24155057pgg.159.1595364537955; Tue, 21 Jul 2020 13:48:57 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id h1sm19351786pgn.41.2020.07.21.13.48.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2020 13:48:57 -0700 (PDT) To: Spencer Dawkins at IETF , Christopher Wood Cc: architecture-discuss@ietf.org References: <087DBE75-7103-4D82-8878-59F1E53592C8@apple.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 22 Jul 2020 08:48:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability , & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 20:49:01 -0000 Yes. I don't see C238 as disjoint from the problem I already raised: https://mailarchive.ietf.org/arch/msg/architecture-discuss/A0ZP4w-UhX7Cu5= E8gSPK1haSDWI/ In fact I even mentioned RTCWEB there. Unsurprisingly, I think that if we don't tackle this problem, technical e= fforts on Evolvability, Deployability , & Maintainability will be futile.= Regards Brian Carpenter On 22-Jul-20 02:06, Spencer Dawkins at IETF wrote: > Because (for reasons I don't understand) I'm involved in AUTH48 process= ing for RTCWeb, I find myself wondering whether the proposed IAB program = might include considering ways to avoid=C2=A0C-238-style protocol specifi= cation clusters, whether from the point of view of architectural oversigh= t, standards process oversight, or RFC Editor oversight.=C2=A0 >=20 > If you're not aware of C238, check out=C2=A0https://www.rfc-editor.org/= auth48/C238=C2=A0for a truly amazing picture of what we are doing today.=C2= =A0 >=20 > I'm sort of kidding, and sort of not.=C2=A0 >=20 > Best, >=20 > Spencer >=20 > On Fri, Jul 10, 2020 at 10:51 AM Christopher Wood > wrote: >=20 > Hi Tommy, >=20 > I think this is a terrific idea. All three areas are certainly wort= h exploring. Deployability and Maintainability in particular might even m= ake sense as topics of their own program, separate from Evolvability. >=20 > However we cut it, I'd like to see progress in the proposed areas, = especially for the TLS WG. Methods and tooling support to help track ongo= ing implementations of protocol extensions would be valuable for the docu= ments we publish and many drafts we have in flight. We have [1] and [2], = though they're not well maintained. A common way to track this informatio= n for the community would be great. >=20 > Best, > Chris >=20 > [1] https://github.com/tlswg/tlswg-wiki/blob/master/IMPLEMENTATIONS= =2Emd > [2] https://github.com/tlswg/tlswg-wiki/blob/master/TESTING.md >=20 > On Mon, Jul 6, 2020, at 12:01 PM, Tommy Pauly wrote: > > The IAB is considering starting a new program that would look at = the > > Evolvability, Deployability, and Maintainability of Internet prot= ocols.. > > The description of the program is included at the bottom of this = email.. > > > > We=E2=80=99d like to get feedback on the proposed program topic a= nd > > description. We=E2=80=99ll be considering this over the next few = weeks, and > > your thoughts and input are welcome! > > > > Best, > > Tommy > > > > =3D=3D=3D=3D=3D=3D > > > > Evolvability, Deployability, & Maintainability (EDM) Program > > > > This program will focus on how to practically encourage best prac= tices > > within the IETF to ensure that the IETF=E2=80=99s standards proce= ss 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, s= uch as > > updating and extending RFC 6709. Moreover, it will focus on ways = to > > help promote and increase awareness of these strategies within th= e IETF > > via program meetings, workshops, and helping organize efforts wit= hin > > working groups and various IETF teams. The program will include m= embers > > of the IESG and the tools team to help implement these strategies= =2E > > > > The topics this group will consider include: > > > > > Evolvability: Encourage protocols to design for extensibility a= nd greasing, and promote the use of extension points to prevent ossificat= ion. Make it easy for people, especially those who aren=E2=80=99t steeped= in IETF process, to know which extension points are the right ones to us= e for a given protocol (and which ones should be considered more stable/o= ssified), and make sure there aren't high allocation barriers to use thos= e extension points. > > > Deployability: Focus on how we make =E2=80=9Crunning code=E2=80= =9D something that is better integrated into the working group process. L= ook at methods to catalog implementations, tools for tracking interoperab= ility testing on different protocol versions, or repositories of which ve= rsions 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, kno= wn > > errata/bugs, or best practices. Help promote consistent ways to h= ost > > non-RFC working group output, like FAQs, wikis, and discussion ve= nues. > > Consider how this community involvement can continue and involve = the > > right experts, even after a working group closes. > > The program will: > > =E2=80=A2 Engage with the IETF community and implementers outside= of the IETF > > to identity successes and problem areas, and collect ideas for > > improvements. > > =E2=80=A2 Work with the IESG and directorates to determine how be= st practices > > for evolvability can best be applied during IESG review and IETF = last > > call. > > =E2=80=A2 Work with the IESG and tools team on ways to connect im= plementers and > > communities that develop and maintain protocols, both while a wor= king > > group is active, and after a working group has concluded its char= ter. > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 From nobody Tue Jul 21 21:00:35 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30473A0C1F for ; Tue, 21 Jul 2020 21:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=eTS9XSLV; dkim=pass (1536-bit key) header.d=taugh.com header.b=K4D34IHv 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 yrqINdnOYH1n for ; Tue, 21 Jul 2020 21:00:31 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 D98483A0C1C for ; Tue, 21 Jul 2020 21:00:30 -0700 (PDT) Received: (qmail 76614 invoked from network); 22 Jul 2020 04:00:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12b41.5f17b9dd.k2007; bh=j80yaDt5A9xPiFKz3uEIvlTGMdTHYN6PUedmXyYIlj0=; b=eTS9XSLVduY/3Q3VPMm1brGlpF1sB1PlgUHCbScRB0mWdpmZu4SgkiYHzHNHPtla2B5ja6ny53EljzEaT/yhPIJjeBozgeHfJe3qE8cqXdLmc7EPGsSudgMCiya+XF0hU7OzVrqpd18j36DNfMWHBUdeA8El6hJb5Kc8bdHxYwBMENyqPMVLzrBtAJDgY1D+aj9cnGLBBCrIuf7ers4QDMrQ7L5Oxw5GG7Mw/Qph7bg15l9YtqpMdIfY7360TaOM DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12b41.5f17b9dd.k2007; bh=j80yaDt5A9xPiFKz3uEIvlTGMdTHYN6PUedmXyYIlj0=; b=K4D34IHvkLocEACqAkiHHdeU3RPf+Ue6iu9CuT8SeVJiZmXRuuGc4w+2OmRyqwWDMU6esHGjXD0wkC91amxiarTrD2HuWbZ2TNqol9Ly1CSvFg/AoO/emCO6wJWdm0FM3Udqqd4iKf9+qn2loNevuneAJWV0Xa50XDKhCCg7AqOaRLN8o4i0Ss/CUNRUQjAxyZgL4DsXd0tX0fpZqxDhSwGw2Xt7U1km5Yj72fPhIcbx62pZjplYfdVzosyAmQKD Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 22 Jul 2020 04:00:28 -0000 Received: by ary.qy (Postfix, from userid 501) id 728C81D5EB94; Wed, 22 Jul 2020 00:00:28 -0400 (EDT) Date: 22 Jul 2020 00:00:28 -0400 Message-Id: <20200722040028.728C81D5EB94@ary.qy> From: "John Levine" To: architecture-discuss@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [arch-d] clusterpation, was Proposed IAB program: Evolvability, Deployability , & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 04:00:34 -0000 In article you write: >Because (for reasons I don't understand) I'm involved in AUTH48 processing >for RTCWeb, I find myself wondering whether the proposed IAB program might >include considering ways to avoid C-238-style protocol specification >clusters, whether from the point of view of architectural oversight, >standards process oversight, or RFC Editor oversight. I think we all agree that we don't ever want to see another document cluster as large or as long-lived as C238. But I would rather not attempt to invent processes to try and guess how best to prevent hypothetical superclusters. I'd rather that the RPC and I (or a future RSE) work informally with ADs and WG chairs when we see a potentially large cluster forming, or worse when a document is about to link two normal sized clusters into a big one. From nobody Tue Jul 21 21:47:49 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9DE3A0DA6 for ; Tue, 21 Jul 2020 21:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGxRBrTUCE9g for ; Tue, 21 Jul 2020 21:47:45 -0700 (PDT) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 C1A703A0DA4 for ; Tue, 21 Jul 2020 21:47:45 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id s26so535083pfm.4 for ; Tue, 21 Jul 2020 21:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=/1hQgJPaRGxKMDwWhCYYZanDfRwFpAV/L/ixvkVDQ+8=; b=k4Cj5bjU3Sg31TL/Rcx1OuPu8F+HzrBch7OEXd+0STRfbRRuIgdEuLwfgge5BEhsb0 HVKuxDqg6ytJGuWot7GUYz0VTlYxc+sJ2JrTsMZQqlLeufMKivAbtek3868JrYfKjGcQ fiuXqia7Vl5KxNCEiaf5601EoxxVYj4jjwzHAXvtpp/LkPTKDC7IktMuMSvkJOsaLeKa VC38CyKlmk0EPm6gRpj06kxpt1GdJjCnLdpprJ9JZidKYMxBAZ7oCPgMZ6yM8Wrhm8oc h8O4z43J18ZQnvYVAj51IdUktOB49BVyFXRTpcDD/uIC4J5WMdhrnCSPUzqWRWZGEJs/ nW5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/1hQgJPaRGxKMDwWhCYYZanDfRwFpAV/L/ixvkVDQ+8=; b=iSsKDQ4FDrWWWkB3q/romtFOgnN2OW/Rcrr3AeSjuGOwQGznQhj9qcsLj6Tq6D+0ht gjhVX3+YvFGsvBb3DHbIeueQe1bw/WUaqcDSIaNiVFpdEKttv6l4bmi0YxM4oRuhqXNk T3Mo9JeQlgqyCr47jnQE8W538sPJKKcrsK4HVUNrgGBMZAhVJ9ImioS2bbDdOWRf37aY 5Kjmdq34Yoj4JWKNkbMt7V6gMN+vYm3JCBRdc+YKMXDFpsP2DgJ03FroSZ2PunYZzaV7 KasWFpOEkoZLGwyAqjCus4H1vYrJTtNv2SEd+FXhQPYG87xETHYqxHJD5ZFVmKioRMU7 MWzw== X-Gm-Message-State: AOAM531H0KiZjr80aeoMFheoWwHzNDwCzeTpPHFwxHVQZa7Mwy4mavLL E9fYC3yC9tgzUPGqrtiCC2KG7Cxb X-Google-Smtp-Source: ABdhPJyn6dbTapeRCp2HdP1mHPI8wXiDMuWhNabFYYkPmoTp2Bu4QD0tuRW8eZUDHhFwevcj/eftHg== X-Received: by 2002:a62:7847:: with SMTP id t68mr28032907pfc.112.1595393264677; Tue, 21 Jul 2020 21:47:44 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id c187sm21494461pfc.146.2020.07.21.21.47.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2020 21:47:43 -0700 (PDT) To: John Levine , architecture-discuss@ietf.org References: <20200722040028.728C81D5EB94@ary.qy> From: Brian E Carpenter Message-ID: <0355ce38-cb6d-d4da-52e0-6176e529ca5f@gmail.com> Date: Wed, 22 Jul 2020 16:47:41 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200722040028.728C81D5EB94@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] clusterpation, was Proposed IAB program: Evolvability, Deployability , & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 04:47:48 -0000 Hi John, On 22-Jul-20 16:00, John Levine wrote: > In article you write: >> Because (for reasons I don't understand) I'm involved in AUTH48 processing >> for RTCWeb, I find myself wondering whether the proposed IAB program might >> include considering ways to avoid C-238-style protocol specification >> clusters, whether from the point of view of architectural oversight, >> standards process oversight, or RFC Editor oversight. > > I think we all agree that we don't ever want to see another document > cluster as large or as long-lived as C238. > > But I would rather not attempt to invent processes to try and guess > how best to prevent hypothetical superclusters. I'd rather that the > RPC and I (or a future RSE) work informally with ADs and WG chairs > when we see a potentially large cluster forming, or worse when a > document is about to link two normal sized clusters into a big one. That would be wise, but by the time anybody notices, it may be too late. I do agree that the answer is not to add more process. The question on the table, I think, is what factors lead to the formation of such a cluster, and what design issues should be considered to avoid it? (Plus the old newtrk question: how can we document clusters of documents usefully for implementers and operators?) Brian From nobody Wed Jul 22 07:18:44 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408F93A09F4 for ; Wed, 22 Jul 2020 07:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=eQShBb+X; dkim=pass (1536-bit key) header.d=taugh.com header.b=tKIxxOgs 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 SqcV0ae3U2Ud for ; Wed, 22 Jul 2020 07:18:41 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 CC59F3A09D1 for ; Wed, 22 Jul 2020 07:18:40 -0700 (PDT) Received: (qmail 19990 invoked from network); 22 Jul 2020 14:18:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=4e14.5f184abe.k2007; i=johnl-iecc.com@submit.iecc.com; bh=EapTqN1xlHuh7cVD8BeJXE1Zs/PvJ9KCIT2qQF4Pgz0=; b=eQShBb+XOpx1BZll2eQX0W7408xf9ro7vFvyibppiwdSj2xaa5bjLg8k/I6sD6Bdu1VzIbDE3kpUyT7jNP+cMYm9GbTfHAXBzelja6r2h9dNYSDv+KyObAr1JMQ4YTxxbTN2RsWD3WdB5hUP4mZpc1dFVSrkKTaxhkZCZvyQxyGcP8wt5LSWJPLtVfeDjUnCjehIJkdxwMzpYu83egiom3OSqwtVXtBKHCkc5Ysg7rCI5EmZmzkM6bwOQd/vtKpd DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=4e14.5f184abe.k2007; olt=johnl-iecc.com@submit.iecc.com; bh=EapTqN1xlHuh7cVD8BeJXE1Zs/PvJ9KCIT2qQF4Pgz0=; b=tKIxxOgsT/Ku86YMW6XvwDUdig2gZWlQRToWI8K233cseSUVA7Z/NOjgEkysPZPPNW658n+bP44jT4wQF5SmvjIbJh7W2OrMqvV+0waAYaVx1IBxQruevzTCqHnjQ2VKhClnCypfMuUVymnuLCOQ9iGI03D/U/C981wBpx/OF3+ug8Z9nR/6qxgui+F+ykPX6wGo8CfV0WjVtAyLGJIO79td+SzNyCiiTzOl3M1iMTnGUoVbW4J+WXdWVbjTiwKA Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 22 Jul 2020 14:18:38 -0000 Date: 22 Jul 2020 10:18:38 -0400 Message-ID: From: "John R Levine" To: "Brian E Carpenter" , architecture-discuss@ietf.org In-Reply-To: <0355ce38-cb6d-d4da-52e0-6176e529ca5f@gmail.com> References: <20200722040028.728C81D5EB94@ary.qy> <0355ce38-cb6d-d4da-52e0-6176e529ca5f@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [arch-d] clusterpation, was Proposed IAB program: Evolvability, Deployability , & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 14:18:43 -0000 On Wed, 22 Jul 2020, Brian E Carpenter wrote: >> I think we all agree that we don't ever want to see another document >> cluster as large or as long-lived as C238. ... >> >> But I would rather not attempt to invent processes to try and guess >> how best to prevent hypothetical superclusters. ... > That would be wise, but by the time anybody notices, it may be too late. The RPC certainly knows how big the clusters are. I've asked them to tell me if they notice any getting large. > The question on the table, I think, is what factors lead to the formation > of such a cluster, and what design issues should be considered to avoid it? Nothing exotic, it's a bunch of drafts with interlinked cross-references. If I saw that happening, I'd try and do a topological sort and see if some of them can get un-linked, or at least if the linked ones can progress together. The reason C238 gpt so big is that there were drafts in the queue that had references to other drafts that weren't done until two years later. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Jul 22 08:11:19 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C593A0888 for ; Wed, 22 Jul 2020 08:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 38ULbPXisigt for ; Wed, 22 Jul 2020 08:11:16 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC9A3A086C for ; Wed, 22 Jul 2020 08:11:15 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 44651548068; Wed, 22 Jul 2020 17:11:10 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 39DE3440043; Wed, 22 Jul 2020 17:11:10 +0200 (CEST) Date: Wed, 22 Jul 2020 17:11:10 +0200 From: Toerless Eckert To: John R Levine Cc: Brian E Carpenter , architecture-discuss@ietf.org Message-ID: <20200722151110.GM13675@faui48f.informatik.uni-erlangen.de> References: <20200722040028.728C81D5EB94@ary.qy> <0355ce38-cb6d-d4da-52e0-6176e529ca5f@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] clusterpation, was Proposed IAB program: Evolvability, Deployability , & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 15:11:19 -0000 Obviously we could invent a new RFC publication status like "conditional", so anything with unresolved normative references gets first published as a conditional RFC having a new normative section of conditional normative dependencies, pointing to the draft versions. As soon as ALL the required normative references exist as RFCs too, they are all updated in status from conditional to whatever their ultimate target status was. Cheers Toerless On Wed, Jul 22, 2020 at 10:18:38AM -0400, John R Levine wrote: > On Wed, 22 Jul 2020, Brian E Carpenter wrote: > > > I think we all agree that we don't ever want to see another document > > > cluster as large or as long-lived as C238. ... > > > > > > But I would rather not attempt to invent processes to try and guess > > > how best to prevent hypothetical superclusters. ... > > > That would be wise, but by the time anybody notices, it may be too late. > > The RPC certainly knows how big the clusters are. I've asked them to tell > me if they notice any getting large. > > > The question on the table, I think, is what factors lead to the formation > > of such a cluster, and what design issues should be considered to avoid it? > > Nothing exotic, it's a bunch of drafts with interlinked cross-references. If > I saw that happening, I'd try and do a topological sort and see if some of > them can get un-linked, or at least if the linked ones can progress > together. The reason C238 gpt so big is that there were drafts in the queue > that had references to other drafts that weren't done until two years later. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Wed Jul 22 08:38:15 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B453A097F for ; Wed, 22 Jul 2020 08:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=b2JOLXGp; dkim=pass (1536-bit key) header.d=taugh.com header.b=NnCZewlH 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 qKrGayFN2_eU for ; Wed, 22 Jul 2020 08:38:11 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 B931E3A092E for ; Wed, 22 Jul 2020 08:38:10 -0700 (PDT) Received: (qmail 73438 invoked from network); 22 Jul 2020 15:38:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=11edc.5f185d60.k2007; i=johnl-iecc.com@submit.iecc.com; bh=GhKQWeRiNqmVTTtwEIje49n5EpXekjIb3JpvJh4kcCs=; b=b2JOLXGpuz1TfDCztwzwTTTAMAW0JyHwFlYRx8nfdv7yW7mNpRej/Hbf4cUVjzH17d235G4O2rpIf7SAxl7N7QUWNgnPQxqJxK56Zbw/7S7+RItYGZyjFfipSaoYOVE4cqaEQyE5/oLtupUqupBMSzyZ9RvzFfY0+g3EFBv/RpWrE62wm+z4mH6cnLzXEV8Qgr6n14GGcWvLwAMjQtI+UrVsz0R5yGNCPuRsW5qQdfO4LKnNMQmmABbAEKGtyF4h DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=11edc.5f185d60.k2007; olt=johnl-iecc.com@submit.iecc.com; bh=GhKQWeRiNqmVTTtwEIje49n5EpXekjIb3JpvJh4kcCs=; b=NnCZewlHptEzHFb2Ta/HewTU/N17TjcL+pJjzTvHTA1oxJwyEANr6duAyFHkd0IfFPlh7YLN2xbe6YE8haX3oxfyrYY7De7RCzywUrbdm8RMUd+hHO+o4aLRdYUh9rNmmf3J7Upwcua5+ncnKfjKKVjXxq8YqRtb+FK/JayNkFicyffp0bPlrBfsk/YRkhvvVBiIVQXT1FMibPvkYFYiUs8JJuv7pYAXIKV0ClWr76CpDu5xHF9NEOiDxqRtpFJI Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 22 Jul 2020 15:38:08 -0000 Date: 22 Jul 2020 11:38:07 -0400 Message-ID: From: "John R Levine" To: "Toerless Eckert" Cc: "Brian E Carpenter" , architecture-discuss@ietf.org In-Reply-To: <20200722151110.GM13675@faui48f.informatik.uni-erlangen.de> References: <20200722040028.728C81D5EB94@ary.qy> <0355ce38-cb6d-d4da-52e0-6176e529ca5f@gmail.com> <20200722151110.GM13675@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [arch-d] clusterpation, was Proposed IAB program: Evolvability, Deployability , & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 15:38:13 -0000 > Obviously we could invent a new RFC publication status like "conditional", > so anything with unresolved normative references gets first published > as a conditional RFC having a new normative section of conditional > normative dependencies, pointing to the draft versions. > > As soon as ALL the required normative references exist as RFCs too, > they are all updated in status from conditional to whatever their > ultimate target status was. If we're going to republish RFCs I would rather address the general versioning question rather than just this special case. But for this special case, I still think a better route is to push WGs to deal with drafts in an order that doesn't produce huge clusters. Some of the drafts in C238 were so old that I worry that the world may have changed while the drafts snoozed. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Jul 22 09:19:24 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83D83A0A82 for ; Wed, 22 Jul 2020 09:19:22 -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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 (1024-bit key) header.d=btconnect.onmicrosoft.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 kWnMYrHLLNlh for ; Wed, 22 Jul 2020 09:19:21 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130108.outbound.protection.outlook.com [40.107.13.108]) (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 BA0293A0A80 for ; Wed, 22 Jul 2020 09:19:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QijxZRzh3cYClRonGXrS7l7oFfPyfQ7JLlFPBcFzUzrfmw1Ll+ZCPOTWo2+iBdl90zWvG+HM0TMw959YcggK6JR0qWhh5mbVTRI38PBkCV1MDITgYNPHTUnrgceUkzT80FWgIEdbUpA4d19GVxGEF+fsC9Qvy5GwLTtkuhZXqPt7f7alchhVagwA1/eCwbX7Xm2gWdUEZbrjqHGUMufNuDC/mRNo7/yE58OiWcBcjjm7ukcMIpmJIU+d9wTv4pKZIhXQC3R7HAlpvng8jdP/KIFik3rGYSpZ6aDZ2IhRgxDUxQVL0K0aoOtTz6tz+EulI7fUZGSdk468QIO+LXIH6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4A7CpM5PlzNxu8B7ZTG1Zzua/sM9WODeDIrmDjZ9o8A=; b=C8idyArHYTn5kYnpl/3y3L0gJ1KW0zOJvYaMLHG7xo+qmJcBoAs1azihtX1uJFoXxzUM0stoL7WaAXTAPg+aF9jyltP37f+dxT+QN/ikz7ouzoXJaFb5EX0eCW+Quuor5/OE+Gf4Mf4ErD9H2pcr+EGMjVTwe0xS1XXYmH4qJyTt7jx8a0rkBS03/EX7HXan2VQnpVo73duA+7K7MDkQpcFC+mlegUEfuu2UoXRz8aTW55m0Ut/HGAtyl6h5wjqEv+57kXELBt3kXW/JrIBX7yEzdrUadGLiajAJxcvPc7sBG4LcNstSL6tsP3quECBHDovphr47jITRutaAZrmtVg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4A7CpM5PlzNxu8B7ZTG1Zzua/sM9WODeDIrmDjZ9o8A=; b=MunWTWWXJCA1gw39GsEuAU16Pmzz4RLt+VsqUdi88aPc/ZD5SE4IH39feqRCzSC49MKb4eNC0zjkJVCEZCRgOgosrjKr2vL+HOYm+JzxsXEMfnM+RRwuHjFduZfikfnMXStB38HGiFW0X+0v9yey0H8yPX41GXqWdk0a/fSoMrY= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB4677.eurprd07.prod.outlook.com (2603:10a6:20b:25::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.17; Wed, 22 Jul 2020 16:19:17 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::893c:ca97:acbf:1c76]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::893c:ca97:acbf:1c76%5]) with mapi id 15.20.3216.020; Wed, 22 Jul 2020 16:19:17 +0000 From: tom petch To: John R Levine , Toerless Eckert CC: "architecture-discuss@ietf.org" Thread-Topic: [arch-d] clusterpation, was Proposed IAB program: Evolvability, Deployability , & Maintainability. Thread-Index: AQHWX9yufhb4dC+OhkmyXClMNYSfFKkTBr2AgACfhQCAAA6uAIAAB4eAgAAIpyw= Date: Wed, 22 Jul 2020 16:19:17 +0000 Message-ID: References: <20200722040028.728C81D5EB94@ary.qy> <0355ce38-cb6d-d4da-52e0-6176e529ca5f@gmail.com> <20200722151110.GM13675@faui48f.informatik.uni-erlangen.de>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: taugh.com; dkim=none (message not signed) header.d=none;taugh.com; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [81.131.229.35] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9b4f8631-5d1b-4abc-4b42-08d82e5afbaa x-ms-traffictypediagnostic: AM6PR07MB4677: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cF6Ew1FhjWVcH7pemG8RjuDAC0tM7lDL5/4x5YHiPBlEgXQoVw0rgsGNRzOTVFQZmbyHLf+00it7goitZ5P0622/tnltFqGbIPwMKzPqC3SX1XzpgW4VFGaBij4SHe+8rIgHOgCqURLhUc9kpn8g+KiekGGJyLe40FhP2RyAK/qW1MvdeqwqTFYjVi22vC1kLTkoydJUxHcrJYGfd48FVlnzYUI+uxGIaaUHic4O0svdRW5gHmT6m1PuYY7kvfL3vDxWuyC5kKjPjorFR31vgDHCK9jRuoWRQXIaY+b5Wxy5o6hdkG1GkgFWuSb4PQ8QGo+J2lt9PooY5Knen6ak6xSfQTXx58uQ3AtJF7k/V0amRlWfSJsHoX21GzuWdXRJtloTCTSf56602pIqH20QTg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(366004)(39860400002)(346002)(396003)(376002)(4326008)(86362001)(76116006)(6506007)(186003)(66446008)(71200400001)(66946007)(66556008)(66476007)(966005)(91956017)(64756008)(8936002)(26005)(83080400001)(83380400001)(9686003)(316002)(55016002)(478600001)(8676002)(52536014)(2906002)(7696005)(33656002)(5660300002)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: y813/p974om6oJ2qsorwHiEf2xzPh++U5ZXeNybOCh0tKkWeF9RUHixCUA4NcPy1XiqIwhzEEUZpTazZZRvfd1mhY5WvyhybnOqeOvulYiTF7+eZVGNWyqLOONHggzfz0TOcG5lzLLG9OEdW5g5pRgD8+FUZutx2p0LhEEprRaxDt5PsGFgvplPwA6dLtzb4u3bxJiXUSYDVF7IlcbPesDs86eFEotU+fgnO6w8wJVG4eysAt1+24N1vcTUXR58R/wO549uTAvRBp1RyPEebOlUTtZa0w8lY5ePjpjW1R5i+P1S2P5A9fUu8erN1PcFEyi8f6mSP4T8HWKyMkQDcsvzJSZ3A7KBprvFkUlTbUVx/HHQ7wxJ4EKIBLcUOf6nMq4xDeQdTSB5r2DISxgzCJlfvnpL8MhOXyNpMONZRSglMCZr5+KZ+bgyAgwLEn1TICGbyg2BrOs8CQD6F2R+KK245wlEBb/317MYDY6F/Nf1795LWslcLCMiGvLIykmA5 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9b4f8631-5d1b-4abc-4b42-08d82e5afbaa X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 16:19:17.6653 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6Z83fuZB4YOALgfUx5ZFUshzEL3+C11GiPWz6h604XjPgktkGGp2Qwp7R6e3Zir6pfqT3plJ8ad0kCIwhnPwSw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4677 Archived-At: Subject: Re: [arch-d] clusterpation, was Proposed IAB program: Evolvability, Deployability , & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 16:19:23 -0000 From: Architecture-discuss on behal= f of John R Levine =0A= Sent: 22 July 2020 16:38=0A= =0A= > Obviously we could invent a new RFC publication status like "conditional"= ,=0A= > so anything with unresolved normative references gets first published=0A= > as a conditional RFC having a new normative section of conditional=0A= > normative dependencies, pointing to the draft versions.=0A= >=0A= > As soon as ALL the required normative references exist as RFCs too,=0A= > they are all updated in status from conditional to whatever their=0A= > ultimate target status was.=0A= =0A= If we're going to republish RFCs I would rather address the general=0A= versioning question rather than just this special case. But for this=0A= special case, I still think a better route is to push WGs to deal with=0A= drafts in an order that doesn't produce huge clusters.=0A= =0A= Some of the drafts in C238 were so old that I worry that the world may=0A= have changed while the drafts snoozed.=0A= =0A= =0A= I have not looked at C238 but I do know of a draft I worked on that is awai= ting progress on a Normative Reference which will fail because the world ha= s changed. This is a cross-WG issue where one WG sets out to provide somet= hing useful, others use it and then the something really useful changes in = nature and becomes unusable.=0A= =0A= This could happen with YANG common types modules. Some WG have recognised = that types needs several iterations to get right and so have held the types= back until at least one using module is ready to advance with it which the= n reduces the risk. Others just duplicate the definitions they want which = can cause other issues.=0A= =0A= Tom Petch=0A= Regards,=0A= John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY=0A= Please consider the environment before reading this e-mail. https://jl.ly= =0A= =0A= _______________________________________________=0A= Architecture-discuss mailing list=0A= Architecture-discuss@ietf.org=0A= https://www.ietf.org/mailman/listinfo/architecture-discuss=0A= From nobody Wed Jul 22 09:54:24 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42143A0B72 for ; Wed, 22 Jul 2020 09:54:17 -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 h95lkI6jIp9S for ; Wed, 22 Jul 2020 09:54:16 -0700 (PDT) Received: from bsa3.jck.com (bsa3.jck.com [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A623A0B5F for ; Wed, 22 Jul 2020 09:54:16 -0700 (PDT) Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jyI0O-0002cq-9N; Wed, 22 Jul 2020 12:54:08 -0400 Date: Wed, 22 Jul 2020 12:31:15 -0400 From: John C Klensin To: Stephen Farrell cc: Brian E Carpenter , Tommy Pauly , architecture-discuss@iab.org Message-ID: <77B3675F78E81E1ECE1DD4B6@JcK-HP5> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Archived-At: Subject: Re: [arch-d] Proposed IAB program: Evolvability, Deployability, & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 16:54:24 -0000 Stephen and Tommy, Sorry it has taken me so long to get to this, but, at least from my perspective, your question (if I understand it correctly) has some interesting answers. These are my opinions only but it may be worth noting that, although I helped with RFC 1123 and was involved in other ways much earlier, I was dragged into the IETF precisely to work on email protocols. Inline below. --On Tuesday, 07 July, 2020 02:14 +0100 Stephen Farrell wrote: > > Hi Brian, > > (Maybe not directly a question for you but...) > > On 06/07/2020 23:05, Brian E Carpenter wrote: >> SMTP has been the classical example for many years, and I >> suspect that RTCWEB might furnish another good example of >> this problem before long. > Do we have evidence as to the (good, bad or neutral) impact > of the stately pace of the evolution of email standards- > track RFCs? I could imagine the net effect being overall > positive or negative but am unsure which may be the case. I > suspect it may be more likely that the actual impact is not > correlated with RFC numbers at all, but that may also be > wrong. Once upon a time, it was a maxim of ARPANET and Internet protocol design that things were to be kept simple, with a minimum of options, alternate ways to do the same thing, and so on. Part of that was (or became) a deliberate contrast with a well-known reference model and protocol suite that were so full of options and variations that almost no one could implement them and it was impossible to tell whether failure to interoperate was a bug or the result of, e.g., difference choices of options or profiles. The designers of Internet email had the added advantage of experience with email systems that served users on a single host and some that served a set of related hosts running the same operating system software even before the mail command was introduced into FTP. Even the envelope-header split came rather last in the game. The implication of that was that, by the time RFCs 821 and 822 came along and the former was followed by RFc 974, they were based on years significant implementation, deployment, and user experience, including experience with gateways, _and_, by today's standards, they were still rather simple protocols. The changes of the early 1990s were necessitated by new requirements -- for multilingual and multimedia mail and for the ability to do a number of things that the original protocols did not facilitate doing in an interoperable way.. and to do so in a way that would not break the existing widely-deployed infrastructure. Even then we made what may have been design errors (or not). For example, in allowing extensions we failed to distinguish clearly between "I, the server, am offering these extensions" and "I the server will not accept your mail unless you support these extensions" and, in MIME, we specified a header field of "MIME-version: 1.0" without any non-destructive plan about what a different number might mean. The next two iterations were just consolidation of multiple specifications and clarifications. And the work now being contemplated (see the "emailcore" BOF on the IETF 108 agenda) is intended to be limited to clarifications and fixing errors and we just haven't felt pressure to do it much earlier. IMAP, for example, is different -- more options, more commands, and more working groups adding yet more options. Now, contrast that situation with, e.g., SIP, HTTP/HTTPS, or RTCweb and, well, it is an interesting contrast. I hope everyone participating in this discussion has read Fred Brooks on second system effects and perhaps thought a bit about what it means to patterns of standards development. john From nobody Wed Jul 22 10:09:20 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E6B3A0B5F for ; Wed, 22 Jul 2020 10:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toQICO9N3Foq for ; Wed, 22 Jul 2020 10:09:16 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DDC3A0B58 for ; Wed, 22 Jul 2020 10:09:16 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D3752548068; Wed, 22 Jul 2020 19:09:10 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id CDEE5440043; Wed, 22 Jul 2020 19:09:10 +0200 (CEST) Date: Wed, 22 Jul 2020 19:09:10 +0200 From: Toerless Eckert To: tom petch Cc: John R Levine , "architecture-discuss@ietf.org" Message-ID: <20200722170910.GO13675@faui48f.informatik.uni-erlangen.de> References: <20200722040028.728C81D5EB94@ary.qy> <0355ce38-cb6d-d4da-52e0-6176e529ca5f@gmail.com> <20200722151110.GM13675@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] clusterpation, was Proposed IAB program: Evolvability, Deployability , & Maintainability. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 17:09:19 -0000 Thanks, Tom, inline On Wed, Jul 22, 2020 at 04:19:17PM +0000, tom petch wrote: > From: Architecture-discuss on behalf of John R Levine > Sent: 22 July 2020 16:38 > > > Obviously we could invent a new RFC publication status like "conditional", > > so anything with unresolved normative references gets first published > > as a conditional RFC having a new normative section of conditional > > normative dependencies, pointing to the draft versions. > > > > As soon as ALL the required normative references exist as RFCs too, > > they are all updated in status from conditional to whatever their > > ultimate target status was. > > If we're going to republish RFCs I would rather address the general > versioning question rather than just this special case. Maybe use the cluster problem case as a test balloon for generic versioning, aka: Lets not create a meta clustet, where the initial benefit of solving the cluster problem has to wait for the last open question on versioning to be resolved first. > But for this > special case, I still think a better route is to push WGs to deal with > drafts in an order that doesn't produce huge clusters. I think everybody will tell you that this is not possible in general than how we deal with it this today. You can not simply re-assign authors to first help finishing other documents. We are a community of arbitrary specialization. > Some of the drafts in C238 were so old that I worry that the world may > have changed while the drafts snoozed. Sure, but if this document would not have been pat of a cluster but been published years ago as standard RFC it could be equally obsolete now technically. Aka: do not raise requirements of usefulness against cluster members over those RFCs that are not cluster members. Heck, i am still trying to find time to go through all the IETF process to downgrade 1989 IGMPv1 protocol from full standard to eg historic and upgrade 2002 IGMPv3 to full standard. Aka: if you wanted to bring in more applicability requirements against clusters you just worsen the problem. Cheers Toerless > > I have not looked at C238 but I do know of a draft I worked on that is awaiting progress on a Normative Reference which will fail because the world has changed. This is a cross-WG issue where one WG sets out to provide something useful, others use it and then the something really useful changes in nature and becomes unusable. > > This could happen with YANG common types modules. Some WG have recognised that types needs several iterations to get right and so have held the types back until at least one using module is ready to advance with it which then reduces the risk. Others just duplicate the definitions they want which can cause other issues. > > Tom Petch > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Tue Jul 28 05:24:15 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C49D3A0BF8 for ; Tue, 28 Jul 2020 05:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7gy1xHlQ9FR for ; Tue, 28 Jul 2020 05:23:31 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F393A0BCE for ; Tue, 28 Jul 2020 05:23:30 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A3438548048; Tue, 28 Jul 2020 14:23:24 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9988F440043; Tue, 28 Jul 2020 14:23:24 +0200 (CEST) Date: Tue, 28 Jul 2020 14:23:24 +0200 From: Toerless Eckert To: iab@iab.org Cc: architecture-discuss@ietf.org Message-ID: <20200728122324.GE1772@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [arch-d] 2 questions (groups) to IAB X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 12:23:37 -0000 Dear IAB, Q1: Community discussion with IAB about their workshop/programs Could the IAB please present a short statement about how the IAB decides what workshops to run and when to start a new program? Would the IAB be open to receiving suggestions from the community, and how would those suggestions be handled? Q2: IAB and evolving IP IETF chair has declared in liaison 1677, that "IETF maintains copyright and change control for the IP specifications" and "extensions or modifications to IETF technologies must be discussed with the IETF before any are worked on in other SDOs". In addition, IAB is chartered with external liaison and architectural oversight. With this role, i would respectfully like to ask IAB about he following issue: There is interest from contributors working inside IETF as well as outside researchers and SDO such as ITU-T to investigate options for future IP/network layer packet/protocol evolution withing but also beyond those options that could naturally evolve from the considerations of RFC4775. This could be seen as similar to what was done 30 years ago in IP-NG through e.g.g: TUBA, TP/IX, CATNIP, IPAE, SIP, PIP and so on. Except that the requirements for such investigations are different from those in 1990th (IPv4 address space exhaustion). For example the networks to which the desired benefits might most apply would not necessarily have to be primarily the Internet. What is in the opinion of IAB the right place to do this work in the community, e.g., IAB workshop/program, IETF experimental WG, some other new org form ? How does IAB think it should be involved in such an effort ? Note: IRTF chair has already stated that he considers architecture investigation into generic network header encoding options as a pure engineering and therefore non-research topic and thinks it is unsuitable for an IRTF RG. I disagree, but that was his statement he made to me. Lastly: Where can i find the definition as to what packet protocol formats would or would not fall into the IETF chairs "IETF ... copyright and change control for the IP specifications" ? E.g.: would any newly designed protocol be subject to IETF copyright claims if it can be made interoperable in some fashion with IPv4 or IPv6 ? Or is it just the naming aspect of "InternetworkProtocol" ? I do not understand the assessment criteria. This question is quite important because without such definition, it is impossible to determine which proposed protocols Alissas liaison 1677 ask against other SDO applies to. Thank you very much Toerless Eckert From nobody Tue Jul 28 07:13:31 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AB53A0CB3; Tue, 28 Jul 2020 07:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=csperkins.org 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 npcC0sVTdQqL; Tue, 28 Jul 2020 07:13:24 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 4F9663A0CB1; Tue, 28 Jul 2020 07:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=RHC5OkFTR1WnZKf7u8E7HQr/QWrwHuZZCd/m/eDPV1s=; b=v7f3JLiHJMyEb22foR/SfShR7H Ys7PJIZwtwQWhEzvfVTY4V3PExzuqX4cGBnkM+fCUds4uDJOwAsNqfPFooLQSp1sUmGh7YWFTrMd7 ShLcwL9A4O6nx5zRlPhInlE+uC2XvF/L/0kgEgPjKGWrygvV79Yyo58evlit08/hilHGiPgDZQZp7 lzRoweTrFBGU9t+oWE4uWk/qR9zD8/I2QG9uRnTmcSOGeEvy3KL8gPeXuiciZugl8smBZ2HFPhFhE OVrMMXpXK244jNVVdOteQamYDHT2hvxN33iOGzIUhzv+VgtuxGNjflYuqsYXrk5BZ8/xAE+ElfWMF aVR017Hw==; Received: from [81.187.2.149] (port=44356 helo=[192.168.0.80]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1k0QM6-0002JA-FC; Tue, 28 Jul 2020 15:13:22 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Colin Perkins In-Reply-To: <20200728122324.GE1772@faui48f.informatik.uni-erlangen.de> Date: Tue, 28 Jul 2020 15:13:08 +0100 Cc: iab@iab.org, architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3F1656D3-DDC6-4E46-9BF7-C99B39167CC8@csperkins.org> References: <20200728122324.GE1772@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.104.15) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [arch-d] 2 questions (groups) to IAB X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 14:13:26 -0000 > On 28 Jul 2020, at 13:23, Toerless Eckert wrote: >=20 > Dear IAB, >=20 > Q1: Community discussion with IAB about their workshop/programs >=20 > Could the IAB please present a short statement about how the IAB = decides > what workshops to run and when to start a new program? Would the IAB = be =20 > open to receiving suggestions from the community, and how would those > suggestions be handled? >=20 > Q2: IAB and evolving IP >=20 > IETF chair has declared in liaison 1677, that "IETF maintains = copyright > and change control for the IP specifications" and "extensions or = modifications > to IETF technologies must be discussed with the IETF before any are = worked > on in other SDOs". In addition, IAB is chartered with external liaison = and > architectural oversight. With this role, i would respectfully like to = ask > IAB about he following issue: >=20 > There is interest from contributors working inside IETF as well as > outside researchers and SDO such as ITU-T to investigate options for > future IP/network layer packet/protocol evolution withing but also = beyond > those options that could naturally evolve from the considerations of = RFC4775. >=20 > This could be seen as similar to what was done 30 years ago in IP-NG = through > e.g.g: TUBA, TP/IX, CATNIP, IPAE, SIP, PIP and so on. Except that the > requirements for such investigations are different from those in = 1990th > (IPv4 address space exhaustion). For example the networks to which the > desired benefits might most apply would not necessarily have to be = primarily > the Internet. >=20 > What is in the opinion of IAB the right place to do this work in the = community, > e.g., IAB workshop/program, IETF experimental WG, some other new org = form ? > How does IAB think it should be involved in such an effort ? >=20 > Note: IRTF chair has already stated that he considers architecture = investigation > into generic network header encoding options as a pure engineering and = therefore > non-research topic and thinks it is unsuitable for an IRTF RG. > I disagree, but that was his statement he made to me. We had a single hallway conversation about this topic at the Singapore = IETF 106 meeting. What I recall saying was that I thought the specific = topic you raised was better suited to a longer-term engineering effort = in IETF than to an IRTF research group, not that the broader topic was = forever out of scope for IRTF.=20 Colin > Lastly: Where can i find the definition as to what packet protocol > formats would or would not fall into the IETF chairs "IETF ... = copyright > and change control for the IP specifications" ? E.g.: would any newly > designed protocol be subject to IETF copyright claims if it can be > made interoperable in some fashion with IPv4 or IPv6 ? Or is it just > the naming aspect of "InternetworkProtocol" ? I do not understand > the assessment criteria.=20 >=20 > This question is quite important because without such definition, > it is impossible to determine which proposed protocols Alissas liaison = 1677 > ask against other SDO applies to. >=20 > Thank you very much > Toerless Eckert >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --=20 Colin Perkins https://csperkins.org/ From nobody Tue Jul 28 09:17:10 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206973A0E7E; Tue, 28 Jul 2020 09:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5QUsl-7i1RK; Tue, 28 Jul 2020 09:17:07 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 25A143A0E7D; Tue, 28 Jul 2020 09:17:07 -0700 (PDT) Received: from lhreml709-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C1890D1A6C17CEFE7000; Tue, 28 Jul 2020 17:17:05 +0100 (IST) Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 28 Jul 2020 17:17:05 +0100 Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Tue, 28 Jul 2020 17:17:05 +0100 Received: from DGGEMM512-MBS.china.huawei.com ([169.254.4.82]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0487.000; Wed, 29 Jul 2020 00:17:01 +0800 From: Lizhenbin To: "architecture-discuss@ietf.org" , "rtgwg@ietf.org" CC: "daniel@olddog.co.uk" Thread-Topic: APN (Application-aware Networking) Side Meeting Thread-Index: AQHWZPd1Qwi8mWyXnkSiq0ifMf+ggg== Date: Tue, 28 Jul 2020 16:17:01 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D937F5509@dggemm512-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.181.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [arch-d] APN (Application-aware Networking) Side Meeting X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 16:17:09 -0000 Hi All, We will have the APN side meeting at 12:30 - 14:00 UTC on July 30 (Thursday= ). The agenda and the WebEx information is provided in the following link.= =20 https://github.com/APN-Community/IETF108-Side-Meeting-APN There has been several similar work like APN such as SPUD and PLUS. Recentl= y Network Token work was also proposed. The side meeting is to try to clari= fy the scope of APN comparing with other work. The possible usecases are al= so proposed for the APN work. Another goal of the side meeting is to clarif= y the security and privacy issues which are always proposed against such ap= plication-ware networking work. In RTGWG session held yesterday, the presen= tation of APN work discussed the possible scenarios related with the securi= ty and privacy issues. The following slides is for your reference: https://www.ietf.org/proceedings/108/slides/slides-108-rtgwg-8-rtgwg-apn6-0= 1 Since it is a complex cross-area work and there is much background informat= ion, wish you could join the side meeting if you have interest in the work = and your comments and suggestions are appreciated.=20 Best Regards, Daniel & Zhenbin (Robin)= From nobody Wed Jul 29 08:04:13 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5555F3A0C0D; Wed, 29 Jul 2020 08:04: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 8ULtz0nHYuKH; Wed, 29 Jul 2020 08:04:07 -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 0B5603A0BC8; Wed, 29 Jul 2020 08:04:06 -0700 (PDT) Received: from p200300dee7007a0000b2a48e6d6cd99d.dip0.t-ipconnect.de ([2003:de:e700:7a00:b2:a48e:6d6c:d99d]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1k0nch-00068L-UE; Wed, 29 Jul 2020 17:04:03 +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: <20200728122324.GE1772@faui48f.informatik.uni-erlangen.de> Date: Wed, 29 Jul 2020 17:04:03 +0200 Cc: IAB , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <52F9BDFE-7843-4366-BAD3-A5979B1F2AE5@kuehlewind.net> References: <20200728122324.GE1772@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3608.80.23.2.2) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1596035047;179c5c81; X-HE-SMSGID: 1k0nch-00068L-UE Archived-At: Subject: Re: [arch-d] [IAB] 2 questions (groups) to IAB X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 15:04:11 -0000 Hi Toerless, Thanks for your requests. Please see replies inline. > On 28. Jul 2020, at 14:23, Toerless Eckert wrote: >=20 > Dear IAB, >=20 > Q1: Community discussion with IAB about their workshop/programs >=20 > Could the IAB please present a short statement about how the IAB = decides > what workshops to run and when to start a new program? Would the IAB = be =20 > open to receiving suggestions from the community, and how would those > suggestions be handled? More information on IAB programs can be found on the IAB webpage: = https://www.iab.org/activities/programs/ As noted there, programs serve to support the IAB in their chartered = responsibilities. As such, programs as well as workshops are usually = created/hold based on discussion within the IAB. In past discussions we = have evaluated each program based on its merits, scope, energy levels = within the IAB and the community, and its likelihood of success. As I = also briefly mentioned in the IAB open meeting today, we in the IAB are = currently also discussing our own practices and procedures to establish = and work with and in those programs, and how best such programs can = engage with the IETF community. As such an update to the noted IAB page = is likely to come up at some future point. The IAB is always interested in community input on technical work the = IAB is currently doing as well as technical discussion on larger = architectural issues. Especially for the later the = architecture-discuss@iab.org list is the right place, not only for = community discussion but also to reach the IAB as IAB members are = participating on that list. Of course you can also always reach the IAB = directly, as you just did using iab@iab.org When we receive input from the community that requires further = discussion, we may do that in our business calls. Our calls (except the = executive sessions of course) are open for observers and the agenda is = published in advance on the IAB wiki. >=20 > Q2: IAB and evolving IP >=20 > IETF chair has declared in liaison 1677, that "IETF maintains = copyright > and change control for the IP specifications" and "extensions or = modifications > to IETF technologies must be discussed with the IETF before any are = worked > on in other SDOs". In addition, IAB is chartered with external liaison = and > architectural oversight. With this role, i would respectfully like to = ask > IAB about he following issue: >=20 > There is interest from contributors working inside IETF as well as > outside researchers and SDO such as ITU-T to investigate options for > future IP/network layer packet/protocol evolution withing but also = beyond > those options that could naturally evolve from the considerations of = RFC4775. >=20 > This could be seen as similar to what was done 30 years ago in IP-NG = through > e.g.g: TUBA, TP/IX, CATNIP, IPAE, SIP, PIP and so on. Except that the > requirements for such investigations are different from those in = 1990th > (IPv4 address space exhaustion). For example the networks to which the > desired benefits might most apply would not necessarily have to be = primarily > the Internet. >=20 > What is in the opinion of IAB the right place to do this work in the = community, > e.g., IAB workshop/program, IETF experimental WG, some other new org = form ? > How does IAB think it should be involved in such an effort ? The IAB used to have a program on IP Stack Evolution which was just = closed last year. Before that there was a program on IP Evolution. For = both concluded programs you can find further information about the scope = as well as published documents or other actives the program members were = involved with on the IAB webpage: = https://www.iab.org/activities/programs/concluded-programs/ip-stack-evolut= ion-program/ https://www.iab.org/activities/programs/concluded-programs/ip-evolution/ These programs were concluded as the intermediate goals of these = programs were reached. As also announced in the IAB open meeting = yesterday, the IAB is considering a to some extend follow-up new program = on Evolvability, Deployability, and Maintainability (EDM). For further = discussion on these aspects an new mailing list has been created: = edm@iab.org =46rom your description above the scope of the work you are interested = in seems rather broad. More generally speaking, the IAB aims to = stimulate discussion around architectural issues in the Internet that = are not always broadly recognised by the wider community, or that either = require more coordinations between areas or are not covered by active = work in the IETF. However, for questions related to a certain protocol = or groups of protocols where one or more IETF working groups already = exists, I recommend you that discussion should take place there to reach = out to the relevant part if the IETF community directly. >=20 > Note: IRTF chair has already stated that he considers architecture = investigation > into generic network header encoding options as a pure engineering and = therefore > non-research topic and thinks it is unsuitable for an IRTF RG. > I disagree, but that was his statement he made to me. >=20 > Lastly: Where can i find the definition as to what packet protocol > formats would or would not fall into the IETF chairs "IETF ... = copyright > and change control for the IP specifications" ? E.g.: would any newly > designed protocol be subject to IETF copyright claims if it can be > made interoperable in some fashion with IPv4 or IPv6 ? Or is it just > the naming aspect of "InternetworkProtocol" ? I do not understand > the assessment criteria.=20 >=20 > This question is quite important because without such definition, > it is impossible to determine which proposed protocols Alissas liaison = 1677 > ask against other SDO applies to. I believe this is a question for the IETF Chair to ask.=20 Best, Mirja >=20 > Thank you very much > Toerless Eckert >=20 >=20