Subject: [MMUSIC] draft-ietf-mmusic-trickle-ice-sip-05: Christer's comments on Section 3

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Oct 2016 07:46:51 +0000

Hi,

Below are comments on Section 3. In general, it¹s about editorial stuff.
There is too much text, and text that is very difficult to understand.

Regards,

Christer

----------

Q1:

The text in Section 3 says:

   "The semantics that Vanilla ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp]
   defines for exchanging ICE candidates are exclusively based on use of
   Offers and Answers as per [RFC3264] over the Session Description
   Protocol (SDP) [RFC4566].²

I think that text is messy. Why not simply say that, when using Vanilla
ICE (or whatever we¹ll end up calling it),
ICE candidates are exchanged using the Offer/Answer mechanism.

Q2:

The text in Section 3 says:

   "This specification extends these mechanism
    by allowing ICE candidates to also be sent in parallel to the Offer/
    Answer negotiation or after the completion of Offer/Answer
    negotiation.²

First, I am not sure exactly what ³these mechanism² mean, and what you are
extending. Why not simply say that this specification defines a mechanism
where candidates can be exchanged using INFO requests.

Second, the ³parallel² wording is confusing. It sounds like you¹re only
allowed to use trickle while you have ongoing O/A negotiations.

Q3:

The text in Section 3 says:

    "Typically, in cases where Trickle ICE is fully supported, a candidate
     exchange would happen along the following lines: The Offerer would
     send an INVITE containing a subset of candidates and then wait for an
     early dialog to be established.  Once that happens, it will be able
     to continue sending candidates through in INFO requests and within
     the same dialog.

     Similarly, an Answerer can start or continue "trickling" ICE
     candidates using INFO messages within the dialog established by its
     18x provisional response.  Figure 1 shows such a sample exchange:²

I suggest to simply say that, once the early dialog has been established,
additional candidates can be exchanged using INFO requests.

Q4:

I think we can remove Section 3.1. The text belongs in the Info Package
definition (Section 10).

Q5:

In Section 3.3, both paragraphs are very difficult to read and understand.

I think what you want to say is that while INFOs are not considered
Offers/Answers, and do not increment the o= line value etc, candidates
that have been exchanged using INFO shall
be included in subsequent Offers/Answers carrying candidates.

Talking about ³traditional SIP², ³offer/answer modules² etc is just
confusing.

---

From: Thomas Stach <[email-masked]>
Date: Wed, 12 Oct 2016 13:09:52 +0200

Christer,

thanks for the feedback.

I'll address it in the next update.

Just a clarifiying question below.

> There is too much text, and text that is very difficult to understand.
Do you propose to remove the text in 3.1 completely or to move it 
section 10?
Regards
Thomas
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Oct 2016 11:20:15 +0000

Hi,

>Do you propose to remove the text in 3.1 completely or to move it

I didn¹t check what you have in section 10, but per RFC 6086 the Info
Package definition needs to explain why INFO was chosen instead of other
alternatives.

So, unless you have done that, you can move the text from section 3.1. I
do think you should make it a little shorter, though. I personally think
INFO is the obvious choice in this case, so I don¹t think you¹ll need too
much justification.

Regards,

Christer