Original text:
3.2.4.  An array of track objects trackobject.  If the 'tracks' field is present then the 'catalog' field MUST NOT be present. <del> 3.2.5. </del>  An array of catalog objects catalogobject.  If the 'catalogs' field is present then the 'tracks' field MUST NOT be present.  A catalog MUST NOT list itself in the catalog array. <del> 3.2.6. </del>  A catalog object is a collection of fields whose location is <del> specified as 'RC', 'TC' or 'RTC' in Table 1. </del>  <del> 3.2.7. </del>  A track object is a collection of fields whose location is specified <del> as 'RT', 'TC' or 'RTC' in Table 1. </del>  <del> 3.2.8. </del>  The name space under which the track name is defined.  See section 2.3 of MoQTransport.  If the track namespace is declared in the root

Reviewer comments:
Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example:

Revised text:
3.2.4. <ins> An object holding a collection of Track Fields (objects with a location of TF or TFC in table 1) which are to be inherited by all tracks.  A field defined at the Track object level always supercedes any value inherited from the Common Track Fields object. 3.2.5. </ins> An array of track objects trackobject.  If the 'tracks' field is present then the 'catalog' field MUST NOT be present.  <ins> 3.2.6. </ins> An array of catalog objects catalogobject.  If the 'catalogs' field is present then the 'tracks' field MUST NOT be present.  A catalog MUST NOT list itself in the catalog array.  <ins> 3.2.7. </ins> A catalog object is a collection of fields whose location is  <ins> specified as 'RC' or 'TFC' in Table 1. </ins>  <ins> 3.2.8. </ins> A track object is a collection of fields whose location is specified  <ins> as 'TFC', 'TF' or 'T' in Table 1. </ins>  <ins> 3.2.9. </ins> The name space under which the track name is defined.  See section 2.3 of MoQTransport.  If the track namespace is declared in the root