Messaging Use Cases and Extensions for STIR
draft-ietf-stir-messaging-08

Thank you for the work on this document.

Many thanks to Claudio Allocchio for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/7hg9Cvxbtn603hgBWj5uFwK52cY/

Like others I took note of the fact that this document contains an itty-bitty piece of bonafide specification [*] surrounded by a great deal of lucid, interesting, but ultimately speculative and inconclusive prose.

Unlike others I'm at peace with that. 

[*] Paragraphs two and three of Section 3.2.

Note I find the overall text very vague:

"This specification therefore explores", " there are a few ways that the PASSporT mechanism of STIR could apply to messaging:", "This could be applicable to MSRP sessions", "An Identity header could be added to any SIP MESSAGE request", "PASSporT can provide its own integrity check", "the PASSporT could be conveyed in an Identity header".

If it wasn't for the IANA registration and Section 3.2, I would have thought Informational or Experimental would have been better.

Thank you to Nancy Cam-Winget for the SECDIR review.

Thank you for addressing other DISCUSS and COMMENT points.

Thanks to the authors for writing this - I personally find use case type documents to be really useful.

I'd also like to thank Bo Wu for the OpsDir comments (https://datatracker.ietf.org/doc/review-ietf-stir-messaging-06-opsdir-lc-wu-2022-11-19/ ) - these contain some nits and editorial comments that the authors should address when folding in other comments.

I'm following John's position here: the document is mostly narrative, but that's fine with me too (AKA: ¯\_(ツ)_/¯)

Thank you for addressing my previous DISCUSS points and COMMENTs (for reference https://mailarchive.ietf.org/arch/msg/stir/nPVTeO12UKSw1bAJLwEA3A6sWig/ )

-éric

Hi, 

Thanks for the document.

I, too, support Robert's discuss position on this.  If I were looking to do an implementation, I think I'd struggle to do so based on this document, and the document doesn't seem to adequately delineate that which is informational and that which is standards.

I support Robert's DISCUSS

I found it quite hard to follow exactly what is in scope of this spec in Section 3.2. I gather there are certain modes of MESSAGE method that are in scope and others that aren't, but it would be useful to start 3.2 with a taxonomy of these modes and discuss what is in and out of scope. Considerations for the unsupported use cases are fine, but should be clearly separated out as such.

Changing position from Discuss.

I think that it is great that the authors adding some text into the intro that highlights that some text is normative and some is informative.  Really, I was hoping that the text would be quite specific about *which* parts of the document are normative or informative, either in the introduction or in the individual sections.  Specifically, I would regard that all sections of an Std Track RFC to be regarded as normative text unless there is an indication that it is informative – e.g., something like “This section provides non-normative guidance about …”

Having said that, this is not a critical issue, and hence I will clear the discuss and leave it to the authors and Murray, as responsible AD, to decide whether further changes would improve the clarity of this specification or whether the current version is sufficient.