Update to IANA Considerations
charter-ietf-ianabis-00-05

[Ballot comment]
Just one minor comment about the last paragraph `By updating BCP 26, the IANABIS Working Group aims...` as it sounds like a marketing sentence for this WG ;-) (a matter of taste)

[Ballot block]
There are a couple things I’d like to clear up before I change my ballot position to “yes, a thousand times yes”:

- I don’t understand the sentence “Process and restrictions specifications around early allocations”.

- Is there some (dis)connection between the first “issues” bullet, “Additional stipulations around what constitutes valid references for “Specification Required” registries”, and the last, “A process for using the Internet-Drafts system to create permanent references”? The last bullet in particular seems cryptic to me, I’d appreciate it being clarified.

(Oh by the way, shouldn’t that be “what constitute valid references”, or “what constitutes a valid reference”, probably the latter? Agreement in number and all that.)

[Ballot comment]
Sorry for not bringing this up earlier, but I realized that the IANA Considerations section is used to register YANG modules, and updates to YANG modules that are maintained by IANA. Some of that text of how to do that has gone into rfc8407-bis, which is not completely out of place, but would like some debate around whether that belongs in this charter, and/or whether it should be moved to the BCP.

[Ballot comment]
Well done, just a suggestion s/Specifying process and restrictions around early allocations;/Process and restrictions specifications around early allocations;/ i.e., other bullets do not start with a verb (same for the line above)

[Ballot comment]
# Internet AD comments for charter-ietf-ianabis-00-02
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### "terminology"

* How do

    "Standardizing terms like ..."

  and

    "Amend and update registry terminology"

  differ?  They seem like they might overlap...

[Ballot comment]
The proposed charter looks as a good start. I took liberty to restructure and revise some wordings. Feel free to ignore or use at your desire:

Working Group Name: IANA Considerations Improvements and Simplifications (IANABIS)

Description
The IANA Considerations section in IETF documents is crucial for ensuring that protocol parameters and registries are managed effectively and consistently. RFC 8126 (BCP 26), titled "Guidelines for Writing an IANA Considerations Section in RFCs", provides a framework to ensure clarity and address operational issues related to IANA registries.

Since its publication in 2017, RFC 8126 has served the IETF community well. However, given the evolving needs and experiences over the past seven years, there is a recognized need to update and enhance BCP 26 to reflect current best practices and address new challenges.

The IANABIS Working Group is chartered to consider proposed revisions to BCP 26, based on the experience gained since the publication of RFC 8126, and to produce a revised document that updates or replaces RFC 8126. This is the sole deliverable of the working group.

Scope of Work
The working group will address the following areas:

# Valid References for "Specification Required" Registries: Define additional stipulations regarding what constitutes valid references, ensuring that specifications are accessible and maintain long-term availability.

# Guidance to Designated Experts: Develop stronger requirements and provide clearer advice to Designated Experts to ensure consistency and transparency in the evaluation process.

# Use of Expert Review Mailing Lists: Establish requirements for the use of Expert Review mailing lists to facilitate open communication and record-keeping.

# Standardization of Terminology: Standardize terms such as "registry group," "registry," and "subregistry" to promote clarity and uniform understanding across IETF documents and registries.

# Early Allocations Process: Specify processes and restrictions around early allocations, including eligibility criteria and procedures, to streamline early adoption without compromising stability.

# Adjustments Based on IANA's Experience: Incorporate adjustments informed by IANA's operational experience with registries over the past seven years to improve efficiency and effectiveness.

# Registry Terminology Updates: Amend and update registry terminology to reflect current practices and eliminate ambiguities.

# Flexible Registration Policies: Define additional registration policies that provide more flexibility, encouraging and accepting a broader range of registrations while maintaining integrity.

# Combinations of Registration Policies: Explore the use of combined registration policies, allowing Working Groups or registrants to choose appropriate policies for specific cases.

# Intermediate Registration Policy: Develop a registration policy that resides between "First Come First Served" (FCFS) and "Specification Required," catering to situations where neither existing policy is fully suitable.

# Permanent References via Internet-Drafts: Establish a process for using the Internet-Drafts system to create permanent references, ensuring long-term accessibility and stability of specifications.

Goals
The primary goal of the IANABIS Working Group is to produce a revised Best Current Practice (BCP 26) that:

# Reflects the current needs and practices of the IETF community.

# Incorporates lessons learned and operational experiences since the publication of RFC 8126.

# Provides clear, comprehensive guidance for authors and Working Groups in crafting IANA Considerations sections.

# Enhances the efficiency, clarity, and consistency of IANA registry management processes

Collaboration
The working group will collaborate closely with:

# IANA Staff: To ensure proposed changes are practical and align with operational realities.

# Designated Experts: To gather insights and feedback on the effectiveness of current processes and proposed improvements.

# IETF Community: To solicit broad input and achieve consensus on the revisions.

Conclusion
By updating BCP 26, the IANABIS Working Group aims to strengthen the foundational guidelines that support the IETF's protocol development and registry management, ensuring they remain robust, clear, and aligned with the evolving landscape of Internet standards.

[Ballot comment]
The proposed charter looks as a good start. I took liberty to restructure and revise some wordings. Feel free to ignore or use at your desire:

Working Group Name: IANA Considerations Improvements and Simplifications (IANABIS)

Description
The IANA Considerations section in IETF documents is crucial for ensuring that protocol parameters and registries are managed effectively and consistently. RFC 8126 (BCP 26), titled "Guidelines for Writing an IANA Considerations Section in RFCs", provides a framework to ensure clarity and address operational issues related to IANA registries.

Since its publication in 2017, RFC 8126 has served the IETF community well. However, given the evolving needs and experiences over the past seven years, there is a recognized need to update and enhance BCP 26 to reflect current best practices and address new challenges.

The IANABIS Working Group is chartered to consider proposed revisions to BCP 26, based on the experience gained since the publication of RFC 8126, and to produce a revised document that updates or replaces RFC 8126. This is the sole deliverable of the working group.

Scope of Work
The working group will address the following areas:

# Valid References for "Specification Required" Registries: Define additional stipulations regarding what constitutes valid references, ensuring that specifications are accessible and maintain long-term availability.
# Guidance to Designated Experts: Develop stronger requirements and provide clearer advice to Designated Experts to ensure consistency and transparency in the evaluation process.
# Use of Expert Review Mailing Lists: Establish requirements for the use of Expert Review mailing lists to facilitate open communication and record-keeping.
# Standardization of Terminology: Standardize terms such as "registry group," "registry," and "subregistry" to promote clarity and uniform understanding across IETF documents and registries.
# Early Allocations Process: Specify processes and restrictions around early allocations, including eligibility criteria and procedures, to streamline early adoption without compromising stability.
# Adjustments Based on IANA's Experience: Incorporate adjustments informed by IANA's operational experience with registries over the past seven years to improve efficiency and effectiveness.
# Registry Terminology Updates: Amend and update registry terminology to reflect current practices and eliminate ambiguities.
# Flexible Registration Policies: Define additional registration policies that provide more flexibility, encouraging and accepting a broader range of registrations while maintaining integrity.
# Combinations of Registration Policies: Explore the use of combined registration policies, allowing Working Groups or registrants to choose appropriate policies for specific cases.
# Intermediate Registration Policy: Develop a registration policy that resides between "First Come First Served" (FCFS) and "Specification Required," catering to situations where neither existing policy is fully suitable.
# Permanent References via Internet-Drafts: Establish a process for using the Internet-Drafts system to create permanent references, ensuring long-term accessibility and stability of specifications.

Goals
The primary goal of the IANABIS Working Group is to produce a revised Best Current Practice (BCP 26) that:

# Reflects the current needs and practices of the IETF community.
# Incorporates lessons learned and operational experiences since the publication of RFC 8126.
# Provides clear, comprehensive guidance for authors and Working Groups in crafting IANA Considerations sections.
# Enhances the efficiency, clarity, and consistency of IANA registry management processes

Collaboration
The working group will collaborate closely with:

# IANA Staff: To ensure proposed changes are practical and align with operational realities.
# Designated Experts: To gather insights and feedback on the effectiveness of current processes and proposed improvements.
# IETF Community: To solicit broad input and achieve consensus on the revisions.

Conclusion
By updating BCP 26, the IANABIS Working Group aims to strengthen the foundational guidelines that support the IETF's protocol development and registry management, ensuring they remain robust, clear, and aligned with the evolving landscape of Internet standards.

[Ballot comment]
The proposed charter looks as a good start. I took liberty to restructure and revise some wordings. Feel free to ignore or use at your desire:

Working Group Name: IANA Considerations Improvements and Simplifications (IANABIS)

Description
The IANA Considerations section in IETF documents is crucial for ensuring that protocol parameters and registries are managed effectively and consistently. RFC 8126 (BCP 26), titled "Guidelines for Writing an IANA Considerations Section in RFCs", provides a framework to ensure clarity and address operational issues related to IANA registries.

Since its publication in 2017, RFC 8126 has served the IETF community well. However, given the evolving needs and experiences over the past seven years, there is a recognized need to update and enhance BCP 26 to reflect current best practices and address new challenges.

The IANABIS Working Group is chartered to consider proposed revisions to BCP 26, based on the experience gained since the publication of RFC 8126, and to produce a revised document that updates or replaces RFC 8126. This is the sole deliverable of the working group.

Scope of Work
The working group will address the following areas:

* Valid References for "Specification Required" Registries: Define additional stipulations regarding what constitutes valid references, ensuring that specifications are accessible and maintain long-term availability.
* Guidance to Designated Experts: Develop stronger requirements and provide clearer advice to Designated Experts to ensure consistency and transparency in the evaluation process.
* Use of Expert Review Mailing Lists: Establish requirements for the use of Expert Review mailing lists to facilitate open communication and record-keeping.
* Standardization of Terminology: Standardize terms such as "registry group," "registry," and "subregistry" to promote clarity and uniform understanding across IETF documents and registries.
* Early Allocations Process: Specify processes and restrictions around early allocations, including eligibility criteria and procedures, to streamline early adoption without compromising stability.
* Adjustments Based on IANA's Experience: Incorporate adjustments informed by IANA's operational experience with registries over the past seven years to improve efficiency and effectiveness.
* Registry Terminology Updates: Amend and update registry terminology to reflect current practices and eliminate ambiguities.
* Flexible Registration Policies: Define additional registration policies that provide more flexibility, encouraging and accepting a broader range of registrations while maintaining integrity.
* Combinations of Registration Policies: Explore the use of combined registration policies, allowing Working Groups or registrants to choose appropriate policies for specific cases.
* Intermediate Registration Policy: Develop a registration policy that resides between "First Come First Served" (FCFS) and "Specification Required," catering to situations where neither existing policy is fully suitable.
* Permanent References via Internet-Drafts: Establish a process for using the Internet-Drafts system to create permanent references, ensuring long-term accessibility and stability of specifications.

Goals
The primary goal of the IANABIS Working Group is to produce a revised Best Current Practice (BCP 26) that:

* Reflects the current needs and practices of the IETF community.
* Incorporates lessons learned and operational experiences since the publication of RFC 8126.
* Provides clear, comprehensive guidance for authors and Working Groups in crafting IANA Considerations sections.
* Enhances the efficiency, clarity, and consistency of IANA registry management processes

Collaboration
The working group will collaborate closely with:

* IANA Staff: To ensure proposed changes are practical and align with operational realities.
* Designated Experts: To gather insights and feedback on the effectiveness of current processes and proposed improvements.
* IETF Community: To solicit broad input and achieve consensus on the revisions.

Conclusion
By updating BCP 26, the IANABIS Working Group aims to strengthen the foundational guidelines that support the IETF's protocol development and registry management, ensuring they remain robust, clear, and aligned with the evolving landscape of Internet standards.