Re: [arch-d] Proposed IAB program: Evolvability, Deployability , & Maintainability.

Mary Barnes <mary.ietf.barnes@gmail.com> Tue, 21 July 2020 14:12 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
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 <architecture-discuss@ietfa.amsl.com>; 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 <architecture-discuss@ietfa.amsl.com>; 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 <architecture-discuss@ietf.org>; Tue, 21 Jul 2020 07:12:22 -0700 (PDT)
Received: by mail-pj1-x1035.google.com with SMTP id k5so1736615pjg.3 for <architecture-discuss@ietf.org>; 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> <fb397f5f-b792-4338-9112-a4a7a4d967c0@www.fastmail.com> <CAKKJt-fNX16Ap8afcg55DXj3DFb8mGYdB3MxHtLyyMN5a0eFLQ@mail.gmail.com>
In-Reply-To: <CAKKJt-fNX16Ap8afcg55DXj3DFb8mGYdB3MxHtLyyMN5a0eFLQ@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Tue, 21 Jul 2020 09:12:10 -0500
Message-ID: <CAHBDyN5dKqggUxcPiGVWdBrkjQtGTXi8in5B+1d7tFPt+08AuA@mail.gmail.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: Christopher Wood <caw@heapingbits.net>, architecture-discuss@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003d607a05aaf4365d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/L7ZGEcl_CT2GYzTdMAHtP_Z_jk8>
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 <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jul 2020 14:12:28 -0000

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 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 <caw@heapingbits.net>
> wrote:
>
>> Hi Tommy,
>>
>> I think this is a terrific idea. All three areas are certainly worth
>> exploring. 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,
>> 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’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
>>
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>