Re: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)

[Christer Holmberg <[e-mail]>]

Hi Roman,

Thank You for the review! I will let someone that has more security expertise then I  have address your comments on section 8. For your other comments, please see inline.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

> (5) Section 3.2.6.  The example in this section is appreciated.  Additional text to explain what this example is showing would be helpful.

We will add text.

---

> (6) Section 3.4.1.2.1. Per “the offer MUST include the same set of ICE-related information that the offerer included in 
> the previous offer or answer”, what happens if the ICE information is different?

Depending on what is different the peer will either consider it a protocol error, or an ICE restart.

---

> (7) Section 3.4.1.2.2. Per “In addition, if the agent is controlling, it MUST include the ‘a=remote-candidates’ attribute for each data stream
> whose check list is in the completed state”, what is a ‘check list’ in this context?

There is a check list associated with each data stream (m= line). So, if the check list associated with a given data stream is in the completed state, the agent will include an a=remote-candidates attribute in the m= line associated with that check list/data stream.

The check list concept is described more in detail in RFC 8445 (it is not SDP specific).

---

>(8) Section 4.4. Per “If two data streams have identical ice-ufrag's, they MUST have identical ice-pwd's”, what happens if there are not identical?

It is a protocol error.

---

>(9) Section 4.4. Per “Its large upper limit allows for increased amounts of randomness to be added over time”, what is the time horizon being mentioned? 
>Is this saying that in the future, longer password and users could be adopted?

Yes.

>(10) Section 4.5.  Unlike the other sections in 4.*, this one doesn’t have an example.

Don't know what happened - it was supposed to have one 😊 I will add an example.

--

>(13) Appendix A.  (Just as Ben pointed out in his DISCUSS for the example in Section 4.6) Shouldn’t the examples in 
>this appendix include a “a=ice-options:ice2” per the guidance in Section 3.2.1.5?

Yes. We will add the attribute.

---

Regards,

Christer