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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Mary,

On Tue, Jul 21, 2020 at 9:12 AM Mary Barnes <[e-mail]>
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 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.
>

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 <
> [e-mail]> 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 <[e-mail]>
>> 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
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/architecture-discuss
>>> >
>>>
>>> _______________________________________________
>>> Architecture-discuss mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>>>
>> _______________________________________________
>> Architecture-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>>
>