Process Document Consolidation
charter-ietf-procon-01

[Ballot comment]
I'm a bit worried that some cleanup/merge is not straightforward without actually tackling the non-editorial parts, especially around the appeal process, as there are conflicting texts and it is not always clear that an Updates: affect only specific parts of an older doc and what the process truly is at the moment. I would hope such discussion are in scope - I can't really see how these would not be. But the use of "editorial" thus worries me a lot.

[Ballot comment]
"RFC2026", paragraph 2

* Treatment of milestones in Working Group charters
When it says "treatment," it is not clear what it is treating. Is it addressing the question of whether milestones are required for WG charters? Or is that milestones are required, but how they should be interpreted, e.g., they are guidelines to when the work may be started/completed, will be discussed by the WG?

[Ballot comment]
My comments raised against the previous review round still apply for this version. I'm thus reiterating them here:

* 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?

[Ballot comment]
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.

[Ballot comment]
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).

[Ballot comment]
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.

[Ballot block]
< entering as block since there is no "discussion" option here >

The two process documents 2026 and 2418 do not quite cover the entire process - especially coverage for the WG process for adoption and last-call. Recently, there have been appeals in that area. More importantly, as a participant, I've not found BCPs that I could "officially" lean on for those phases.

However, I've found two (informational) documents that have been helpful "guidelines" - RFC 7221 and RFC6174 - they cover important gaps in our BCPs.

It is normal for someone to see this as scope creep, but I think this is more like filling of important gaps. To be clear, I am not suggesting rolling in these two RFCs as a whole, but there are clearly chunks in there that are worthy of a formal promotion into our process documents as part of the consolidation work.

I would like to know the views of the rest of the IESG.

[Ballot comment]
# 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).

[Ballot comment]
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

[Ballot comment]
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