Process Document Consolidation
charter-ietf-procon-01
Yes
(Paul Wouters)
No Objection
Deb Cooley
Jim Guichard
Mike Bishop
Note: This ballot was opened for revision 00-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
Éric Vyncke
Yes
Comment
(2025-05-19 for -00-00)
Sent
Long due refresh indeed... Just a comment s/any associated errata/any associated verified or hold-for-update errata/
Mahesh Jethanandani
Yes
Comment
(2025-05-19 for -00-00)
Sent
Agree that a refresh of the two documents is long overdue.
Roman Danyliw
Yes
Comment
(2025-05-15 for -00-00)
Sent
The origin of this charter is multiple dispatch results from ALLDISPATCH at IETF 120 [1] and IETF 121 [2] which recommended forming a new WG(s) to do the work. [1] ALLDISPATCH at IETF 120: draft-schinazi-update-on-milestones [2] ALLDISPATCH at IETF 121: draft-rsalz-2418bis, draft-rsalz-2026bis, draft-eggert-ietf-chair-may-delegate
Deb Cooley
No Objection
Gorry Fairhurst
No Objection
Comment
(2025-05-22 for -00-00)
Sent
I'm positive in general. * I have a concern about how the milestone redefinition would develop: I've hoped that WGs would/should use Milestones to manage their work, but I've seen a wide variety of practice. I would hope any developments focus on what is "best" to manage priorities and progress. * I strongly support E Kline for a suggestion changing: s/is incapacitated/is unable to serve for any reason/ * Following the comment form Ketan Talaulikar, two RFCs seem like they ought to provide input: - I have used RFC 7221 in the past, I think this is useful to highlight for people to learn or more. - RFC 6174 might be useful, but is more of a reference to the way the tracker worked (at some time).
Gunter Van de Velde
No Objection
Comment
(2025-05-22 for -00-00)
Sent
This sounds like a good idea to get these updated. recently i had to use these to help mediate undesired behavior on my WGs. I'm wondering if it might be helpful to include some editorial guidance that drafts should focus on documenting technical or operational procedures, rather than being written in bad faith with the sole purpose of targeting or undermining other existing drafts, whether those drafts are already working group items or not.
Jim Guichard
No Objection
Ketan Talaulikar
(was Block)
No Objection
Comment
(2025-05-27 for -00-01)
Sent
Thanks for the discussion and based on that, I would offer the following brief comments/inputs that are non-blocking and for Roman (as responsible AD) and the WG to consider for RFC2418: - Please leverage RFC7221 - Conflict of interest (the reference in RFC2418 section 3 seems incorrect?) - cover when one or more chairs are authors/contributors - IPR disclosures - consider incorporating the check/poll at WG adoption and LC stages as a recommendation. Note: this does not change or dilute the existing "rolling basis" IPR disclosure requirement per RFC8179 - Inclusion of Shepherd in the Staff Roles. Perhaps without going into the process details like write up templates and all. - Coverage in sec 7 of RFC2418 for a high-level flow description of documents and their progression through the WG.
Mike Bishop
No Objection
Mohamed Boucadair
No Objection
Comment
(2025-05-16 for -00-00)
Sent
The RFC2026 and RFC2418 consolidation effort is worth. Some comments about the two candidate items: * Milestones are used for different purposes. A more structural change would be to provide provisions for WGs to set priorities without rechartering (of course, anchored in WG charter scope). If we had that change, then the optionality of milestones would be OK. Does the current milestone bullet also cover support for means to set WG-defined priorities or this is about the specific proposal listed in Roman's ballot? * What is the motivation for the item about the guidance to adopt documents? Are there reported issues/abuses/etc.? * For the guidance to adopt documents, not sure if freezing more process details in an RFC is a good approach. Maybe key principles can make it to the RFC but more detailed procedures are better managed in an online page? Do we expect the discussion to also cover whether we offload (rather than add more text to reference RFCs) to other forms? Thank you
Paul Wouters Former IESG member
Yes
Yes
(for -00-00)
Not sent
Erik Kline Former IESG member
No Objection
No Objection
(2025-05-19 for -00-00)
Sent
# Internet AD comments for charter-ietf-procon-00-00 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md ## Comments * s/is incapacitated/is unable to serve for any reason/? This leaves open the question of which parties can assess inability to serve, but probably that's the IAB (which would have appointed the said in the first place, IIRC).