Subject: [Ice] ICE behavior when zero candidates are provided by one side

From: Justin Uberti <[email-masked]>
Date: Tue, 12 Feb 2019 17:37:42 -0800

During the rollout of mDNS ICE candidate functionality in Chrome, we became
aware of a situation with ICE that probably needs to be corrected, perhaps
in -trickle.

In a case where the initiator does not supply candidates, or its candidates
are not understood by the remote endpoint, the remote endpoint will not be
able to form candidate pairs, even if it has viable local addresses. This
situation does not seem to be covered in any spec, and the expectation from
a quick re-read is that ICE would go directly to the Failed state.

However, if the endpoint simply waited for a certain amount of time, it
could learn peer-reflexive candidates from the initiator, and then proceed
normally. Accordingly, perhaps we should add some text to -trickle that
says that implementations should not conclude ICE processing immediately
once all candidate pairs have failed, and instead should wait a minimum of
one STUN timeout to allow peer-reflexive candidates to be generated.

Am I missing anything? Does -trickle seem like the most expedient place to
address this issue?

More details on the specific problem we encountered (mDNS candidate is not
understood by an ICE implementation, causing it to immediately go to the
failed state):
https://groups.google.com/d/msg/discuss-webrtc/4Yggl6ZzqZk/hihT9TWtFgAJ

---

From: Roman Shpount <[email-masked]>
Date: Tue, 12 Feb 2019 20:47:19 -0500

I was planning to propose some language related to this in
mmusic-ice-sip-sdp, specifically related to handling non-trickle cases. I
wanted to add language that if all remote candidates in session description
are discarded, either due to being candidates with
FQDN  connection-addresses which failed to resolve or due to being
candidates with unsupported address family, then ICE agent MUST not go
immediately into Failed state and must continue to wait for at least one
STUN timeout for possible incoming STUN binding requests, which can
generate peer-reflexive candidates.

Regards,
_____________
Roman Shpount

On Tue, Feb 12, 2019 at 8:38 PM Justin Uberti <juberti=
[email-masked]> wrote:

> During the rollout of mDNS ICE candidate functionality in Chrome, we
> became aware of a situation with ICE that probably needs to be corrected,
> perhaps in -trickle.
>
> In a case where the initiator does not supply candidates, or its
> candidates are not understood by the remote endpoint, the remote endpoint
> will not be able to form candidate pairs, even if it has viable local
> addresses. This situation does not seem to be covered in any spec, and the
> expectation from a quick re-read is that ICE would go directly to the
> Failed state.
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 12 Feb 2019 18:01:28 -0800

Agree with the overall assessment and solution, although I think there
could be other similar scenarios, for example, a single 192.168.1.x
candidate that is discarded by the recipient because there is no route to
the destination.

Do you think sip-sdp is the right home for this, or would this need to be
addressed in a 8445 update?

On Tue, Feb 12, 2019 at 5:47 PM Roman Shpount <[email-masked]> wrote:

> generate peer-reflexive candidates..
>
> Regards,
> _____________
> Roman Shpount
>
>
>> Failed state..
>> Am I missing anything? Does -trickle seem like the most expedient place
>> to address this issue?
>>
>> More details on the specific problem we encountered (mDNS candidate is
>> not understood by an ICE implementation, causing it to immediately go to
>> the failed state):

---

From: Roman Shpount <[email-masked]>
Date: Wed, 13 Feb 2019 00:06:14 -0500

> addressed in a 8445 update?

The ice-sip-sdp is responsible for procedures for forming the initial
remote candidate list. It is responsible for procedures for FQDN
resolution, parsing and discarding unsupported candidate addresses. Because
of this, I thought it would not be out of place to specify in ice-sip-sdp
what ICE agent should do when an empty list of candidates is generated as a
result of initial remote candidate gathering procedures.

> candidate that is discarded by the recipient because there is no route to

This is actually an interesting new case. I do not think there is anything
in ICE nomination that states that STUN binding request should fail
immediately when there is no path to the destination address, but candidate
pair does fail immediately on a hard ICMP error, which should cover this
case. Dealing with a situation when all pairs failed immediately due to
hard ICMP errors is something which has nothing to do with initial
candidate gathering and probably belongs in RFC 8445 update.

Based on this new case, I think we need RFC 8445 update that states ICE
nomination process should not fail for the duration of STUN timeout even if
the candidate pair list is empty or if all the candidate pairs failed.

Regards,
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Tue, 12 Feb 2019 21:27:13 -0800

> the candidate pair list is empty or if all the candidate pairs failed.

Agreed. That seems like a heavy lift though, so perhaps a note in sip-sdp
would suffice until said update.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 13 Feb 2019 11:09:50 -0500

On Wed, Feb 13, 2019 at 12:27 AM Justin Uberti <[email-masked]> wrote:

>>> Do you think sip-sdp is the right home for this, or would this need to
>>> be addressed in a 8445 update?
>>>
>>
>> This is actually an interesting new case. I do not think there is
>> anything in ICE nomination that states that STUN binding request should
>> fail immediately when there is no path to the destination address, but
>> candidate pair does fail immediately on a hard ICMP error, which should
>> cover this case. Dealing with a situation when all pairs failed immediately
>> due to hard ICMP errors is something which has nothing to do with initial

I will provide Suhas with the text to add to ice-sip-sdp to put back
support of FQDN and empty list handling.

Should we add an errata (with wait for documentation update) to RFC 8445 so
that implementers would be aware of the empty list issue due to all
candidate pairs failing?
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Wed, 13 Feb 2019 08:29:54 -0800

I think that's a good idea.

On Wed, Feb 13, 2019 at 8:10 AM Roman Shpount <[email-masked]> wrote:

> Should we add an errata (with wait for documentation update) to RFC 8445
> so that implementers would be aware of the empty list issue due to all
> candidate pairs failing?
> _____________
> Roman Shpount
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Feb 2019 19:37:08 +0000

Hi,

Regarding the destination-not-reachable (ICMP) case, exactly what do you suggest to say?

Regards,

Christer

From: Ice <[email-masked]> on behalf of Justin Uberti <juberti=[email-masked]>
Date: Wednesday, 13 February 2019 at 11.30
To: Roman Shpount <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Ice] ICE behavior when zero candidates are provided by one side

On Wed, Feb 13, 2019 at 8:10 AM Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Feb 13, 2019 at 12:27 AM Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Feb 12, 2019 at 9:06 PM Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Feb 12, 2019 at 9:01 PM Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
Do you think sip-sdp is the right home for this, or would this need to be addressed in a 8445 update?

The ice-sip-sdp is responsible for procedures for forming the initial remote candidate list. It is responsible for procedures for FQDN resolution, parsing and discarding unsupported candidate addresses. Because of this, I thought it would not be out of place to specify in ice-sip-sdp what ICE agent should do when an empty list of candidates is generated as a result of initial remote candidate gathering procedures.

Agree with the overall assessment and solution, although I think there could be other similar scenarios, for example, a single 192.168.1.x candidate that is discarded by the recipient because there is no route to the destination.

This is actually an interesting new case. I do not think there is anything in ICE nomination that states that STUN binding request should fail immediately when there is no path to the destination address, but candidate pair does fail immediately on a hard ICMP error, which should cover this case. Dealing with a situation when all pairs failed immediately due to hard ICMP errors is something which has nothing to do with initial candidate gathering and probably belongs in RFC 8445 update.

Based on this new case, I think we need RFC 8445 update that states ICE nomination process should not fail for the duration of STUN timeout even if the candidate pair list is empty or if all the candidate pairs failed.

Agreed. That seems like a heavy lift though, so perhaps a note in sip-sdp would suffice until said update.

I will provide Suhas with the text to add to ice-sip-sdp to put back support of FQDN and empty list handling.

Should we add an errata (with wait for documentation update) to RFC 8445 so that implementers would be aware of the empty list issue due to all candidate pairs failing?
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 13 Feb 2019 14:54:54 -0500

> Regarding the destination-not-reachable (ICMP) case, exactly what do you
I was thinking something along the following lines:

During ICE nomination process all candidate pairs can rapidly go into
Failed state if ICMP hard error is received on each of them. According to
RFC 8445 this should force entire nomination process end with the Failed
state. This can be undesirable since it would cause the ICE nomination
process to fail too quickly and not provide enough time for peer reflexive
candidates to be collected. Once example of such scenario is when client,
located on a private network behind NAT sends only host candidates to a
server on a public IP. During nomination process on the server side all
candidates can immediately fail with ICMP unreachable errors, since server
has no path to the client private network. At the same time, if failure
were delayed, the nomination would succeed once STUN binding requests from
the client are received by the server and one of the peer reflexive
candidates is nominated. To avoid this failure, it is suggested that ICE
nomination process failure SHOULD be delayed for at least one STUN timeout
interval to allow remote STUN binding requests to arrive from the remote
side and peer reflexive candidates to be collected.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Feb 2019 21:06:41 +0000

Hi,

I assume this is the text that you suggest to put into an errata?

Because, I don’t think we can put this text in draft-sip-sdp, as it is supposed to be aligned with RFC 8445.

Instead, we need to fix 8445 (using an update draft, errata or whatever), and then reference that fix in draft-sip-sdp.

Regards,

Christer

From: Roman Shpount <[email-masked]>
Date: Wednesday, 13 February 2019 at 14.55
To: Christer Holmberg <[email-masked]>
Cc: Justin Uberti <juberti=[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ice] ICE behavior when zero candidates are provided by one side

On Wed, Feb 13, 2019 at 2:37 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Regarding the destination-not-reachable (ICMP) case, exactly what do you suggest to say?

During ICE nomination process all candidate pairs can rapidly go into Failed state if ICMP hard error is received on each of them. According to RFC 8445 this should force entire nomination process end with the Failed state. This can be undesirable since it would cause the ICE nomination process to fail too quickly and not provide enough time for peer reflexive candidates to be collected. Once example of such scenario is when client, located on a private network behind NAT sends only host candidates to a server on a public IP. During nomination process on the server side all candidates can immediately fail with ICMP unreachable errors, since server has no path to the client private network. At the same time, if failure were delayed, the nomination would succeed once STUN binding requests from the client are received by the server and one of the peer reflexive candidates is nominated. To avoid this failure, it is suggested that ICE nomination process failure SHOULD be delayed for at least one STUN timeout interval to allow remote STUN binding requests to arrive from the remote side and peer reflexive candidates to be collected.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 13 Feb 2019 16:26:12 -0500

> I assume this is the text that you suggest to put into an errata?

Yes, this is the text that will go into errata.

Because, I don’t think we can put this text in draft-sip-sdp, as it is
> supposed to be aligned with RFC 8445.
>

For ice-sip-sdp I was planning to suggest the following (and I need more
time to fine tune it):

When initial set of remote candidates is gathered from the session
description, some of the candidates can be discarded. Specifically
candidates with FQDN connection-address are discarded if they do not
resolve or resolve to more then one address.  Also, candidates with
unsupported address families are discarded as well. As candidates are
discarded it is possible that all remote candidates are discarded and ICE
nomination process would start with an empty list of remote candidates. In
this case, ICE agent SHOULD NOT fail nomination process immediately and
SHOULD continue to receive remote STUN binding request on local candidate
addresses for at least one STUN timeout interval. This should allow for
STUN binding requests to arrive from the remote party and for the
nomination to proceed using peer reflexive candidates.

Instead, we need to fix 8445 (using an update draft, errata or whatever),
> and then reference that fix in draft-sip-sdp.
>

We probably need to do both.

Regards,
_____________
Roman Shpount

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 13 Feb 2019 15:18:01 -0700

On 2/12/19 10:27 PM, Justin Uberti wrote:
>     The ice-sip-sdp is responsible for procedures for forming the
>     initial remote candidate list. It is responsible for procedures for
>     FQDN resolution, parsing and discarding unsupported candidate
>     addresses. Because of this, I thought it would not be out of place
>     to specify in ice-sip-sdp what ICE agent should do when an empty
>     list of candidates is generated as a result of initial remote
>     candidate gathering procedures.
> 
>         Agree with the overall assessment and solution, although I think
>         there could be other similar scenarios, for example, a single
>         192.168.1.x candidate that is discarded by the recipient because
>         there is no route to the destination.
> 
>      
>     anything in ICE nomination that states that STUN binding request
>     should fail immediately when there is no path to the destination
>     address, but candidate pair does fail immediately on a hard ICMP
>     error, which should cover this case. Dealing with a situation when
>     all pairs failed immediately due to hard ICMP errors is something
>     which has nothing to do with initial candidate gathering and
>     probably belongs in RFC 8445 update. 
> 
> 
>     Based on this new case, I think we need RFC 8445 update that states
>     ICE nomination process should not fail for the duration of STUN
>     timeout even if the candidate pair list is empty or if all the
>     candidate pairs failed.
> 
> 

As noted in your initial message, this can happen in the trickle case of
sending zero candidates in the initial ICE description, too. But because
there are several situations where this might happen (trickle or not,
SIP or not), an update to 8445 is likely the right way to go. A heavy
lift, as you say...

Peter

---

From: Ben Campbell <[email-masked]>
Date: Wed, 13 Feb 2019 16:28:39 -0600

Responding with one point, with AD hat on:

> On Feb 13, 2019, at 10:09 AM, Roman Shpount <[email-masked]> wrote:
> 

I don’t think an errata report is the appropriate way to handle this. Errata are intended for use when we discover an error where an RFC does not reflect the intent of the WG at the time of publication. That is different from errors where we learn after the fact that we should have done something differently.

An update to 8445 seems like the right way to handle this. That update could be very short.

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 13 Feb 2019 16:30:43 -0600

> On Feb 13, 2019, at 4:18 PM, Peter Saint-Andre <[email-masked]> wrote:
> 
> lift, as you say…

Why does it need to be that heavy? We’d be talking about no more than a couple of pages, not counting boiler-plate, right?

Thanks!

Ben.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 13 Feb 2019 15:31:40 -0700

> Why does it need to be that heavy? We’d be talking about no more than a couple of pages, not counting boiler-plate, right?

Someone has to write an I-D. :-) But yeah, should be short and sweet.

Peter

---

From: Justin Uberti <[email-masked]>
Date: Wed, 13 Feb 2019 17:49:21 -0800

Would this be an extension spec, or a -bis of 8445? Agree the former could
be easy, but may be missed by many implementors.

On Wed, Feb 13, 2019 at 2:31 PM Peter Saint-Andre <[email-masked]>
wrote:

> > Why does it need to be that heavy? We’d be talking about no more than a
> couple of pages, not counting boiler-plate, right?
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 13 Feb 2019 18:50:27 -0700

On 2/13/19 6:49 PM, Justin Uberti wrote:
> Would this be an extension spec, or a -bis of 8445? Agree the former
> could be easy, but may be missed by many implementors.

Seems like an extension spec to me.

Peter

---

From: Justin Uberti <[email-masked]>
Date: Wed, 13 Feb 2019 17:56:09 -0800

OK, agree that's better than an erratum. Something like "Preventing
Premature Failure of ICE Negotiation"?

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Feb 2019 13:21:30 +0000

Hi,

Unless someone else wants to do it, I’d be happy to put together an initial draft.

Regards,

Christer

From: Ice <[email-masked]> on behalf of Justin Uberti <juberti=[email-masked]>
Date: Wednesday, 13 February 2019 at 20.57
To: Peter Saint-Andre <[email-masked]>
Cc: Ben Campbell <[email-masked]>, Roman Shpount <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ice] ICE behavior when zero candidates are provided by one side

OK, agree that's better than an erratum. Something like "Preventing Premature Failure of ICE Negotiation"?

On Wed, Feb 13, 2019 at 5:50 PM Peter Saint-Andre <[email-masked]<mailto:[email-masked]>> wrote:

Peter

---

From: Justin Uberti <[email-masked]>
Date: Thu, 14 Feb 2019 08:29:15 -0800

Roman, did you want to take a crack at it? I am happy to help write.

On Thu, Feb 14, 2019 at 5:21 AM Christer Holmberg <
[email-masked]> wrote:

> *From: *Ice <[email-masked]> on behalf of Justin Uberti <juberti=
> [email-masked]>
> *Date: *Wednesday, 13 February 2019 at 20.57
> *To: *Peter Saint-Andre <[email-masked]>
> *Cc: *Ben Campbell <[email-masked]>, Roman Shpount <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [Ice] ICE behavior when zero candidates are provided by
> one side
>
>
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 14 Feb 2019 14:01:19 -0500

Justin,

I have not gone through the technical process of submitting the draft and I
do not have enough time right now to figure it out, so I would prefer for
someone else to take the lead on this.

I think Christer already volunteered and I would be happy to provide all
the necessary text as long as he takes care of all the technical details.

Regards,
_____________
Roman Shpount

On Thu, Feb 14, 2019 at 11:29 AM Justin Uberti <[email-masked]> wrote:

>> *Cc: *Ben Campbell <[email-masked]>, Roman Shpount <[email-masked]>,
>> "[email-masked]" <[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Feb 2019 19:13:49 +0000

Hi,

I can put together a first version, put it on GitHub, and anyone can then provide text etc.

Regards,

Christer

From: Roman Shpount <[email-masked]>
Date: Thursday, 14 February 2019 at 14.01
To: Justin Uberti <[email-masked]>
Cc: Christer Holmberg <[email-masked]>, Peter Saint-Andre <[email-masked]>, Ben Campbell <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ice] ICE behavior when zero candidates are provided by one side

Justin,

I have not gone through the technical process of submitting the draft and I do not have enough time right now to figure it out, so I would prefer for someone else to take the lead on this.

I think Christer already volunteered and I would be happy to provide all the necessary text as long as he takes care of all the technical details.

Regards,
_____________
Roman Shpount

On Thu, Feb 14, 2019 at 11:29 AM Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
Roman, did you want to take a crack at it? I am happy to help write.

On Thu, Feb 14, 2019 at 5:21 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: Ice <[email-masked]<mailto:[email-masked]>> on behalf of Justin Uberti <juberti=[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 13 February 2019 at 20.57
To: Peter Saint-Andre <[email-masked]<mailto:[email-masked]>>
Cc: Ben Campbell <[email-masked]<mailto:[email-masked]>>, Roman Shpount <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] ICE behavior when zero candidates are provided by one side

Peter

---

From: Justin Uberti <[email-masked]>
Date: Thu, 14 Feb 2019 11:19:16 -0800

Sounds good - thanks Christer.

Please use markdown if possible :-)

On Thu, Feb 14, 2019 at 11:13 AM Christer Holmberg <
[email-masked]> wrote:

> *From: *Roman Shpount <[email-masked]>
> *Date: *Thursday, 14 February 2019 at 14.01
> *To: *Justin Uberti <[email-masked]>
> *Cc: *Christer Holmberg <[email-masked]>, Peter
> Saint-Andre <[email-masked]>, Ben Campbell <[email-masked]>, "
> I have not gone through the technical process of submitting the draft and
> I do not have enough time right now to figure it out, so I would prefer for

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Feb 2019 20:07:54 +0000

Just to verify, since MMUSIC will take over the maintenance of 8445, I assume this will be a MMUSIC draft?

Regards,

Christer

From: Justin Uberti <[email-masked]>
Date: Thursday, 14 February 2019 at 14.19
To: Christer Holmberg <[email-masked]>
Cc: Roman Shpount <[email-masked]>, Peter Saint-Andre <[email-masked]>, Ben Campbell <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ice] ICE behavior when zero candidates are provided by one side

On Thu, Feb 14, 2019 at 11:13 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 14 February 2019 at 14.01
To: Justin Uberti <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>>, Ben Campbell <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] ICE behavior when zero candidates are provided by one side

Justin,

Regards,
_____________
Roman Shpount

Regards,

Christer

Peter

---

From: Ben Campbell <[email-masked]>
Date: Thu, 14 Feb 2019 14:11:39 -0600

Well, we haven’t closed ICE yet, nor have we added ICE maintenance to the MMUSIC charter. (The IESG discussed this last week, and there was not a lot of support for preemptively adding ICE maintenance to the MMUSIC charter until there were actual milestones.

I’d be inclined to just do this in ICE, or even make it AD sponsored. (in order of preference.)

Chairs, thoughts?

Ben.

> On Feb 14, 2019, at 2:07 PM, Christer Holmberg <[email-masked]> wrote:
> 
> On Thu, Feb 14, 2019 at 11:13 AM Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi,
>> 
>> From: Roman Shpount <[email-masked] <mailto:[email-masked]>>
>> To: Justin Uberti <[email-masked] <mailto:[email-masked]>>
>> Cc: Christer Holmberg <[email-masked] <mailto:[email-masked]>>, Peter Saint-Andre <[email-masked] <mailto:[email-masked]>>, Ben Campbell <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> On Thu, Feb 14, 2019 at 11:29 AM Justin Uberti <[email-masked] <mailto:[email-masked]>> wrote:
>>> On Thu, Feb 14, 2019 at 5:21 AM Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
>>>> Hi,
>>>> 
>>>> From: Ice <[email-masked] <mailto:[email-masked]>> on behalf of Justin Uberti <juberti=[email-masked] <mailto:[email-masked]>>
>>>> To: Peter Saint-Andre <[email-masked] <mailto:[email-masked]>>
>>>> Cc: Ben Campbell <[email-masked] <mailto:[email-masked]>>, Roman Shpount <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>>>> On Wed, Feb 13, 2019 at 5:50 PM Peter Saint-Andre <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Feb 2019 20:21:10 +0000

I just want to know whether I shall name the document draft-holmberg-mmusic or draft-holmberg-ice 😊

From: Ben Campbell <[email-masked]>
Date: Thursday, 14 February 2019 at 15.12
To: Christer Holmberg <[email-masked]>, <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Justin Uberti <[email-masked]>, Roman Shpount <[email-masked]>, Peter Saint-Andre <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ice] ICE behavior when zero candidates are provided by one side

Chairs, thoughts?

Ben.

On Feb 14, 2019, at 2:07 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Regards,

Christer

From: Justin Uberti <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 14 February 2019 at 14.19
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: Roman Shpount <[email-masked]<mailto:[email-masked]>>, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>>, Ben Campbell <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ice] ICE behavior when zero candidates are provided by one side

Regards,

Christer

Justin,

Regards,
_____________
Roman Shpount

Regards,

Christer

Peter

---

From: Justin Uberti <[email-masked]>
Date: Thu, 14 Feb 2019 13:20:53 -0800

let's do -ice and we can deal with any needed changes later, should they be
required.

On Thu, Feb 14, 2019 at 12:21 PM Christer Holmberg <
[email-masked]> wrote:

> I just want to know whether I shall name the document
> draft-holmberg-mmusic or draft-holmberg-ice 😊
>
>
>
> *From: *Ben Campbell <[email-masked]>
> *Date: *Thursday, 14 February 2019 at 15.12
> *To: *Christer Holmberg <[email-masked]>, <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Cc: *Justin Uberti <[email-masked]>, Roman Shpount <[email-masked]>,
> Peter Saint-Andre <[email-masked]>, "[email-masked]" <[email-masked]>
> Well, we haven’t closed ICE yet, nor have we added ICE maintenance to the
> MMUSIC charter. (The IESG discussed this last week, and there was not a lot
> of support for preemptively adding ICE maintenance to the MMUSIC charter
> until there were actual milestones.
>
>
>
> *From: *Justin Uberti <[email-masked]>
> *Date: *Thursday, 14 February 2019 at 14.19
> *To: *Christer Holmberg <[email-masked]>
> *Cc: *Roman Shpount <[email-masked]>, Peter Saint-Andre <
> [email-masked]>, Ben Campbell <[email-masked]>, "[email-masked]" <
> [email-masked]>

---

From: Ari Keränen <[email-masked]>
Date: Fri, 15 Feb 2019 13:08:49 +0000

Hi Ben,

I'm thinking that this would be a great opportunity to add MMUSIC milestone and justify the charter update. But since this is unlikely to drag for long, doing this in ICE WG is OK too.

Cheers,
Ari

On 14 Feb 2019, at 22.11, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Chairs, thoughts?

Ben.

Regards,

Christer

Regards,

Christer

Justin,

Regards,
_____________
Roman Shpount

Regards,

Christer

Peter