[Gen-art] Genart last call review of draft-ietf-sipcore-rejected-08
Ines Robles via Datatracker <firstname.lastname@example.org> Mon, 03 June 2019 21:30 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAC312004A; Mon, 3 Jun 2019 14:30:32 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Ines Robles via Datatracker <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Reply-To: Ines Robles <email@example.com>
Date: Mon, 03 Jun 2019 14:30:32 -0700
Subject: [Gen-art] Genart last call review of draft-ietf-sipcore-rejected-08
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Mon, 03 Jun 2019 21:30:32 -0000
Reviewer: Ines Robles Review result: Ready 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.
- [Gen-art] Genart last call review of draft-ietf-s… Ines Robles via Datatracker
- Re: [Gen-art] Genart last call review of draft-ie… Alissa Cooper