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

Hi Benjamin,

The following pull request addresses most of your remaining issues that were not addressed in version -38:

https://github.com/suhasHere/ice-sip-sdp/pull/20

NOTE 1: I have not yet updated any examples with IPv6 addresses. I’d like Adam to comment on that, since he previously said it shouldn’t be done.

NOTE 2: I will copy the IP address privacy text from Section 5.1 to the Security Considerations once Suhas has incorporated the changes I did to the Security Considerations in another pull request.

NOTE 3: Regarding the rtcp attribute, I still think we shall not use SHOULD/MAY normative language, as we now align with the existing procedures in RFC 3605. However, I have added a Note that describes the change from RFC 5245, and the rtcp attribute change is also mentioned in the “Changes to RFC 5245” section that was added to the -38 version.

Also, I don’t remember whether you commented on the need for an IANA registry for the candidate attribute extensions, but FYI I have created a pull request for that too:

https://github.com/suhasHere/ice-sip-sdp/pull/19

Regards,

Christer

From: Suhas Nandakumar <suhasietf@gmail.com>
Date: Sunday, 11 August 2019 at 5.33
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, "iesg@ietf.org" <iesg@ietf.org>, Flemming Andreasen <fandreas@cisco.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "draft-ietf-mmusic-ice-sip-sdp@ietf.org" <draft-ietf-mmusic-ice-sip-sdp@ietf.org>
Subject: Re: [MMUSIC] Benjamin Kaduk's Discuss on draft-ietf-mmusic-ice-sip-sdp-38: (with DISCUSS and COMMENT)

On Fri, Aug 9, 2019 at 11:54 AM Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> 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<https://protect2.fireeye.com/url?k=035ce5d6-5fd54a1f-035ca54d-0cc47ad93e1c-d6a6721d40020605&q=1&u=https%3A%2F%2Fgithub.com%2FsuhasHere%2Fice-sip-sdp%2Fpull%2F18%2Ffiles>).

    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
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic