IRC grammar does not allow numbers inside of command names (with exception of numerics, which must be exactly 3 numbers). You need to pick a different command name. I suggest MFA since this could in theory be used for more than 2 factors as well with the introduction of biometric authentication types (e.g. passkeys).

Other aspects of this spec should be similarly edited to update "2fa" with the other chosen string for consistency.

"MUST NOT contain whitespace" is superfluous as that is already forbidden by the specified set of allowed characters.

"printable" is vague and there is no solid definition of that outside of the ASCII space. Specify precisely which characters are allowed here (or, more easily, which characters are forbidden and allow everything else)

"No base 64" is superfluous and should be removed.

This is already prevented because if 2-factor auth is enabled, they won't be able to fully authenticate without passing it. This entire section should be reworked tbh as it seems more like a footgun than anything else. A server may choose to not allow a user to remove their final second authentication factor (that is, require 2FA in some fashion). But if a server doesn't choose to allow that, we shouldn't be requiring the user to validate that they have precisely the thing they want to remove.

If you want to have an extra challenge on removal for additional assurance, allow them to authenticate using any of their registered secondary factors in order to remove them from the list.

This entire section should be removed, since we shouldn't be using SASL for this. The previous registry can be used for both enrollment and authentication.

I touch more on this below, but this command should be used for actual authentication. For enrollment, just use ADD for the entire process (even if it requires multiple back and forth messages).

If an attacker can write to the credential store, they can either disable the 2FA flag entirely or inject their own credentials that they are in possession of, so this isn't a particularly compelling reason. Come up with something better or omit the explanation.

This section appears to be normative given the proliferation of MUST. I recommend that all of these notes be rolled into the actual specification text instead of living at the bottom of the document. This section should instead be moved into non-normative prose explaining security considerations in a human-understandable manner.

I would remove this listing from this section as it's just an additional place to (forget to) update as other mechs are added. The introduction section is more for human-readable prose to let people understand why the spec exists and what problems it solves. Diving into implementation details this early mostly serves to raise more questions than it answers.