Original text:
The document is meant to spur discussion in the IETF community.  If there proves to be rough consensus in the community in support of the proposals in this document, the functional requirements would need to <del> be discussed with the IETF Tools Team, and the IETF Secretariat who </del>  would need to support various pieces of what is proposed herein. 2. conventions to support the creation and management of GitHub organizations for working groups and single-document repositories in a uniform way.  The steps could be done manually by the IETF <del> Secretariat or they could be automated.  For example, see </del>  <https://github.com/richsalz/ietf-gh-scripts> and <https://github.com/martinthomson/i-d-template> for working examples of automation that is in use in some working groups. In this document the question of whether processes should be manual <del> or automated is deliberately left ambiguous since the first question that should be asked is whether this is functionality the community would want to have supported at all. </del>  Most of the conventions below are drawn from I-D.ietf-git-using- github. be able to make it have the same management as one would get with going through the steps in creation.  That is, it would be good to be able to run steps 3 and 4 from creation so that the rest of the <del> activities in this section such as personnel work the same for the organizations that were created on their own. </del>  2.3. 2.4. When a working group is closed, the team with administrative access <del> would be removed and the owner list would be returned to its initial composition.  The organization summary and the repositories within the organization would be updated to indicate that they are no longer under development. </del>  2.5. be useful to have automation or established administrative conventions for repositories within WG organizations, such as: <del> Creating a new repository for an individual draft that is at the discretion of the WG chair; </del>  Creating a new repository for an already-adopted working group draft;

Reviewer comments:
See URL
I'm good with all the changes except the one I commented on. I’ve picked this document up as responsible AD, because Alissa is an author on the document. There’s one item in my review that I’d like to have addressed before this goes out for last call; the rest don’t need to block last call, but they should be easy to address. Blocking comment: — Section 2.4 — When a working group is closed, the team with administrative access would be removed and the owner list would be returned to its initial composition. What “initial composition”? The Secretariat and the ADs at the time the organization was created? That doesn’t make sense. The Secretariat and current ADs at the time of closing? That’s not “initial”. Or do you have something else in mind? The rest: — Abstract — Just a note here that the second paragraph should be removed before publication. I’ve put this in as an RFC Editor Note. — Section 1 — proposals in this document, the functional requirements would need to be discussed with the IETF Tools Team, and the IETF Secretariat who would need to support various pieces of what is proposed herein. Nit: the comma after “Tools Team” is misplaced, and should be after “Secretariat” instead. — Section 2 — For example, see and for working examples of automation that is in use in some working groups. Two things here: Nit: “For example … for working examples” is redundant; I suggest starting the sentence with “See”. I’m not sure that these URLs will stand the test of time, remaining valid in an archival document. On the other hand, having them here as examples is certainly useful. Perhaps we could archive them on an URL page, or perhaps the RFC Editor could do so on an rfc-URL page? In this document the question of whether processes should be manual or automated is deliberately left ambiguous “Ambiguous” isn’t the right word — it carries a connotation of confusion. I suggest “unspecified”. And there needs to be a comma after that word, whichever we choose. — Section 2.2 — be able to run steps 3 and 4 from Section 2.1 so that the rest of the activities in this section such as personnel work the same for the organizations that were created on their own. I find this awkward; I think it needs commas and a minor edit: NEW be able to run steps 3 and 4 from Section 2.1 so that the rest of the activities in this section, such as personnel changes, work the same way as for organizations that were created as specified herein. END — Section 2.5 — o Creating a new repository for an individual draft that is at the discretion of the WG chair; What does “an individual draft that is at the discretion of the WG chair” mean? — Section 4 — An attacker who can change the contents of Internet Drafts, particularly late in a working group's process, can possibly cause unnoticed changes in protocols that are eventually adopted. Indeed, and so should we propose any mitigations? Using a github instance that’s maintained and secured under URL At the very least we’ll need to rely on careful review during the publication process, including verifying what changes were made at each step and flagging questionable changes. The text here should probably say something more. Barry

Revised text:
The document is meant to spur discussion in the IETF community.  If there proves to be rough consensus in the community in support of the proposals in this document, the functional requirements would need to  <ins> be discussed with the IETF Tools Team and the IETF Secretariat, who </ins> would need to support various pieces of what is proposed herein. 2. conventions to support the creation and management of GitHub organizations for working groups and single-document repositories in a uniform way.  The steps could be done manually by the IETF  <ins> Secretariat or they could be automated.  See </ins> <https://github.com/richsalz/ietf-gh-scripts> and <https://github.com/martinthomson/i-d-template> for working examples of automation that is in use in some working groups. In this document the question of whether processes should be manual  <ins> or automated is deliberately left unspecified, since the first question that should be asked is whether this is functionality the community would want to have supported at all. </ins> Most of the conventions below are drawn from I-D.ietf-git-using- github. be able to make it have the same management as one would get with going through the steps in creation.  That is, it would be good to be able to run steps 3 and 4 from creation so that the rest of the  <ins> activities in this section, such as personnel changes, work the same way as for organizations that were created as specified herein. </ins> 2.3. 2.4. When a working group is closed, the team with administrative access  <ins> would be removed and the owner list would be returned to the Secretariat and current ADs at the time of closing.  The organization summary and the repositories within the organization would be updated to indicate that they are no longer under development. </ins> 2.5. be useful to have automation or established administrative conventions for repositories within WG organizations, such as:  <ins> Creating a new repository for an individual draft (at the discretion of the WG chair); </ins> Creating a new repository for an already-adopted working group draft;