Ines, thanks for your review, which I pointed to in my No Objection ballot. Alissa > On Jun 3, 2019, at 5:30 PM, Ines Robles via Datatracker <noreply@xxxxxxxx> wrote: > > 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 mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
