Update to IANA Considerations
charter-ietf-ianabis-01-02

[Ballot comment]
Just a minor suggestion s/The primary goal of the IANABIS Working Group is to produce a revised BCP 26 and BCP 100/The primary goal of the IANABIS Working Group is to produce a revised RFC 8126 and RFC 7120/ as the rest of this section is about 2 *documents* and not BCP (that can include several RFCs).

[Ballot comment]
Thanks for the discussion and for updating the charter to reflect the outcome [1].

The nits are not fixed; feel free to grab whatever useful:

# nit

OLD: These form a critical function in many protocol frameworks
NEW: These BCPs form a critical function in many protocol frameworks

# nit

OLD: The current version of BCP 26 was published in 2017
NEW: The latest version of BCP 26 was published in 2017

# nit

Be consistent through the charter:  IANABIS Working Group vs. IANABIS working group

# nit

Bullet lists: s/;/, or  simply s/;/. and s/; and/.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/ianabis/SJUwcYKlOkxYLOHs9I-96OMGwZ8/

[Ballot block]
This is more to serve as a reminder of what we have agreed on in the e-mail thread.

Open an issue to track that when 8126bis is being worked upon, it will look at absorbing Section 4.30 from draft-ietf-netmod-rfc8407bis.

[Ballot block]
# Implications

CURRENT:
  Lastly, the working group may consider combining the two documents into a single BCP.

We would break all https://datatracker.ietf.org/doc/bcp26/referencedby/ if we change BCP 26 with a new umbrella. Given https://datatracker.ietf.org/doc/bcp100/, I would be more explicit here and say that revision of 7210 may be considered to be under BCP26.

NEW:
  Lastly, the working group may consider combining the two documents into BCP 26.

# Plan for other specs that update 8126

I’m aware at least about draft-ietf-netmod-rfc8407bis which is tagged as updating 8126. Do we plan to re-include such considerations as part of 8126bis or this can be handled by external reference for specific IANA actions.

I think that we need a provision for such checks in the candidate revision work.

[Ballot comment]
# nit

OLD: These form a critical function in many protocol frameworks
NEW: These BCPs form a critical function in many protocol frameworks

# nit

OLD: The current version of BCP 26 was published in 2017
NEW: The latest version of BCP 26 was published in 2017

# nit

Be consistent through the charter:  IANABIS Working Group vs. IANABIS working group

# nit

Bullet lists: s/;/, or  simply s/;/. and s/; and/.

[Ballot comment]
A few comments:

1) "A registration policy between "First Come First Served" and “Specification Required”; and"

This seems way too specific (and I don't understand the reason for it, to be honest). There are a couple of other bullets on the charter that should cover it, if the WG indeed wants to consider this as an issue per se.

"Additional registration policies that can allow more flexibility for encouraging and accepting registrations;"
"A process for using the Internet-Drafts system to create permanent references."

2) The charter is conspicuous by the absence of any text related to describing the use of IANA registries by other SDOs or public/private entities outside of the IETF. IMHO RFC8216 does not provide good enough guidance in this regard. There is scope for improvement in terms of specific guidance to both the WGs/authors writing documents that create and set registrations policies for registries, as well to others (especially those outside of the IETF) that want to perform allocation.

That said, this is much needed work, so Thanks!

[Ballot comment]
# Internet AD comments for charter-ietf-ianabis-01-00
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

* "A registration policy between "First Come First Served" and
  “Specification Required”"

  How is this expected to be different from Expert Review?

* I don't think it would meaningfully alter the documents that get
  (re)written but we might note that the target for some of this
  information includes anyone who might need to interact with an IANA
  registry, specifically: folks outside the IETF community who might need
  to understand something about a registry or making a request.

  I think this means we probably need to be mindful of any text that could
  get a little too "Inside Baseball"-y, if you take my meaning, and
  generally make sure that text remains approachable by non-IETF-ers.

[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.