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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 09 Aug 2019 11:38:52 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mmusic-ice-sip-sdp-38: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/

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

----------------------------------------------------------------------
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?

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.

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.

Section 5.1

I appreciate that IP address privacy is mentioned here.  (It might
be good in the security considerations, too.)

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.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Aug 2019 18:54:18 +0000

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.

    >different ice-option-tag values; the example uses a comma.
    
    DOH! I will fix that, and remove the comma.

    >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.
    
    >doesn't seem to have ended up in the document.
    
    That’s another thing still to be done.

     --- 

    Section 4.2.2
    
    > relevant specifications, so calling out any differences here might be worthwhile.

    I agree that would be useful. 
    
    ---

    > 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
    
    > are only briefly mentioned elsewhere in the document, and could be worth

    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?

    Regards,

    Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Sat, 10 Aug 2019 19:32:45 -0700

On Fri, Aug 9, 2019 at 11:54 AM Christer Holmberg <
[email-masked]> 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.
>
>     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.
>
>     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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 11 Aug 2019 09:28:21 +0000

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 <[email-masked]>
Date: Sunday, 11 August 2019 at 5.33
To: Christer Holmberg <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>, "[email-masked]" <[email-masked]>, Flemming Andreasen <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

     ---

    Section 4.2.2

    ---

    ---

    Section 9

    > are only briefly mentioned elsewhere in the document, and could be worth

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

[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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 11 Aug 2019 19:25:07 +0000

Hi Benjamin,

...

>    are only briefly mentioned elsewhere in the document, and could be worth
  
I have created a new pull request with the changes to the Security Considerations.

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

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Mon, 12 Aug 2019 15:24:05 -0500

On 8/11/19 4:28 AM, Christer Holmberg wrote:
> 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.
>

Yes; Éric raised the same point. My reply to him was: "The point of the 
examples in this document is to demonstrate the presence of a NAT. While 
they could be replaced with NPTv6 examples (or other examples of IPv6 
address translation), I think that doing so would not be in the spirit 
of the IAB statement on IPv6, even if stateless."

/a

---

From: Roman Shpount <[email-masked]>
Date: Mon, 12 Aug 2019 19:03:56 -0400

Hi Adam,

One of the common use cases for ICE is to allow correct address selection
for dual network systems. Because of this, I think it make sense to add
IPv6 host candidates to examples, since this reflects common ICE use case.

What do you think?
_____________
Roman Shpount

On Mon, Aug 12, 2019 at 6:17 PM Adam Roach <[email-masked]> wrote:

> 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.
>
>
> address translation), I think that doing so would not be in the spirit of
> the IAB statement on IPv6, even if stateless."
> /a

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Aug 2019 09:36:24 -0500

Hi Christer,

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

-Ben

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 13 Aug 2019 17:58:53 -0700

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 <[email-masked]> wrote:

> 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:
> >
> > Cc: Benjamin Kaduk <[email-masked]>, "[email-masked]" <[email-masked]>,
> Flemming Andreasen <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> > Subject: Re: [MMUSIC] Benjamin Kaduk's Discuss on
> draft-ietf-mmusic-ice-sip-sdp-38: (with DISCUSS and COMMENT)
> >
> >
> >
> [email-masked]<mailto:[email-masked]>>
> 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
> >     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.
> >
> 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
> >).
> >