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

I share Ketan's question regarding the use of IANA registries by other SDOs. Would the working group consider looking at this as well?

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

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!

Thanks for addressing my comment.

I would encourage caution around the suggestion to combine BCPs. Seems like it could break things.

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/

Just wondering how this can be done `Lastly, the working group may consider combining the two documents into a single BCP.`