Subject: Re: [MMUSIC] draft-ietf-rtcweb-mdns-ice-candidates

From: Justin Uberti <[email-masked]>
Date: Fri, 11 Dec 2020 20:01:21 -0800

Youenn and Qingsi have resolved several issues over the past week. There
are a few remaining issues to discuss, but I think we can have this ready
for last call within the month, perhaps earlier.

On Mon, Oct 26, 2020 at 5:20 PM Flemming Andreasen <[email-masked]>
wrote:

> Going back to the original question: What do the authors view as a
> realistic timeframe for getting the draft ready for publication ?
>
> Thanks
>
> -- Flemming
>
> On 10/22/20 1:54 AM, Justin Uberti wrote:
>
> This is currently supported in Safari iOS, and we are working to bring
> this to Chrome Android as well.
>
> On Wed, Oct 21, 2020 at 8:47 AM Roman Shpount <[email-masked]> wrote:
>
>> I would like to see if there any implementations of this draft on mobile
>> networks. I think this draft's interactions with mobile network deployment
>> scenarios, such as 464XLAT, should be examined in detail before this draft
>> is ready for publication. Also, mDNS is not currently supported on Android,
>> which represents a significant portion of this draft use case, making some
>> of the implementation details a bit fuzzy. My main concern here is if the
>> mDNS name which is associated with one IP address always resolves to the
>> same IP address with the same address family when resolved on the same
>> network.
>>
>> Best Regards,
>> _____________
>> Roman Shpount
>>
>>
>> On Wed, Oct 21, 2020 at 11:04 AM Flemming Andreasen <fandreas=
>> [email-masked]> wrote:
>>
>>> By publication we mean that the draft is considered to be in the final
>>> ready state with no known issues, whether technical or editorial. At that
>>> point, the Working Group chairs will do (another) thorough review of the
>>> document, and if it looks ready then ask for publication of the document,
>>> which means it will be sent to the responsible Area Director for review,
>>> and subsequently to the IESG for further review and eventually it's
>>> published as an RFC.
>>>
>>> Thanks
>>>
>>> -- Flemming
>>>
>>> On 10/21/20 10:48 AM, Youenn Fablet wrote:
>>>
>>> I am also fuzzy about what it means to publish the draft.
>>> It seems to me the document is ready for another version to be published.
>>> To produce the final version that we expect to go to validation, we
>>> should probably finish resolving the 8 remaining issues and update the spec
>>> according the resolutions of these 8 issues.
>>>
>>> On 21 Oct 2020, at 16:33, Flemming Andreasen <[email-masked]> wrote:
>>>
>>> It all depends on how mature the draft is, especially in terms of its
>>> technical content. Also, we will need a few reviewers to look closely at
>>> the draft to see if there are any issues the authors may not have thought
>>> of.
>>>
>>> Cheers
>>>
>>> -- Flemming
>>>
>>>
>>>
>>> On 10/20/20 10:55 PM, Qingsi Wang wrote:
>>>
>>> Hi Flemming,
>>>
>>> I'm sorry for not being familiar with the process. In addition to
>>> editorial revisions and addressing comments, are there other prerequisites
>>> for publication?
>>>
>>> Thanks,
>>> Qingsi
>>>
>>> On Tue, Oct 20, 2020 at 7:47 PM Flemming Andreasen <[email-masked]>
>>> wrote:
>>>
>>>> Thanks Justin. What do the authors view as a realistic timeframe for
>>>> getting the draft ready for publication ?
>>>>
>>>> Cheers
>>>>
>>>> -- Flemming
>>>>
>>>> On 10/19/20 8:08 PM, Justin Uberti wrote:
>>>>
>>>> New draft posted (now with -mmusic name) and waiting for approval.
>>>>
>>>> On Thu, Oct 15, 2020 at 12:40 PM Justin Uberti <[email-masked]>
>>>> wrote:
>>>>
>>>>> This fell off my radar, will update the draft shortly though.
>>>>>
>>>>> On Fri, Sep 18, 2020 at 9:13 AM Flemming Andreasen <fandreas=
>>>>> [email-masked]> wrote:
>>>>>
>>>>>> It looks like we have at least 5 people interested in and willing to
>>>>>> contribute to the work. Based on this, the chairs will work with our AD on
>>>>>> getting a new milestone added.
>>>>>>
>>>>>> I see that the current draft has expired though - can we get an
>>>>>> updated version submitted first ?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -- Flemming (as MMUSIC co-chair)
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 9/2/20 2:57 PM, Qingsi Wang wrote:
>>>>>>
>>>>>> I am interested and willing to contribute to this document too.
>>>>>>
>>>>>> Best,
>>>>>> Qingsi
>>>>>>
>>>>>> On Wed, Sep 2, 2020 at 11:51 AM Youenn Fablet <youenn=
>>>>>> [email-masked]> wrote:
>>>>>>
>>>>>>> I am interested and willing to contribute to the document.
>>>>>>> The proposal being implemented by various parties, having this
>>>>>>> document be reviewed and ironed out as much as possible is valuable.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Y
>>>>>>>
>>>>>>> On 2 Sep 2020, at 20:09, Flemming Andreasen <[email-masked]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> So far I've only seen 2 people expressing an interest in this
>>>>>>> document.
>>>>>>>
>>>>>>> Is anybody else interested, and if so, are you willing to contribute
>>>>>>> and/or review the document ?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> -- Flemming (as MMUSIC co-chair)
>>>>>>>
>>>>>>> On 7/31/20 12:16 AM, Roman Shpount wrote:
>>>>>>>
>>>>>>> I am strongly in favor of adopting this draft to MMUSIC and getting
>>>>>>> it completed.
>>>>>>> _____________
>>>>>>> Roman Shpount
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jul 30, 2020 at 7:33 PM Justin Uberti <juberti=
>>>>>>> [email-masked]> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> With the closure of rtcweb, we have been advised to find a new
>>>>>>>> forum for
>>>>>>>> https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04,
>>>>>>>> and MMUSIC seems like the best home for it.
>>>>>>>>
>>>>>>>> I believe this document is in fairly good shape and should be ready
>>>>>>>> for last call soon. Any objections to taking it on in this working group?
>>>>>>>>
>>>>>>>> Justin
>>>>>>>> _______________________________________________
>>>>>>>> mmusic mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> mmusic mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>>>>>>
>>>>>>
>>>>>>
>>>>
>>> _______________________________________________
>>> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 14 Dec 2020 10:17:31 -0500

Thanks Justin

We submitted a milestone update a little while back and are just waiting 
for the AD go-ahead. In the meantime, it would be good to have any 
remaining issues discussed on the mailing list as well.

Cheers

-- Flemming

On 12/11/20 11:01 PM, Justin Uberti wrote:
> Youenn and Qingsi have resolved several issues over the past week. 
> There are a few remaining issues to discuss, but I think we can have 
> this ready for last call within the month, perhaps earlier.
>
> On Mon, Oct 26, 2020 at 5:20 PM Flemming Andreasen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>     This is currently supported in Safari iOS, and we are working to
>>     bring this to Chrome Android as well.
>>
>>     On Wed, Oct 21, 2020 at 8:47 AM Roman Shpount <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>         I would like to see if there any implementations of this
>>         draft on mobile networks. I think this draft's interactions
>>         with mobile network deployment scenarios, such as 464XLAT,
>>         should be examined in detail before this draft is ready for
>>         publication. Also, mDNS is not currently supported on
>>         Android, which represents a significant portion of this draft
>>         use case, making some of the implementation details a bit
>>         fuzzy. My main concern here is if the mDNS name which is
>>         associated with one IP address always resolves to the same IP
>>         address with the same address family when resolved on the
>>         same network.
>>
>>         Best Regards,
>>         _____________
>>         Roman Shpount
>>
>>
>>         On Wed, Oct 21, 2020 at 11:04 AM Flemming Andreasen
>>         <fandreas=[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>
>>             By publication we mean that the draft is considered to be
>>             in the final ready state with no known issues, whether
>>             technical or editorial. At that point, the Working Group
>>             chairs will do (another) thorough review of the document,
>>             and if it looks ready then ask for publication of the
>>             document, which means it will be sent to the responsible
>>             Area Director for review, and subsequently to the IESG
>>             for further review and eventually it's published as an RFC.
>>
>>             Thanks
>>
>>             -- Flemming
>>
>>>             To produce the final version that we expect to go to
>>>             validation, we should probably finish resolving the 8
>>>             remaining issues and update the spec according the
>>>             resolutions of these 8 issues.
>>>
>>>>             On 21 Oct 2020, at 16:33, Flemming Andreasen
>>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>             It all depends on how mature the draft is, especially
>>>>             in terms of its technical content. Also, we will need a
>>>>             few reviewers to look closely at the draft to see if
>>>>             there are any issues the authors may not have thought of.
>>>>
>>>>             Cheers
>>>>
>>>>             -- Flemming
>>>>
>>>>
>>>>
>>>>>             I'm sorry for not being familiar with the process. In
>>>>>             addition to editorial revisions and addressing
>>>>>             comments, are there other prerequisites for publication?
>>>>>
>>>>>             Thanks,
>>>>>             Qingsi
>>>>>
>>>>>             On Tue, Oct 20, 2020 at 7:47 PM Flemming Andreasen
>>>>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>
>>>>>                 Thanks Justin. What do the authors view as a
>>>>>>                 On Thu, Oct 15, 2020 at 12:40 PM Justin Uberti
>>>>>>                 <[email-masked] <mailto:[email-masked]>>
>>>>>>                 wrote:
>>>>>>
>>>>>>                     On Fri, Sep 18, 2020 at 9:13 AM Flemming
>>>>>>                     Andreasen
>>>>>>                     <fandreas=[email-masked]
>>>>>>                     <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>>                         It looks like we have at least 5 people
>>>>>>                         interested in and willing to contribute
>>>>>>                         to the work. Based on this, the chairs
>>>>>>                         will work with our AD on getting a new
>>>>>>                         milestone added.
>>>>>>
>>>>>>                         I see that the current draft has expired
>>>>>>                         though - can we get an updated version
>>>>>>                         submitted first ?
>>>>>>
>>>>>>                         Thanks
>>>>>>
>>>>>>>                         On Wed, Sep 2, 2020 at 11:51 AM Youenn
>>>>>>>                         Fablet
>>>>>>>                         <youenn=[email-masked]
>>>>>>>                         <mailto:[email-masked]>> wrote:
>>>>>>>
>>>>>>>>                             On 2 Sep 2020, at 20:09, Flemming
>>>>>>>>                             Andreasen <[email-masked]
>>>>>>>>                             <mailto:[email-masked]>> wrote:
>>>>>>>>
>>>>>>>>>                             I am strongly in favor of
>>>>>>>>>                             adopting this draft to MMUSIC and
>>>>>>>>>                             getting it completed.
>>>>>>>>>                             _____________
>>>>>>>>>                             Roman Shpount
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                             On Thu, Jul 30, 2020 at 7:33 PM
>>>>>>>>>                             Justin Uberti
>>>>>>>>>                             <juberti=[email-masked]
>>>>>>>>>                             <mailto:[email-masked]>>
>>>>>>>>>                             wrote:
>>>>>>>>>
>>>>>>>>>                                 Hi all,
>>>>>>>>>
>>>>>>>>>                                 With the closure of rtcweb, we
>>>>>>>>>                                 have been advised to find a
>>>>>>>>>                                 new forum for
>>>>>>>>>                                 https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04
>>>>>>>>>                                 <https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04>,
>>>>>>>>>                                 I believe this document is in
>>>>>>>>>                                 fairly good shape and should
>>>>>>>>>                                 be ready for last call soon.
>>>>>>>>>                                 Any objections to taking it on
>>>>>>>>>                                 in this working group?
>>>>>>>>>
>>>>>>>>>                                 Justin
>>>>>>>>>                                 <mailto:[email-masked]>
>>>>>>>>>                                 <https://www.ietf.org/mailman/listinfo/mmusic>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                             [email-masked]  <mailto:[email-masked]>
>>>>>>>>>                             https://www.ietf.org/mailman/listinfo/mmusic  <https://www.ietf.org/mailman/listinfo/mmusic>
>>>>>>>>
>>>>>>>
>>>>>>>                             [email-masked] <mailto:[email-masked]>
>>>>>>>                             <https://www.ietf.org/mailman/listinfo/mmusic>
>>>>>>>
>>>>>>>
>>>>>>>                         [email-masked]  <mailto:[email-masked]>
>>>>>>>                         https://www.ietf.org/mailman/listinfo/mmusic  <https://www.ietf.org/mailman/listinfo/mmusic>
>>>>>>
>>>>>
>>>>>
>>>>>             [email-masked]  <mailto:[email-masked]>
>>>>>             https://www.ietf.org/mailman/listinfo/mmusic  <https://www.ietf.org/mailman/listinfo/mmusic>
>>>>
>>>
>>>
>>>             [email-masked]  <mailto:[email-masked]>
>>>             https://www.ietf.org/mailman/listinfo/mmusic  <https://www.ietf.org/mailman/listinfo/mmusic>
>>
>>             [email-masked] <mailto:[email-masked]>
>>             <https://www.ietf.org/mailman/listinfo/mmusic>
>>
>
>

---

From: Youenn Fablet <[email-masked]>
Date: Mon, 14 Dec 2020 16:57:10 +0100

The remaining issue so far is how to integrate mDNS ICE candidate within the ICE SIP SDP spec.
Issue is tracked at https://github.com/rtcweb-wg/mdns-ice-candidates/issues/98 <https://github.com/rtcweb-wg/mdns-ice-candidates/issues/98>
Either the mDNS ICE candidate overrides ICE-SIP-SDP or ICE-SIP-SDP is updated and could refer to the mDNS ICE candidate spec.
We lean towards the former and welcome any feedback on the best way to proceed.

Thanks,
	Y

> On 14 Dec 2020, at 16:17, Flemming Andreasen <[email-masked]> wrote:
> 
> Thanks Justin 
> 
> We submitted a milestone update a little while back and are just waiting for the AD go-ahead. In the meantime, it would be good to have any remaining issues discussed on the mailing list as well. 
> 
> Cheers
> 
> -- Flemming 
> 
>> Youenn and Qingsi have resolved several issues over the past week. There are a few remaining issues to discuss, but I think we can have this ready for last call within the month, perhaps earlier.
>> 
>> On Mon, Oct 26, 2020 at 5:20 PM Flemming Andreasen <[email-masked] <mailto:[email-masked]>> wrote:
>> Going back to the original question: What do the authors view as a realistic timeframe for getting the draft ready for publication ? 
>> 
>> Thanks 
>> 
>> -- Flemming 
>> 
>>> This is currently supported in Safari iOS, and we are working to bring this to Chrome Android as well.
>>> 
>>> On Wed, Oct 21, 2020 at 8:47 AM Roman Shpount <[email-masked] <mailto:[email-masked]>> wrote:
>>> I would like to see if there any implementations of this draft on mobile networks. I think this draft's interactions with mobile network deployment scenarios, such as 464XLAT, should be examined in detail before this draft is ready for publication. Also, mDNS is not currently supported on Android, which represents a significant portion of this draft use case, making some of the implementation details a bit fuzzy. My main concern here is if the mDNS name which is associated with one IP address always resolves to the same IP address with the same address family when resolved on the same network.
>>> 
>>> Best Regards,
>>> _____________
>>> Roman Shpount
>>> 
>>> 
>>> On Wed, Oct 21, 2020 at 11:04 AM Flemming Andreasen <fandreas=[email-masked] <mailto:[email-masked]>> wrote:
>>> By publication we mean that the draft is considered to be in the final ready state with no known issues, whether technical or editorial. At that point, the Working Group chairs will do (another) thorough review of the document, and if it looks ready then ask for publication of the document, which means it will be sent to the responsible Area Director for review, and subsequently to the IESG for further review and eventually it's published as an RFC. 
>>> 
>>> Thanks 
>>> 
>>> -- Flemming 
>>> 
>>>> To produce the final version that we expect to go to validation, we should probably finish resolving the 8 remaining issues and update the spec according the resolutions of these 8 issues.
>>>> 
>>>>> On 21 Oct 2020, at 16:33, Flemming Andreasen <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> It all depends on how mature the draft is, especially in terms of its technical content. Also, we will need a few reviewers to look closely at the draft to see if there are any issues the authors may not have thought of. 
>>>>> 
>>>>> Cheers
>>>>> 
>>>>> -- Flemming 
>>>>> 
>>>>> 
>>>>> 
>>>>>> I'm sorry for not being familiar with the process. In addition to editorial revisions and addressing comments, are there other prerequisites for publication?
>>>>>> 
>>>>>> Thanks,
>>>>>> Qingsi
>>>>>> 
>>>>>> On Tue, Oct 20, 2020 at 7:47 PM Flemming Andreasen <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> Thanks Justin. What do the authors view as a realistic timeframe for getting the draft ready for publication ? 
>>>>>> 
>>>>>> Cheers
>>>>>> 
>>>>>> -- Flemming 
>>>>>> 
>>>>>>> On Thu, Oct 15, 2020 at 12:40 PM Justin Uberti <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>> On Fri, Sep 18, 2020 at 9:13 AM Flemming Andreasen <fandreas=[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>> It looks like we have at least 5 people interested in and willing to contribute to the work. Based on this, the chairs will work with our AD on getting a new milestone added. 
>>>>>>> 
>>>>>>> I see that the current draft has expired though - can we get an updated version submitted first ? 
>>>>>>> 
>>>>>>> Thanks 
>>>>>>> 
>>>>>>>> On Wed, Sep 2, 2020 at 11:51 AM Youenn Fablet <youenn=[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>> The proposal being implemented by various parties, having this document be reviewed and ironed out as much as possible is valuable.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 	Y
>>>>>>>> 
>>>>>>>>> On 2 Sep 2020, at 20:09, Flemming Andreasen <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>> 
>>>>>>>>> So far I've only seen 2 people expressing an interest in this document. 
>>>>>>>>> 
>>>>>>>>> Is anybody else interested, and if so, are you willing to contribute and/or review the document ? 
>>>>>>>>> 
>>>>>>>>> Thanks 
>>>>>>>>> 
>>>>>>>>>> I am strongly in favor of adopting this draft to MMUSIC and getting it completed.
>>>>>>>>>> _____________
>>>>>>>>>> Roman Shpount
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Thu, Jul 30, 2020 at 7:33 PM Justin Uberti <juberti=[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>> 
>>>>>>>>>> With the closure of rtcweb, we have been advised to find a new forum for https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04 <https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04>, and MMUSIC seems like the best home for it.
>>>>>>>>>> 
>>>>>>>>>> I believe this document is in fairly good shape and should be ready for last call soon. Any objections to taking it on in this working group?
>>>>>>>>>> 
>>>>>>>>>> Justin

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 14 Dec 2020 19:11:46 +0000

Hi,

I don't think you can override ICE-SIP-SDP. You can update ICE-SIP-SDP in the mdns draft, though.

Regards,

Christer

From: mmusic <[email-masked]> On Behalf Of Youenn Fablet
Sent: maanantai 14. joulukuuta 2020 17.57
To: Flemming Andreasen <[email-masked]>
Cc: Justin Uberti <juberti=[email-masked]>; mmusic WG <[email-masked]>
Subject: Re: [MMUSIC] draft-ietf-rtcweb-mdns-ice-candidates

The remaining issue so far is how to integrate mDNS ICE candidate within the ICE SIP SDP spec.
Issue is tracked at https://github.com/rtcweb-wg/mdns-ice-candidates/issues/98<https://protect2.fireeye.com/v1/url?k=d3f714f2-8c6c2c10-d3f75469-86073b36ea28-1104717675e6365a&q=1&e=f1f29775-cad2-4330-81ed-4c95d3733118&u=https%3A%2F%2Fgithub.com%2Frtcweb-wg%2Fmdns-ice-candidates%2Fissues%2F98>
Either the mDNS ICE candidate overrides ICE-SIP-SDP or ICE-SIP-SDP is updated and could refer to the mDNS ICE candidate spec.
We lean towards the former and welcome any feedback on the best way to proceed.

Thanks,
                             Y

On 14 Dec 2020, at 16:17, Flemming Andreasen <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Justin

Cheers

-- Flemming

On Mon, Oct 26, 2020 at 5:20 PM Flemming Andreasen <[email-masked]<mailto:[email-masked]>> wrote:
Going back to the original question: What do the authors view as a realistic timeframe for getting the draft ready for publication ?

Thanks

-- Flemming

On Wed, Oct 21, 2020 at 8:47 AM Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
I would like to see if there any implementations of this draft on mobile networks. I think this draft's interactions with mobile network deployment scenarios, such as 464XLAT, should be examined in detail before this draft is ready for publication. Also, mDNS is not currently supported on Android, which represents a significant portion of this draft use case, making some of the implementation details a bit fuzzy. My main concern here is if the mDNS name which is associated with one IP address always resolves to the same IP address with the same address family when resolved on the same network.

Best Regards,
_____________
Roman Shpount

On Wed, Oct 21, 2020 at 11:04 AM Flemming Andreasen <fandreas=[email-masked]<mailto:[email-masked]>> wrote:
By publication we mean that the draft is considered to be in the final ready state with no known issues, whether technical or editorial. At that point, the Working Group chairs will do (another) thorough review of the document, and if it looks ready then ask for publication of the document, which means it will be sent to the responsible Area Director for review, and subsequently to the IESG for further review and eventually it's published as an RFC.

Thanks

-- Flemming

On 21 Oct 2020, at 16:33, Flemming Andreasen <[email-masked]<mailto:[email-masked]>> wrote:

Cheers

-- Flemming

Thanks,
Qingsi

On Tue, Oct 20, 2020 at 7:47 PM Flemming Andreasen <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Justin. What do the authors view as a realistic timeframe for getting the draft ready for publication ?

Cheers

-- Flemming

On Thu, Oct 15, 2020 at 12:40 PM Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
This fell off my radar, will update the draft shortly though.

On Fri, Sep 18, 2020 at 9:13 AM Flemming Andreasen <fandreas=[email-masked]<mailto:[email-masked]>> wrote:
It looks like we have at least 5 people interested in and willing to contribute to the work. Based on this, the chairs will work with our AD on getting a new milestone added.

Thanks

Best,
Qingsi

On Wed, Sep 2, 2020 at 11:51 AM Youenn Fablet <youenn=[email-masked]<mailto:[email-masked]>> wrote:
I am interested and willing to contribute to the document.
The proposal being implemented by various parties, having this document be reviewed and ironed out as much as possible is valuable.

Thanks,
Y

On 2 Sep 2020, at 20:09, Flemming Andreasen <[email-masked]<mailto:[email-masked]>> wrote:

Thanks

On Thu, Jul 30, 2020 at 7:33 PM Justin Uberti <juberti=[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

With the closure of rtcweb, we have been advised to find a new forum for https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04, and MMUSIC seems like the best home for it.

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

mmusic mailing list

[email-masked]<mailto:[email-masked]>

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

mmusic mailing list

[email-masked]<mailto:[email-masked]>

mmusic mailing list

[email-masked]<mailto:[email-masked]>

mmusic mailing list

[email-masked]<mailto:[email-masked]>

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

mmusic mailing list

[email-masked]<mailto:[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 14 Dec 2020 14:57:34 -0500

Hi,

We have added the following language in ICE-SIP-SDP specifically related to
this issue:

An agent generating local candidates MUST NOT use FQDN addresses.  An agent
processing remote candidates MUST ignore candidate lines that include
candidates with FQDN or IP address versions that are not supported or
recognized.  The procedures for generation and handling of FQDN candidates,
as well as how agents indicate support for such procedures, need to be
specified in an extension specification.

So, the simplest thing would be to treat mdns-ice as an extension
specification.

Another option is to write an extension specification for a generic
FQND candidate handling.
_____________
Roman Shpount

On Mon, Dec 14, 2020 at 2:12 PM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

> Hi,
>
>
>
> I don’t think you can override ICE-SIP-SDP. You can update ICE-SIP-SDP in
> the mdns draft, though.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* mmusic <[email-masked]> *On Behalf Of *Youenn Fablet
> *Sent:* maanantai 14. joulukuuta 2020 17.57
> *To:* Flemming Andreasen <[email-masked]>
> *Cc:* Justin Uberti <juberti=[email-masked]>; mmusic WG <
> [email-masked]>
> *Subject:* Re: [MMUSIC] draft-ietf-rtcweb-mdns-ice-candidates
>
>
>
> Issue is tracked at
> https://github.com/rtcweb-wg/mdns-ice-candidates/issues/98
> <https://protect2.fireeye.com/v1/url?k=d3f714f2-8c6c2c10-d3f75469-86073b36ea28-1104717675e6365a&q=1&e=f1f29775-cad2-4330-81ed-4c95d3733118&u=https%3A%2F%2Fgithub.com%2Frtcweb-wg%2Fmdns-ice-candidates%2Fissues%2F98>
>
> Either the mDNS ICE candidate overrides ICE-SIP-SDP or ICE-SIP-SDP is
> updated and could refer to the mDNS ICE candidate spec.
>
> To produce the final version that we expect to go to validation, we should
> probably finish resolving the 8 remaining issues and update the spec
> On Thu, Oct 15, 2020 at 12:40 PM Justin Uberti <[email-masked]> wrote:
>
> The proposal being implemented by various parties, having this document be
> reviewed and ironed out as much as possible is valuable.
>
>
>
> Thanks,
>
> Y
>
>
>
> On 2 Sep 2020, at 20:09, Flemming Andreasen <[email-masked]> wrote:
>
>
>
> With the closure of rtcweb, we have been advised to find a new forum for
> https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04, and
> MMUSIC seems like the best home for it.
>
>
>
> I believe this document is in fairly good shape and should be ready for
> last call soon. Any objections to taking it on in this working group?
>
>
>
> Justin
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 14 Dec 2020 15:06:01 -0500

I have a general question about MDNS that will affect the
mdns-ice-candidate draft:

Is it possible for an IPv4 MDNS name allocated by one end-point to be
resolved as IPv6 address by another end-point, or visa-versa (IPv6 MDNS
name be resolved as IPv4)?

I specifically would like to know if something like 464XLAT can cause MDNS
resolution results to be converted to a different IP address type.

If this can happen, then the MDNS candidate can generate more than one
local candidate or a candidate of a different address type, affecting
candidate priority. I think the stability of the FQDN candidate resolution,
including the MDNS candidate resolution, can improve if the expected
address type is specified for each candidate as a candidate extension.
_____________
Roman Shpount

---

From: Qingsi Wang <[email-masked]>
Date: Mon, 14 Dec 2020 12:39:59 -0800

I don't think so given the requirement in the draft and also available
implementation options of mDNS responder in an ICE agent. The draft
requires an ICE agent to expose different mDNS names for each address if it
uses an interface with both IPv4 and IPv6 addresses. As a result, even if
there is caching in the subnet by other endpoints and another endpoint
tries to reply to a query for the name, the resolution should be
consistent. As an implementation strategy, the ICE agent can 1) set the
cache-flush bit in their response (and/or announcement) per RFC 6762 to
indicate this is not a shared record type and purge inconsistency in the
subnet, and 2) attach a NSEC record in the additional section of the
response to indicate the sole existence of either A or quar-A record of a
name. This is admittedly all based on the assumption that there is no rogue
endpoint that tries to mess the local messages, which is a different story
outside the scope of this draft.

> I specifically would like to know if something like 464XLAT can cause
MDNS resolution results to be converted to a different IP address type.

I don't recall behaviors like this in 464XLAT or NAT (not expecting them to
change the packet payload).

---

From: Roman Shpount <[email-masked]>
Date: Tue, 15 Dec 2020 00:25:06 -0500

Based on this, do you assume that the ICE agent will directly resolve MDNS
candidates without using any third-party libraries or going through DNS
proxies?

My concern is that DNS proxy running in the CLAT in the mobile device can
translate IPv4 address to IPv6 address. I was looking for an implementation
where CLAT is located on the device is running in combination with MDNS but
could not find anything. I think DNS translation is done in the client
library on Android when 464XLAT is used, but I might be wrong since I don't
directly deal with this.
_____________
Roman Shpount

On Mon, Dec 14, 2020 at 3:40 PM Qingsi Wang <[email-masked]> wrote:

> I don't recall behaviors like this in 464XLAT or NAT (not expecting them
> to change the packet payload).
>

---

From: Youenn Fablet <[email-masked]>
Date: Tue, 15 Dec 2020 11:50:00 +0100

A few thoughts from looking at the solution you are proposing.

In general, the fact that the candidate priority is affected might not prevent the connection to happen.
I am not sure a change of the candidate priority warrants adding the expected address type.

If an ICE agent gets multiple IP addresses from resolving a FQDN candidate, the ICE agent might either drop the candidate or select an IP address from an unexpected address type.
This might affect connection establishment.
As Qingsi said, the draft contains mitigations so that this situation should not happen for mDNS candidates.
This could potentially happen for non mDNS FQDN candidates but is outside the scope of the mDNS draft.

> On 15 Dec 2020, at 06:25, Roman Shpount <[email-masked]> wrote:
> 
> Based on this, do you assume that the ICE agent will directly resolve MDNS candidates without using any third-party libraries or going through DNS proxies?
> 
> My concern is that DNS proxy running in the CLAT in the mobile device can translate IPv4 address to IPv6 address. I was looking for an implementation where CLAT is located on the device is running in combination with MDNS but could not find anything. I think DNS translation is done in the client library on Android when 464XLAT is used, but I might be wrong since I don't directly deal with this.
> _____________
> Roman Shpount
> 
> 
> On Mon, Dec 14, 2020 at 3:40 PM Qingsi Wang <[email-masked] <mailto:[email-masked]>> wrote:
> > Is it possible for an IPv4 MDNS name allocated by one end-point to be resolved as IPv6 address by another end-point, or visa-versa (IPv6 MDNS name be resolved as IPv4)?
> 
> I don't think so given the requirement in the draft and also available implementation options of mDNS responder in an ICE agent. The draft requires an ICE agent to expose different mDNS names for each address if it uses an interface with both IPv4 and IPv6 addresses. As a result, even if there is caching in the subnet by other endpoints and another endpoint tries to reply to a query for the name, the resolution should be consistent. As an implementation strategy, the ICE agent can 1) set the cache-flush bit in their response (and/or announcement) per RFC 6762 to indicate this is not a shared record type and purge inconsistency in the subnet, and 2) attach a NSEC record in the additional section of the response to indicate the sole existence of either A or quar-A record of a name. This is admittedly all based on the assumption that there is no rogue endpoint that tries to mess the local messages, which is a different story outside the scope of this draft.
> 
> > I specifically would like to know if something like 464XLAT can cause MDNS resolution results to be converted to a different IP address type.
> 
> I don't recall behaviors like this in 464XLAT or NAT (not expecting them to change the packet payload).
> 
> On Mon, Dec 14, 2020 at 12:06 PM Roman Shpount <[email-masked] <mailto:[email-masked]>> wrote:
> I have a general question about MDNS that will affect the mdns-ice-candidate draft:
> 
> Is it possible for an IPv4 MDNS name allocated by one end-point to be resolved as IPv6 address by another end-point, or visa-versa (IPv6 MDNS name be resolved as IPv4)?
> 
> I specifically would like to know if something like 464XLAT can cause MDNS resolution results to be converted to a different IP address type.
> 
> If this can happen, then the MDNS candidate can generate more than one local candidate or a candidate of a different address type, affecting candidate priority. I think the stability of the FQDN candidate resolution, including the MDNS candidate resolution, can improve if the expected address type is specified for each candidate as a candidate extension.
> _____________
> Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 15 Dec 2020 12:42:53 -0500

I understand what you are saying, but my point is, this draft would need to
specify procedures for MDNS allocation (it already does so) and resolution,
which ensures that each MDNS FQDN is resolved to only one address. I am
trying to figure out if local DNS proxy in CLAT would affect MDNS
resolution, especially if implemented as a part of the DNS resolution
library, and I cannot definitively see that.
_____________
Roman Shpount

On Tue, Dec 15, 2020 at 5:50 AM Youenn Fablet <[email-masked]> wrote:

> If an ICE agent gets multiple IP addresses from resolving a FQDN
> candidate, the ICE agent might either drop the candidate or select an IP
> address from an unexpected address type.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 15 Dec 2020 10:03:20 -0800

Treating mdns-ice-candidates as an extension spec seems like the cleanest
path to me. We can simply adjust the draft metadata to say that it updates
sip-sdp, and then I suppose we'll need a section that directly indicates
how sip-sdp is being extended.

On Mon, Dec 14, 2020 at 11:57 AM Roman Shpount <[email-masked]> wrote:

> Hi,
>
> We have added the following language in ICE-SIP-SDP specifically related
> to this issue:
>
> An agent generating local candidates MUST NOT use FQDN addresses.  An
> agent processing remote candidates MUST ignore candidate lines that include
>> The proposal being implemented by various parties, having this document
>> be reviewed and ironed out as much as possible is valuable.
>>
>>
>>
>> Thanks,
>>
>> Y
>>
>>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 Dec 2020 19:17:55 +0000

Hi,

>Treating mdns-ice-candidates as an extension spec seems like the cleanest path to me. We can simply adjust the draft metadata to say that it updates sip-sdp, and
>then I suppose we'll need a section that directly indicates how sip-sdp is being extended.

I guess we at least need a statement saying that sip-sdp is updated by allowing FQDNs that resolve to a single IP address.

We need to double check whether some procedures also need to be updated.

Regards,

Christer

On Mon, Dec 14, 2020 at 11:57 AM Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

We have added the following language in ICE-SIP-SDP specifically related to this issue:

An agent generating local candidates MUST NOT use FQDN addresses.  An agent processing remote candidates MUST ignore candidate lines that include candidates with FQDN or IP address versions that are not supported or recognized.  The procedures for generation and handling of FQDN candidates, as well as how agents indicate support for such procedures, need to be specified in an extension specification.

So, the simplest thing would be to treat mdns-ice as an extension specification.

Another option is to write an extension specification for a generic FQND candidate handling.
_____________
Roman Shpount

On Mon, Dec 14, 2020 at 2:12 PM Christer Holmberg <christer.holmberg=[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I don’t think you can override ICE-SIP-SDP. You can update ICE-SIP-SDP in the mdns draft, though.

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> On Behalf Of Youenn Fablet
Sent: maanantai 14. joulukuuta 2020 17.57
To: Flemming Andreasen <[email-masked]<mailto:[email-masked]>>
Cc: Justin Uberti <juberti=[email-masked]<mailto:[email-masked]>>; mmusic WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] draft-ietf-rtcweb-mdns-ice-candidates

Thanks,
                             Y

Thanks Justin

Cheers

-- Flemming

Thanks

-- Flemming

Best Regards,
_____________
Roman Shpount

Thanks

-- Flemming

Cheers

-- Flemming

Thanks,
Qingsi

Cheers

-- Flemming

Thanks

Best,
Qingsi

Thanks,
Y

Thanks

Justin

mmusic mailing list

mmusic mailing list

mmusic mailing list

mmusic mailing list

mmusic mailing list

---

From: Roman Shpount <[email-masked]>
Date: Tue, 15 Dec 2020 19:12:40 -0500

I do not think we can allow all FQDNs that resolve to a single IP
address since,
in general, this is impossible to enforce.

I would suggest that we be as specific as possible and only allow FQDN
candidates in the form of UID.local, allocated by an ice-agent to resolve
to a single address and directly resolved by the ice-agent. The
mdns-ice-candidates draft will define procedures for allocation and
resolution of such candidates and nothing else. All other FQDN should
continue to be ignored unless further resolution procedures are defined in
other drafts.

If we want to define how other FQDN candidates are resolved, I would
suggest putting it into another draft.
_____________
Roman Shpount

On Tue, Dec 15, 2020 at 2:18 PM Christer Holmberg <
[email-masked]> wrote:

> sip-sdp, and
> I guess we at least need a statement saying that sip-sdp is updated by
> allowing FQDNs that resolve to a single IP address.
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Dec 2020 08:13:28 +0000

Hi,

>I do not think we can allow all FQDNs that resolve to a single IP address since, in general, this is impossible to enforce.
>
>I would suggest that we be as specific as possible and only allow FQDN candidates in the form of UID.local, allocated by an ice-agent to resolve to a single address and directly
>resolved by the ice-agent. The mdns-ice-candidates draft will define procedures for allocation and resolution of such candidates and nothing else. All other FQDN should continue
>to be ignored unless further resolution procedures are defined in other drafts.

Correct.  My point was that we should not generally allow FQDNs, and then say that problems that come with it are solved elsewhere.

Regards,

Christer

On Tue, Dec 15, 2020 at 2:18 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Regards,

Christer

Thanks,
                             Y

Thanks Justin

Cheers

-- Flemming

Thanks

-- Flemming

Best Regards,
_____________
Roman Shpount

Thanks

-- Flemming

Cheers

-- Flemming

Thanks,
Qingsi

Cheers

-- Flemming

Thanks

Best,
Qingsi

Thanks,
Y

Thanks

Justin

mmusic mailing list

mmusic mailing list

mmusic mailing list

mmusic mailing list

mmusic mailing list