Re: [Edm] [arch-d] New IAB Program: Evolvability, Deployability, & Maintainability (EDM)

Seems like point 1 should be ignoring pointless IAB programs.

There’s work to be done. This isn’t it.

Tony

> On Aug 25, 2020, at 2:47 PM, IAB Executive Administrative Manager <execd@iab.org> wrote:
> 
> A new IAB Program has been formed on Evolvability, Deployability, & 
> Maintainability (EDM). For additional information, please contact the 
> IAB or the Program Lead.
> 
> Evolvability, Deployability, & Maintainability (EDM) Program
> -----------------------------------------------------------------------
> 
> IAB Lead:
> Tommy Pauly <tpauly@apple.com>
> 
> Mailing list:
> Address: edm@iab.org
> To subscribe: https://www.iab.org/mailman/listinfo/edm
> Archive: https://mailarchive.ietf.org/arch/browse/edm/
> 
> 
> Program Page: https://www.iab.org/activities/programs/evolvability-deployability-maintainability-edm-program/
> 
> Program Description:
> 
> This program will focus on how to practically encourage best practices 
> within the IETF to ensure that the IETF’s standards process considers 
> protocol evolution, deployability, and long-term maintainability. This 
> group will work on documents that catalog and analyze successful 
> strategies for protocol evolution, deployment, and maintenance, such as 
> updating and extending RFC 6709. Moreover, it will focus on ways to help 
> promote and increase awareness of these strategies within the IETF via 
> program meetings, workshops, and helping organize efforts within working 
> groups and various IETF teams. The program will include members of the 
> IESG and the tools team to help implement these strategies.
> 
> The topics this group will consider include:
> 
> * Evolvability: Encourage protocols to design for extensibility and 
>  greasing, and promote the use of extension points to prevent 
>  ossification. Make it easy for people, especially those who aren’t 
>  steeped in IETF process, to know which extension points are the right 
>  ones to use for a given protocol (and which ones should be considered 
>  more stable/ossified), and make sure there aren’t high allocation 
>  barriers to use those extension points.
> 
> * Deployability: Focus on how we make “running code” something that is 
>  better integrated into the working group process. Look at methods to 
>  catalog implementations, tools for tracking interoperability testing 
>  on different protocol versions, or repositories of which versions of 
>  protocols are implemented and used on the Internet. Discuss how 
>  deployments can advertise experiments they are running.
> 
> * Maintainability: Many working groups have expressed a desire to have 
>  ways for the community of protocol designers and implementers to keep 
>  track of the current state of affairs in deployment patterns, known 
>  errata/bugs, or best practices. Help promote consistent ways to host 
>  non-RFC working group output, like FAQs, wikis, and discussion venues. 
>  Consider how this community involvement can continue and involve the 
>  right experts, even after a working group closes.
> 
> The program will:
> 
> * Engage with the IETF community and implementers outside of the IETF to 
>  identity successes and problem areas, and collect ideas for 
>  improvements.
> * Work with the IESG and directorates to determine how best practices 
>  for evolvability can best be applied during IESG review and IETF last 
>  call.
> * Work with the IESG and tools team on ways to connect implementers and 
>  communities that develop and maintain protocols, both while a working 
>  group is active, and after a working group has concluded its charter.
> 
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss