Subject: [admin-discuss] Conclusion of the IASA2 Retrospective

From: IETF Administration LLC Board of Directors Chair <[email-masked]>
Date: Mon, 01 Nov 2021 16:11:32 -0700

The IETF Administration LLC (IETF LLC) has now completed the IETF Administrative Support Activity (IASA 2.0) retrospective. The report was developed with community input and review and is now available online. For more details and a link to the report, please see the blog post at: 

https://www.ietf.org/blog/iasa2-retrospective-conclusion/

Jason Livingood
Board Chair, IETF Administration LLC 
[email-masked]

++++++++++ How to Contact the IETF LLC ++++++++++
Executive Director: [email-masked]  
Sponsorship: [email-masked] 
Board: [email-masked] 

++++++++++ General IETF LLC Board Background ++++++++++
About the IETF LLC: https://www.ietf.org/about/administration/
Meeting minutes: https://www.ietf.org/about/administration/llc-board/minutes/
Future meetings: https://www.ietf.org/about/administration/llc-board/meeting-info/
Financial statements: https://www.ietf.org/about/administration/financial-statements/

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Nov 2021 14:43:22 +1300

Thanks for this comprehensive report. I'd like to mention one point that came to my attention very recently. It's relevant to items 50 and and 56 in the report.

RFC 8711 says this:
"The IETF has a long history of community involvement in the execution of certain administrative functions, in particular development of IETF tools, the operation of the meeting network by the Network Operations Center (NOC), and some outreach and communications activities conducted by the Education and Mentoring Directorate. The IETF LLC staff is expected to respect the IETF community's wishes about community involvement in these and other functions going forward as long as the staff feels that they can meet the otherwise-stated needs of the community. Establishing the framework to allow the IETF LLC to staff each administrative function as appropriate may require the IETF community to document its consensus expectations in areas where no documentation currently exists."

(https://www.rfc-editor.org/rfc/rfc8711.html#section-5.1-5)

Do we have a clear mechanism for this - an organized community discussion leading to (rough) consensus followed by a request for resource assessment by the LLC? I'm quite aware of the tools-discuss list but it's the consensus-forming and the subsequent follow-up that seems unclear.

I don't mean to imply that the LLC is falling short; if anything, it's the community part of this that is missing. As some here will realise, the same issue arises for RFC Editor tools.

Regards
    Brian Carpenter

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 5 Nov 2021 13:52:22 +0000

> Do we have a clear mechanism for this - an organized community discussion leading to (rough) consensus followed by a request for resource assessment by the LLC? I'm quite aware of the tools-discuss…

This is a good question, Brian, and one that it seems the IETF community has struggled with recently -- as the IETF discuss list seems to have become less reflective of community consensus and people have unsubscribed. As the community coalesces around a new method(s) for broad community-wide consensus, then the LLC would certainly leverage that. In the meantime, the practice we seem to have arrived at for now is a combination - depending on the particulars of a given issue - of surveys, list discussion on multiple email lists, consultations with the relevant users/developers/administrators, consultation with IAB/IESG/WG chairs, new BoFs, new WGs, etc. In the case of more modest issues, the group closest to the work usually knows exactly what is needed (e.g. the NOC team knows their stuff inside & out). It sort of depends on the issue I suppose.

That said, I know everyone is open to suggestions on any new mechanisms for getting feedback and developing community-wide consensus. And if there are specific technical platform issues/choices looming on the horizon you think need broader discussion & debate, please say so (I know there are a few).  We're also in the budget planning process - so now is also a good time for any groups to request funding for new things & related work in 2022 if that would help them.

Lastly, I think perhaps there is also an emerging opportunity to engage the community in some way (such as a group of volunteers or something else) on overall future tools strategy & direction and probably other similar technical areas. It seems good timing to start discussing this, as we're finally at a point where the organization has more resource capacity and once tactical backlog items can be cleared then decisions about the future are at hand. I know Jay has been giving this some thought and appreciate any input you or others may have.

Jason

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 6 Nov 2021 10:13:35 +1300

> Lastly, I think perhaps there is also an emerging opportunity to engage the community in some way (such as a group of volunteers or something else) on overall future tools strategy & direction and…

We have lists: this one, tools-discusss, xml2rfc, rfc-interest, and probably others I don't know about. What we lack, because these are informal lists, is a mechanism for getting from feature requests to *rough consensus* on feature requests. I'm not sure how to fix that; maybe we need a tools-dispatch WG??

     Brian

---

From: Jay Daley <[email-masked]>
Date: Sat, 6 Nov 2021 11:00:01 +1300

> On 6/11/2021, at 10:13 AM, Brian E Carpenter <[email-masked]> wrote:
> 

This reflects a point that Mark Nottingham has been making in the RFC Editor Future Program - the community could and probably should be providing consensus guidance on features/design for tools/website/content but doing so through an RFC is such a heavyweight mechanism that it is not happening, and so an alternative mechanism is needed.  As Jason said, this is something I’ve been thinking about for a while and was a driver behind the creation of the Tools Architecture and Strategy Team, which is now moribund. Even if that was working, as Mark pointed out, that’s not a consensus mechanism. 

I don’t know what the answer is though some time ago, someone with a smile on their face suggested that I propose something like an IETF Operational Note (RFC 4693) to fill this gap.

Jay

-- 
Jay Daley
IETF Executive Director 
[email-masked]
> 
>    Brian
> 
> -- 
> admin-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/admin-discuss
>