I think this document is pretty much ready, but I have minor comments in two places:

— Section 4 —

   The format of a service provider CPS advertisement consists of a
   simple JSON object containing one or more pairs of TNAuthList values
   pointing to the URIs of CPSs, e.g. {
   "0-1234":"https://cps.example.com" }. The format of this is a hyphen-
   separated concatenation of the [RFC8226] TNAuthList TNEntry values
   ("0" for SPC, "1" for telephone number range, "2" for individual
   telephone number) with the TNAuthList value.  Note for in case "1",
   telephone number ranges are expressed by a starting telephone number
   followed by a count, and the count itself is here also by hyphen-
   separated from the TN (e.g., "1-15714341000-99").  An advertisement
   can contain multiple such ranges by adding more pairs.  CPS URIs MUST
   be HTTPS URIs [RFC3986].  These CPS URIs SHOULD be publicly
   reachable, as service providers cannot usually anticipate all of the
   potential callers that might want to connect with them, but in more
   constrained environments, they MAY be only reachable over a closed
   network.

I have a few minor comments here:

1. Where you talk about the concatenation of the “TNAuthList TNEntry values” with the “TNAuthList value”, shouldn’t the former also be the singular “value”, as any one pair can only have one TNEntry value?  This made me have to re-read the sentence a few times before I understood that you're not putting multiple TNEntry values with hyphens between (as "0-1-2").

2. For “CPS URIs MUST be HTTPS URIs [RFC3986],” I think this isn’t the best reference: it’s the generic URI document.  To cite HTTPS URIs, this is better: “CPS URIs MUST be HTTPS URIs (see [RFC9110] Section 4.2.2).”

3. For “they MAY be only reachable over a closed network,” I generally don’t think the “SHOULD / but MAY” combination is proper use of BCP 14 key words.  I think the the second part should simply be the plain English “may”.  *Very minor*, so do what you think is best, but please consider changing it.


— Section 10 —

When I read the last sentence, I find its point to be ambiguous: it appears to be stating a situation that needs to be avoided, but it doesn’t say so.  Might it be better to phrase it as tying into and emphasizing the point from the prior sentence, maybe like this?:

NEW
   Otherwise, if anyone with a STIR
   certificate were able to publish or access PASSporTs for any telephone
   number, this could lead to an undesirable federated environment where
   effectively anyone with a STIR certificate could acquire PASSporTs for
   calls in progress to any service provider.
END

(And I’m not sure the word “federated” is necessary in there.)