[MMUSIC] Changes for draft-ietf-mmusic-trickle-ice-sip-14 - 3PCC

[Thomas Stach <[e-mail]>]

All,

during IESG review we got the below DISCUSS by Adam on the 3PCC procedures.

During the discussion the followed Ben indicated that he would be ok to 
remove the section.

In the interest of finishing the document, I'd remove the corresponding 
section by end of the week, unless somebody objects,.

If people think that explicit 3PCC would be needed for Trickle-ICE, this 
could be deferred to a separate draft.

Excerpt from Adam'S IESG review:

---------------------------------------------------------------------------

§4.3.4 discusses the interaction of 3PCC with the trickle ICE mechanism.
Unfortunately, the diagrams used in this section do not show a 3PCC signaling
flow; they show a two-party call flow with an offerless INVITE. A 3PCC call flow
would necessarily involve a 3PCC controller sending an offerless INVITE to one
party, receiving an offer from that party (typically in a reliable provisional
response or in a 200 OK), and then sending an INVITE to the other party
containing that offer.

The text in this section matches the diagrams, and consequently does not appear
to be an analysis of 3PCC behavior. It is an analysis of two-party offerless
INVITE behavior.

If this section remains, it needs to be substantially re-worked: the diagrams
need to show three parties, with a 3PCC controller performing the controlling
role as described in RFC 3725. While I haven't stepped through the implications
for Trickle ICE when a controller is actually involved and is moving offers and
answers around between different message types, I suspect that the analysis in
here is substantially different once this starts happening.

I would personally be okay if the entire section were removed; however, I
have no desire to override working group consensus regarding the value of a
section dealing with 3PCC considerations.

---------------------------------------------------------------------------



Regards

Thomas