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

[Roman Shpount <[e-mail]>]

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 <
[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]> 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]> 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]> *On Behalf Of *Youenn Fablet
> *Sent:* maanantai 14. joulukuuta 2020 17.57
> *To:* Flemming Andreasen <[e-mail]>
> *Cc:* Justin Uberti <juberti=[e-mail]>; mmusic WG <
> [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]> 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]>
> 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]> 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]> 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]> 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]>
> 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]> 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]> 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]> 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]> 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]> 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]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
>
> mmusic mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
>
> mmusic mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
>
>
>
> _______________________________________________
>
> mmusic mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
>
> _______________________________________________
>
> mmusic mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
>
> _______________________________________________
>
> mmusic mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>