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

[Suhas Nandakumar <[e-mail]>]

We just submitted version -39 addressing pending IESG DISCUSS comments.
please let us know

thanks
Suhas

On Tue, Aug 13, 2019 at 7:36 AM Benjamin Kaduk <[e-mail]> wrote:

> 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 <[e-mail]>
> > Date: Sunday, 11 August 2019 at 5.33
> > To: Christer Holmberg <[e-mail]>
> > Cc: Benjamin Kaduk <[e-mail]>, "[e-mail]" <[e-mail]>,
> Flemming Andreasen <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <
> [e-mail]>
> > 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 <
> [e-mail]<mailto:[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<
> 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
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/mmusic
>