Reviewer: Barry Leiba
Review result: Has Nits
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.)
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
