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

Hi Christer,

Thanks, this all sounds good to me (and I'm happy to defer to Adam about
the IPv6 examples).

-Ben

On Sun, Aug 11, 2019 at 09:28:21AM +0000, Christer Holmberg wrote:
> 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