Re: [Gen-art] Genart last call review of draft-ietf-sipcore-rejected-08

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux