Last Call Review of draft-ietf-sipcore-rejected-08
review-ietf-sipcore-rejected-08-genart-lc-robles-2019-06-03-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-sipcore-rejected-08
Reviewer: Ines Robles
Review Date: 2019-06-03
IETF LC End Date: 2019-06-04
IESG Telechat date: Not scheduled for a telechat

Summary:

I believe the draft is technically good. This document is well written.

The document defines the 608 (Rejected) SIP response code, that  enables
calling parties to learn that an intermediary rejected their call attempt.

I have some minor questions.

Major issues: none

Minor issues: none

Nits/editorial comments:

Section 1- I think it would be nice to expand SIP and add a reference to
RFC3261 the first time that SIP is mentioned in the Introduction.

Comments/Questions:

1- Section 1. "...a user (human)..."

  A user could be as well a smart device, right?. For example, in a smart home
  scenario, we have Alexa rejecting a call from a supermarket. The call
  rejection is ordered by a human or ordered by another device (e.g. a fridge
  with temporal calling-management functions that can send commands to Alexa to
  accept, reject calls from supermarket ). In the latter case the user is not a
  human, but a smart device.  In this case, Alexa would be the UAS?

  2- In Figure 2 is not clear to me if the INVITE command goes as well to the
  "call analytics engine" entity, since the arrow goes directly to the UAS.

  Should this image indicate arrows to the "call analytics engine" entity, to
  be aligned with figure 1?

  3- Figure 5:

                                                                                                        +-+--+-+
+---+         +-----+          +---+         +-----+         +-----+          
|Called| |UAC+--->+Proxy+--->+SBC+--->+Proxy+--->+Proxy+--->+Party | +---+     
    +-----+           +---+        +-----+         +-----+          |Proxy |
                                                                                                         +------+

  3.1- The arrows of the UAC to the Called Party Proxy are unidirectional.
  Should be bidirectional? Since there are messages from the Called Party Proxy
  entity to the SBC, and then to the UAC.

  3.2- Should the "Proxy" entities be identified for example with Proxy A,
  Proxy B and Proxy C, to indicate that they are different Proxy entities?

  3.3- Should be added in the figure the flow of messages that the "Proxy"
  entities goes through, or at least mentioned when explaining figure 5.

  Thank you for this draft,

  Ines.