Section 3., paragraph 1:
>    The tel URI parameters and values for these parameters MUST be
>    documented in a RFC or other permanent and readily available public
>    specification in order to be registered by IANA.

  Section 4.2 defines the polocy as "Specification Required, Designated
  Expert" from RFC2434 - could you use that same term here?


Section 4.2., paragraph 1:
>    As per the terminology in [6] and actions accorded to such a role,
>    the registration policy for tel URI parameters shall be
>    "Specification Required, Designated Expert" (the former implicitly
>    implies the latter.)

  Why does "Specification Required" imply "Designated Expert"? That's
  not the case IMO.

The distinction between URI parameters that accept a set of predefined
values vs. parameters that can accept any value would benefit from
some clarification. Originally, I thought "predefined values" meant an
enumeration (like "isub-encoding"), but later in the document, things
like domain names, URIs, or strings of digits are also counted as "set
of predefined values".

Also, apparently there are currently no parameters in the "can accept
any value" category -- so perhaps instead of talking about "predefined
values", we could just classify parameters as "has a value" vs.  "does
not have a value"?

The document probably should have "Updates: RFC 3966" on cover page
since it changes the procedures defined in RFC 3966 (which says that
"New mandatory parameters must be described in a standards-track RFC,
but an informational RFC is sufficient for optional parameters.")

Should the parameters used in obsolete RFC 2806 be marked as
"reserved" in this registry? ('tsp' and 'postd')

Who is proposed as the designated expert for this registry?

I strongly concur with all of Pasi's comments and recommend the authors
consider them seriously.  As a suggestion for clarity: instead of a
yes/no for "predefined value", have a three-state "value-type" column
that says one of: no-value, constrained, unconstrained.  BTW, it appears
there are no "unconstrained" parameters defined -- if that's likely to
continue in the future, perhaps it's simpler to just omit the column
altogether.