Subject: [stir] WG last call comments on stir-oob-04

From: Mary Barnes <[email-masked]>
Date: Thu, 18 Apr 2019 16:01:49 -0500

I think the document is not quite ready to progress and needs some minor
changes, as also reflected by Russ' and Eric's reviews.   I've responded
inline to their review point(s) where I had similar concerns, rather than
introduce yet again.  I have also tried to not duplicate comments, but
don't guarantee I didn't since I started my review prior to their posts.

Regards,
Mary.

Minor comments:
----------------------
- General: per Eric's comments, there is still a lot of work to do to get
this completed or even to get a simple profile specified. It might be very
helpful somewhere to summarize the gaps that must be addressed.  And, it
should clearly state that this document doesn't provide a complete solution
but rather identifies building blocks and gaps required to realize a
solution.  Maybe something like this added at the end of the introduction:

"This document provides the operating environments in which this
out-of-band STIR mechanism is intended to operate.  It provides use cases
and provides a description of the components and a solution architecture.
It describes the storage and retrieval of PASSporTs in the CPS within this
context.  Gaps that must be addressed in a solution are also identified."

- Section 1, 2nd paragraph.  Is it really "most" calls that still traverse
the PSTN?  I would think "a number of" might be a better way to say that.

- Section 5.2.  I don't quite understand the premise in that first
paragraph.  Are there 2 simultaneous calls and once it hits the gateway it
gets dropped?

- Section 7.5, last paragraph.  It seems to me that the recommendation for
the amount of time to store a PASSporT should have some relation to the
time chosen for verifying "iat" values in the PASSporT.  Maybe change "for
more than sixty seconds."   to "something like "no longer than a value that
might be selected for the verification service policy for freshness of the
"iat" value as described in [RFC 8224]."   As I recall, there was a
conscious choice made to not put a specific value on that time in 8224 and
I can't see why we wouldn't want to do the same here.

Editorial nits:
-----------------
- Section 1, 3rd sentence:  I found this wording awkward, so I suggest the
following change:
OLD:
  For example, [RFC8224] defines an Identity header of SIP requests capable
of carrying a
  PASSporT [RFC8225] object in SIP as a means ...
NEW:
   For example, [RFC8224] defines a SIP Identity header field capable of
carrying
  PASSporT [RFC8225] objects in SIP requests as a means ...

- Section 4, 3rd paragraph.  I think a list with numbers is more readable
than this plain list.  and strictly speaking an "or" at the end of item 1
is more accurate since I think you're describing two options.

- Section 5.3, 1st paragraph:
"it will immediate drop" -> "it will immediately drop"

- Section 5.4, last paragraph:
" perhaps the destination endpoints queries" -> "perhaps the destination
endpoint queries"

- Section 6.1, 3rd paragraph:  "the most obviously way" -> "the most
obvious way"

- Section 6.2, 3rd paragraph:  "will need decrypt" -> "will  need to
decrypt"

- Section 7.3 Again, I think a numbered list is a better way to annotate
those two points.

- Section 7.5. Ditto Russ' comment on reference to "blind signature"

- The reference to the VIPR overview spec isn't to the most recent
version.  It should be draft-jennings-vipr-overview (and as I've said a
number of times, I think it would be good to actually publish that one)

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 25 Apr 2019 22:03:16 +0000

Thanks for the notes Mary. A few responses inline.

Minor comments:
----------------------
- General: per Eric's comments, there is still a lot of work to do to get this completed or even to get a simple profile specified. It might be very helpful somewhere to summarize the gaps that must be addressed.  And, it should clearly state that this document doesn't provide a complete solution but rather identifies building blocks and gaps required to realize a solution.  Maybe something like this added at the end of the introduction:

"This document provides the operating environments in which this out-of-band STIR mechanism is intended to operate.  It provides use cases and provides a description of the components and a solution architecture.  It describes the storage and retrieval of PASSporTs in the CPS within this context.  Gaps that must be addressed in a solution are also identified."

<Jon> Sure, I mean, moving it to Info from PS is intended to signify that it is just a framework and not a protocol specification (apart from the little strawman which is marked clearly as a strawman). But I don’t have a problem adding something like that to the end of the intro. </Jon>

- Section 1, 2nd paragraph.  Is it really "most" calls that still traverse the PSTN?  I would think "a number of" might be a better way to say that.

<Jon> The numbers I hear are well into “most”, even if more than half of residential landline is now last-mile IP. But it’s true that statements like this don’t age well or add much value for posterity. I can patch it. </Jon>

- Section 5.2.  I don't quite understand the premise in that first paragraph.  Are there 2 simultaneous calls and once it hits the gateway it gets dropped?

<Jon> Not two calls, no, the PBX we’re assuming here does not have a SIP trunk, just an old-school PRI or something, but it does have a regular Internet connection. So it is dropping the call to that PRI, and as it does so, it puts the PASSporT in the CPS. Would it help if I made it clear that despite having Internet access, it doesn’t have an outbound Internet voice call path, or something? </Jon>

- Section 7.5, last paragraph.  It seems to me that the recommendation for the amount of time to store a PASSporT should have some relation to the time chosen for verifying "iat" values in the PASSporT.  Maybe change "for more than sixty seconds."   to "something like "no longer than a value that might be selected for the verification service policy for freshness of the "iat" value as described in [RFC 8224]."   As I recall, there was a conscious choice made to not put a specific value on that time in 8224 and I can't see why we wouldn't want to do the same here.

<Jon> That’s probably fine. Your nits below are also appreciated. Thanks again for the read. </Jon>

Editorial nits:
-----------------
- Section 1, 3rd sentence:  I found this wording awkward, so I suggest the following change:
OLD:
  For example, [RFC8224] defines an Identity header of SIP requests capable of carrying a
  PASSporT [RFC8225] object in SIP as a means ...
NEW:
   For example, [RFC8224] defines a SIP Identity header field capable of carrying
  PASSporT [RFC8225] objects in SIP requests as a means ...

- Section 4, 3rd paragraph.  I think a list with numbers is more readable than this plain list.  and strictly speaking an "or" at the end of item 1 is more accurate since I think you're describing two options.

- Section 5.4, last paragraph:
" perhaps the destination endpoints queries" -> "perhaps the destination endpoint queries"

- Section 6.1, 3rd paragraph:  "the most obviously way" -> "the most obvious way"

- Section 6.2, 3rd paragraph:  "will need decrypt" -> "will  need to decrypt"

- Section 7.3 Again, I think a numbered list is a better way to annotate those two points.

- The reference to the VIPR overview spec isn't to the most recent version.  It should be draft-jennings-vipr-overview (and as I've said a number of times, I think it would be good to actually publish that one)

<Jon> Heh. Will update the ref at least. </Jon>