Subject: [MMUSIC] Mirja Kühlewind's No Objection on draft-ietf-mmusic-ice-sip-sdp-37: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Mon, 05 Aug 2019 10:18:48 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mmusic-ice-sip-sdp-37: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) First I have a processing question for the IESG (and maybe the RFC editor)
but it might be just me not knowing this: As I understand it, RFC5245 was spilt
up into RFC8445 and this document, however, I find it a bot odd that both
documenst obsolete RFC5245. Is that what we usually do? Did we have this case
before? Is that the right thing to do?

2) One quick question: Why is a port value of "9" used to signal use of the
default destination, instead of e.g. "0"? Is that because port "0" is used to
reset the data stream? However, couldn't this combination of address and port
"0" not be treated differently? Or is that to avoid any potential false
connections? How could that happen? Isn't there a better way to do that? I
mainly would like to understand what the reason is and maybe request to also
explain this in the document.

3) A minor editorial comment
Sec 4: "This specification defines eight new SDP attributes"
Given these attributes have already been specified in RFC5245, I wouldn't call
them "new".

4) Question on sec 4.1:
"   <transport>:  indicates the transport protocol for the candidate.
      This specification only defines UDP.  However, extensibility is
      provided to allow for future transport protocols to be used with
      ICE by extending the sub-registry "ICE Transport Protocols" under
      "Interactive Connectivity Establishment (ICE)" registry."
The registry also contain an entry for TCP (see RFC6544). However, I also
wonder a bit why a new registry was created initially instead of just using the
protocol numbers or keyword in the IANA Protocol Numbers Registry...?

5) A request in section 5.4:
"If absent in an offer and answer the default value of the attribute
   is 50 ms, which is the recommended value specified in [RFC8445]."
RFC8445 also specifies a minimum of 5ms (MUST). It would be good to also
indicate here that this minimum exists without relying on the user to look up
RFC8445.

6) Also further on in section 5.4:
   "Once both agents have indicated the pacing value they with to use,
   both agents MUST use the larger of the indicated values."
Given this in normatively specified in RFC8445, maybe you should not use
normative language in this document but provide in addition again a reference
to RFC8445.

7) And similar on the use of MUST in section 5:
"The keepalives MUST be sent
   regardless of whether the data stream is currently inactive, .."
This is specified in RFC8445, so maybe consider not using normative language
here as well... however, this case is maybe less clear.

8) You probably should explicitly instruct IANA in the IANA consideration
section to update the references to this RFC instead of RFC5245 in the
respective registry.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 5 Aug 2019 14:27:33 -0400

Hi Mirja,

Thank you for your comments. Let me try to address some of them

> explain this in the document.

The reason port "9" is used is due to port "0" having a special meaning in
offer/answer SDP negotiations. Port "0" specifies that "m=" section in SDP
is not used in the offer or that data stream specified by this "m=" section
is refused in the answer. Most of the SDP offer/answer implementations
simply ignore the whole m= section when they see port "0" in the "m=" line.
On the other hand, when port "9" is set in the "m=" line and "0.0.0.0"/"::"
address is set in the "c=", this 'm=" section is still processed. Setting
"c=" line address to  "0.0.0.0"/"::" with port in "m=" line to "9", tells
the ICE agent that ICE mismatch is not triggered, regardless of what ICE
candidates are specified for this "m=" section.  This is specifically used
in combination of trickle ICE, where SDP can be sent before ICE candidates
are collected, so default candidate cannot be picked and "0.0.0.0"/"::" and
port "9" are used as a placeholder.

> protocol numbers or keyword in the IANA Protocol Numbers Registry...?

This registry was setup to provide a place to register an RFC which defines
ICE procedures for a specific transport protocol. ICE cannot operate over
all the protocols defined in IANA protocol registry and requires specific
procedures for protocols where it can operate. Futhermore, protocols used
by ICE are not necessarily protocols that are defined by IANA. For
instance, there was a discussion of defining ICE over TLS/TCP, which is not
a IANA protocol.

The rest of the comments are mostly editorial and I would let people
primarily editing the document address them.

 Best Regards,
______________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Aug 2019 18:44:34 +0000

Hi Mirja,

Thank You for the review! Please see inline.

>1) First I have a processing question for the IESG (and maybe the RFC editor) but it might be just me not knowing this: 
>As I understand it, RFC5245 was spilt up into RFC8445 and this document, however, I find it a bot odd that both documenst 
>obsolete RFC5245. Is that what we usually do? Did we have this case before? Is that the right thing to do?

That's a good question. I hope the chairs and/or the AD can give some guidance.

---

>2) One quick question: Why is a port value of "9" used to signal use of the default destination, instead of e.g. "0"? Is that
>because port "0" is used to reset the data stream? 

Correct.

>However, couldn't this combination of address and port "0" not be treated differently? Or is that to avoid any potential false connections? 
>How could that happen? Isn't there a better way to do that? I mainly would like to understand what the reason is and maybe request to also explain this in the document.

The usage of port '9' comes from the SDP rules for negotiating a TCP stream (RFC 4145), where port '9' means that the port value can be discarded.

For ICE, port '9' will be used with the ICE Trickle extension, where you don't yet provide any candidate when you send the SDP, having the same the-port-can-be-discarded meaning.

---

>Given these attributes have already been specified in RFC5245, I wouldn't call them "new".

I guess we could remove "new".

---

> The registry also contain an entry for TCP (see RFC6544). However, I also wonder a bit why a new registry was created initially instead 
> of just using the protocol numbers or keyword in the IANA Protocol Numbers Registry...?

Unfortunately I don't know. The registry was created in RFC 6544, and I was not much involved in the work on that draft.

Anyone else know? Jonathan?

---

> RFC8445 also specifies a minimum of 5ms (MUST). It would be good to also indicate here that this minimum exists without relying on the user to look up RFC8445.

5ms is not only the minimum value for an agent, it is the minimum combined value for all agents - if you e.g., have a browser with multiple tabs, each using ICE for WebRTC.

So, we need to say that. Something like:

   "As defined in [RFC8455], regardless of the Ta value chosen for each agent, the combination of
    all transactions from all agents (if a given implementation runs several concurrent agents) must not
    be sent more often than once every 5 ms." 

(I assume you mean section 4.5)

---

>   "Once both agents have indicated the pacing value they with to use, both agents MUST use the larger of the indicated values."
>Given this in normatively specified in RFC8445, maybe you should not use normative language in this document but provide in addition again a reference to RFC8445.

I suggest:

   "As defined in [RFC8455], once both agents have indicated the pacing value they want to use, both agents will use the larger of the indicated values."

(I assume you mean section 4.5)

---

7) And similar on the use of MUST in section 5:
"The keepalives MUST be sent
   regardless of whether the data stream is currently inactive, .."
This is specified in RFC8445, so maybe consider not using normative language here as well... however, this case is maybe less clear.

I suggest:

   "As defined in [RFC8455], the keepalives will be sent..."

---

8) You probably should explicitly instruct IANA in the IANA consideration section to update the references to this RFC instead of RFC5245 in the respective registry.

Good point. Will do that.

---

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Aug 2019 18:45:47 +0000

What Roman replied :)

Regards,

Christer

Lähettäjä: Roman Shpount <[email-masked]>
Lähetetty: maanantai 5. elokuuta 2019 21.28
Vastaanottaja: Mirja Kühlewind <[email-masked]>
Kopio: The IESG <[email-masked]>; lemming Andreasen <[email-masked]>; [email-masked]; mmusic WG <[email-masked]>; [email-masked]
Aihe: Re: [MMUSIC] Mirja Kühlewind's No Objection on draft-ietf-mmusic-ice-sip-sdp-37: (with COMMENT)

Hi Mirja,

On Mon, Aug 5, 2019 at 1:19 PM Mirja Kühlewind via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

The reason port "9" is used is due to port "0" having a special meaning in offer/answer SDP negotiations. Port "0" specifies that "m=" section in SDP is not used in the offer or that data stream specified by this "m=" section is refused in the answer. Most of the SDP offer/answer implementations simply ignore the whole m= section when they see port "0" in the "m=" line. On the other hand, when port "9" is set in the "m=" line and "0.0.0.0"/"::" address is set in the "c=", this 'm=" section is still processed. Setting "c=" line address to  "0.0.0.0"/"::" with port in "m=" line to "9", tells the ICE agent that ICE mismatch is not triggered, regardless of what ICE candidates are specified for this "m=" section.  This is specifically used in combination of trickle ICE, where SDP can be sent before ICE candidates are collected, so default candidate cannot be picked and "0.0.0.0"/"::" and port "9" are used as a placeholder.

4) Question on sec 4.1:

This registry was setup to provide a place to register an RFC which defines ICE procedures for a specific transport protocol. ICE cannot operate over all the protocols defined in IANA protocol registry and requires specific procedures for protocols where it can operate. Futhermore, protocols used by ICE are not necessarily protocols that are defined by IANA. For instance, there was a discussion of defining ICE over TLS/TCP, which is not a IANA protocol.

The rest of the comments are mostly editorial and I would let people primarily editing the document address them.

 Best Regards,
______________
Roman Shpount

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 6 Aug 2019 11:11:32 +0200

Thanks for the explanation!

> On 5. Aug 2019, at 20:27, Roman Shpount <[email-masked]> wrote:
> 
> Hi Mirja,
> 
> Thank you for your comments.. Let me try to address some of them
> 
> On Mon, Aug 5, 2019 at 1:19 PM Mirja Kühlewind via Datatracker <[email-masked]> wrote:
> The reason port "9" is used is due to port "0" having a special meaning in offer/answer SDP negotiations. Port "0" specifies that "m=" section in SDP is not used in the offer or that data stream specified by this "m=" section is refused in the answer. Most of the SDP offer/answer implementations simply ignore the whole m= section when they see port "0" in the "m=" line. On the other hand, when port "9" is set in the "m=" line and "0.0..0.0"/"::" address is set in the "c=", this 'm=" section is still processed. Setting "c=" line address to  "0.0.0.0"/"::" with port in "m=" line to "9", tells the ICE agent that ICE mismatch is not triggered, regardless of what ICE candidates are specified for this "m=" section.  This is specifically used in combination of trickle ICE, where SDP can be sent before ICE candidates are collected, so default candidate cannot be picked and "0.0.0.0"/"::" and port "9" are used as a placeholder.
>  
> 4) Question on sec 4.1:
> This registry was setup to provide a place to register an RFC which defines ICE procedures for a specific transport protocol. ICE cannot operate over all the protocols defined in IANA protocol registry and requires specific procedures for protocols where it can operate.. Futhermore, protocols used by ICE are not necessarily protocols that are defined by IANA. For instance, there was a discussion of defining ICE over TLS/TCP, which is not a IANA protocol.
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 6 Aug 2019 11:12:18 +0200

Yes, sounds all good. You could eventually consider to add some explanation about why port 9 is used in the text but that’s optional… Thanks!

> On 5. Aug 2019, at 20:44, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Mirja,
>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 7 Aug 2019 08:48:00 -0400

> Thank You for the review! Please see inline.
I'm not sure either. Maybe Adam knows ?

-- Flemming

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 7 Aug 2019 10:49:46 -0400

> I'm not sure either. Maybe Adam knows ?

I'm not Adam. Nevertheless...

This is just about clarity and use of terminology, right?

Some parts of 5245 have been replaced by 8445, and other parts by this 
document. And this document has a normative dependency on 8445, and not 
on 5245. RFC8445 also makes normative changes (enumerated in section 21) 
to the parts of 5245 that it covers. That seems to justify it obsoleting 
5245.

But 8445 doesn't address the parts of 5245 that are covered by this 
document. For that you also need this document.

Consider somebody who has an implementation of ICE is SIP that currently 
references 5245. Somebody tells him that 5245 is now obsolete. So he 
checks the tracker and finds that it has been obsoleted by 8445. When he 
checks the changes from 5245 he finds a reference to this document.

That seems good enough to me. This document is just a supplement to the 
one that obsoletes 5245, and so it doesn't itself need to obsolete 5245.

BUT:

RFC8445 has section 21 that highlights what is new since 5245. That is 
good as far as it goes. But that doesn't cover changes to the parts of 
5245 that covered sip & sdp.

ISTM that this document also needs a section on changes from 5245.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Aug 2019 16:23:49 +0000

Hi,

My suggestion is:

1) We remove the obsolete-RFC4245 part. 
2) We describe the changes (as far as SIP and SDP is concerned) from RFC 5245.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: mmusic <[email-masked]> Puolesta Paul Kyzivat
Lähetetty: keskiviikko 7. elokuuta 2019 17.50
Vastaanottaja: [email-masked]
Aihe: Re: [MMUSIC] Mirja Kühlewind's No Objection on draft-ietf-mmusic-ice-sip-sdp-37: (with COMMENT)

On 8/7/19 8:48 AM, Flemming Andreasen wrote:
>>> As I understand it, RFC5245 was spilt up into RFC8445 and this 
>>> document, however, I find it a bot odd that both documenst obsolete RFC5245. Is that what we usually do? Did we have this case before? Is that the right thing to do?

Some parts of 5245 have been replaced by 8445, and other parts by this document. And this document has a normative dependency on 8445, and not on 5245. RFC8445 also makes normative changes (enumerated in section 21) to the parts of 5245 that it covers. That seems to justify it obsoleting 5245.

But 8445 doesn't address the parts of 5245 that are covered by this document. For that you also need this document.

Consider somebody who has an implementation of ICE is SIP that currently references 5245. Somebody tells him that 5245 is now obsolete. So he checks the tracker and finds that it has been obsoleted by 8445. When he checks the changes from 5245 he finds a reference to this document.

That seems good enough to me. This document is just a supplement to the one that obsoletes 5245, and so it doesn't itself need to obsolete 5245.

BUT:

RFC8445 has section 21 that highlights what is new since 5245. That is good as far as it goes. But that doesn't cover changes to the parts of
5245 that covered sip & sdp.

	Thanks,
	Paul

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Adam Roach <[email-masked]>
Date: Wed, 7 Aug 2019 13:52:55 -0500

> I'm not sure either. Maybe Adam knows ? 

I don't think there's any issue with the situation. I've copied Heather 
to see if she sees any issues with two documents obsoleting the same one.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Aug 2019 19:16:26 +0000

Hi,

I have created a PR that removes the 5245-obsolete, and adds a section that describes the SDP O/A related changes done from 5245. Those I think are useful to have - no matter if this document ends up obsoleting 5245 or not...

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

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: mmusic <[email-masked]> Puolesta Paul Kyzivat
Lähetetty: keskiviikko 7. elokuuta 2019 17.50
Vastaanottaja: [email-masked]
Aihe: Re: [MMUSIC] Mirja Kühlewind's No Objection on draft-ietf-mmusic-ice-sip-sdp-37: (with COMMENT)

BUT:

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 7 Aug 2019 16:13:19 -0400

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

Thanks. The list of changes is very helpful.

	Paul

---

From: Heather Flanagan <[email-masked]>
Date: Wed, 7 Aug 2019 14:54:38 -0700

> On Aug 7, 2019, at 11:52 AM, Adam Roach <[email-masked]> wrote:
> 
> I don't think there's any issue with the situation. I've copied Heather to see if she sees any issues with two documents obsoleting the same one.
> 

It’s not a problem, though I would expect that RFC8445 and draft-ietf-mmusic-ice-sip-sdp explain how/why they each obsolete RFC5245. 

-Heather

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Aug 2019 14:41:17 +0000

Hi Heather,

Thank You for your input!

    > It’s not a problem, though I would expect that RFC8445 and draft-ietf-mmusic-ice-sip-sdp explain how/why they each obsolete RFC5245. 
    
    There will be text regarding how/why 5245 was obsoleted in either case.

    So, what people want to do? Does ice-sip-sdp obsolete 5245 or not?

Regards,

Christer

    -Heather

---

From: "Suhas Nandakumar (snandaku)" <[email-masked]>
Date: Thu, 8 Aug 2019 14:47:17 +0000

Sent from my iPhone

> On Aug 8, 2019, at 7:42 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Heather,
> 

I feel just listing the differences from rfc5245 is enough without explicit statement about obsoleting rfc5245

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 8 Aug 2019 10:58:02 -0400

>      So, what people want to do? Does ice-sip-sdp obsolete 5245 or not?

I don't think it matters. Either way is fine with me. (As long as the 
differences are listed.)

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 8 Aug 2019 11:03:52 -0400

>      So, what people want to do? Does ice-sip-sdp obsolete 5245 or not?
I believe it does.

-- Flemming (as individual)

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 8 Aug 2019 21:02:54 -0700

Hello All

 We submitted version 38 addressing the IESG reviews. This version does say
it obsoletes rfc5245 since it ranked highest in the responses but also
includes the explanation showing the differences.

Thanks
Suhas

On Thu, Aug 8, 2019 at 8:04 AM Flemming Andreasen <[email-masked]>
wrote:

> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>
>