Re: [MMUSIC] Benjamin Kaduk's Discuss on draft-ietf-mmusic-ice-sip-sdp-38: (with DISCUSS and COMMENT)

[Suhas Nandakumar <[e-mail]>]

On Fri, Aug 9, 2019 at 11:54 AM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
>     First, as I also indicated to Alexey, the new version of the draft was
> submitted before all IESG issues had been resolved, due to a
> misunderstanding among the authors. Sorry for the confusion.
>
>     ----------------------------------------------------------------------
>     DISCUSS:
>     ----------------------------------------------------------------------
>
>     >A fairly minor point, but the example in Section 5.6 is not compliant
>     >with the ABNF for the ice-options production, which uses SP to
> separate
>     >different ice-option-tag values; the example uses a comma.
>
>     DOH! I will fix that, and remove the comma.
>
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>
>     >Thank you for addressing most of my comments from the -37!  A few
>     >still remain, below.
>     >
>     >Can you remind me why the discussion of an additional three-second
>     >waiting period for SIP with forking was removed from (now-) Section 7?
>
>     I removed the paragraph because I don't think there was anything SIP
> specific about it.
>
>     Also, my intention was to move the text about forking to Section 7.3,
> but that's another thing I didn't have time to do before the new version
> was submitted.
>
>     >Do we have anywhere a definition of what it means to "indicate ICE
>     >support in an SDP offer/answer"?  (As distinct from ice2 support.)  I
> remember
>     >some discussion about containing a ufrag/password being enough, but
> that
>     >doesn't seem to have ended up in the document.
>
>     That’s another thing still to be done.
>
>      ---
>
>     Section 4.2.2
>
>     > Aren't "rtcp attribute SHOULD be included" and "rtcp attribute MAY be
>     > omitted" just duplicating existing normative requirements from
> previous
>     > specifications (which thus would not need new normative language
> here)?
>     > I think we talked about how this is slightly different from some of
> the previous
>     > relevant specifications, so calling out any differences here might
> be worthwhile.
>
>     I agree that would be useful.
>
>     ---
>
>     > Section 5.1
>     >
>     > I appreciate that IP address privacy is mentioned here.  (It might
>     > be good in the security considerations, too.)
>
>     Another thing I didn't do before the new version was submitted. I will
> fix that.
>
>     ---
>
>     Section 9
>
>     > I think this top-level section would be a great place to reiterate
> that
>     > the SDP and ICE security considerations apply, since we are using
> both
>     > of them in combination.  Specifically, the IP Address Privacy
> concerns
>     > are only briefly mentioned elsewhere in the document, and could be
> worth
>     > reiterating.
>
>     That's strange. I had done that change in the pull request (
> https://github.com/suhasHere/ice-sip-sdp/pull/18/files).
>
>     In fact, it seems like none of the changes to the security
> considerations have been incorporated. Suhas?
>

[Suhas] That was an oversight Christer. We can ensure the differential gets
added in the follow up version.
Sorry for the confusion.


>
>     Regards,
>
>     Christer
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>