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

[Mary Barnes <[e-mail]>]

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)