Code change:
I suggest creating an IANA registry for catalog fields with values auto-populated from Section 3.2.
What is the point of shifting the catalog fields definitions to IANA? IANA is useful for ensuring global uniqueness. If a single specification defines the catalog format, then that spec if a much more efficient and natural place to define the fields used by that format.
If we end up needing new fields (which we certainly will), we don't need a revised RFC. The fields table can be amended/expanded in a number of ways.

Related discussion:
text: 5. <del> This section details how the MoQ Streaming Format Type can be registered.  The type registry can be updated by incrementally expanding the type space, i.e., by allocating and reserving new type identifiers.  As per [RFC8126], this section details the creation of the "MoQ Streaming Format Type" registry. </del> <ins> This section details how the MoQ Streaming Format Type and new fields can be registered for inclusion in a catalog. </ins> 5.1. This document creates a new registry, "MoQ Streaming Format Type". <del> The registry policy is "RFC Required".  The Type value is 2 octets. The range is 0x0000-0xFFFF.The initial entry in the registry is: </del> <ins> This registry is managed by the IANA according to the RFC Required policy of RFC5226.  The Type value is 2 octets.  The range is 0x0000-0xFFFF.  The initial entry in the registry is: </ins> <del> Every MoQ streaming format draft normatively referencing this catalog format MUST register itself a unique type identifier. </del> <ins> No RFC is provided for the initial entry as it is reserved for Every MoQ streaming format draft normatively referencing this catalog format MUST register itself a unique type identifier.  The type registry can be updated by incrementally expanding by allocating and reserving new type identifiers. 5.2. This document creates a new IANA registry for the Common Catalog fields.  The registry is called "MoQ Common Catalog Fields".  This registry is managed by the IANA according to the Specification Required policy of RFC5226.  The initial entries in the registry are: Any registration for a new Field name MUST provide the following information: Descriptive Name - a descriptive name for the field. Field Name - the JSON field name, as will be used inside the JSON catalog. Required - the string "yes" if the field is required in all catalogs and "opt" if it is not. Location - a string defining the permissible locations for the field within the catalog: 'R' - the field is located in the Root of the JSON object. 'RC' - the field may be located in either the Root or a Catalog object. 'RTC' - the field may be located in either the Root, or a Track object or a Catalog object. 'TC' - the field may be located in either a Track object or a Catalog object. 'RT' - the field may be located in either the Root or a Track object. 'T' - the field is located in a Track object. 'S' - the field is located in the Selection Parameters object. JSON Type - the JSON type of the field value, which must be one of String, Array, Number, Object or Boolean. Specification - a URL to the specification which defines the usage of the field within the catalog, per the Specification Required policy of RFC5226. </ins>