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

[Roman Danyliw <[e-mail]>]

Hi Christer!

Thanks for the quick follow-up.  There is one detail below to consider, but I've covered otherwise.

> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> Sent: Tuesday, August 6, 2019 9:03 AM
> To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: VS: Roman Danyliw's Discuss on draft-ietf-mmusic-ice-sip-sdp-37:
> (with DISCUSS and COMMENT)
> 
> 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.

Understood.  Thanks or the clarification.

> ---
> 
> > (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).

Got it.  That's context I didn't have.  Thanks.

> ---
> 
> >(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.

Is there generic guidance that would make that obvious in other SIP/SDP error handling, or should that be said explicitly?

> ---
> 
> >(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.

Got it. 

> >(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.

Thanks.

> --
> 
> >(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.

Thanks.

> ---

Regards,
Roman

> Regards,
> 
> Christer