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

[Christer Holmberg <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> wrote:
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 <[e-mail]<mailto:[e-mail]>> 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=[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Youenn Fablet
Sent: maanantai 14. joulukuuta 2020 17.57
To: Flemming Andreasen <[e-mail]<mailto:[e-mail]>>
Cc: Justin Uberti <juberti=[e-mail]<mailto:[e-mail]>>; mmusic WG <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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=[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> wrote:
This fell off my radar, will update the draft shortly though.

On Fri, Sep 18, 2020 at 9:13 AM Flemming Andreasen <fandreas=[e-mail]<mailto:[e-mail]>> 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=[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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=[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________

mmusic mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/mmusic


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


_______________________________________________

mmusic mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/mmusic




_______________________________________________

mmusic mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/mmusic



_______________________________________________

mmusic mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/mmusic

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



_______________________________________________

mmusic mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/mmusic


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