Re: [MMUSIC] (Rough) Consensus Call - No FQDN support in ice-sip-sdp

Hi,

I would have liked to see the Pull Request before concluding that there is no “agreement”. But, we can obviously not wait forever.

Having said that, related to Suhas’ comment, if we agree to leave FQDN out I think we still need some text.

One option is to put back the text pre-22 text (see below), but I am not sure that solves the issue. Another option is to explicitly say that support and processing of FQDNs are outside the scope of the document, and needs to be covered in a separate specification.

Note, however, that draft-ietf-rtcweb-mdns-ice-candidates assumes that FQDNs are allowed, so in order to progress that draft we either need such separate specification – or draft-ietf-rtcweb-mdns-ice-candidates also needs to cover FQDN support in general.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of Suhas Nandakumar <suhasietf@gmail.com>
Date: Monday, 13 May 2019 at 8.05
To: Flemming Andreasen <fandreas@cisco.com>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] (Rough) Consensus Call - No FQDN support in ice-sip-sdp

I am willing to leave out FQDN specification but want to bring to notice the following

Till ice-sip-sdp-22 we had a recommendation about resolving to one IP Address when multiple match a given FQDN and removed FQDN out from the later versions.

Here is the original text if it helps (pre-22)

<connection-address>:  is taken from RFC 4566 [RFC4566].  It is the

      IP address of the candidate.  When parsing this field, an agent

      can differentiate an IPv4 address and an IPv6 address by presence

      of a colon in its value -- the presence of a colon indicates IPv6.

      An agent MUST ignore candidate lines that include candidates with

      IP address versions that are not supported or recognized.  An IP

      address SHOULD be used, but an FQDN MAY be used in place of an IP

      address.  In that case, when receiving an offer or answer

      containing an FQDN in an a=candidate attribute, the FQDN is looked

      up in the DNS first using an AAAA record (assuming the agent

      supports IPv6), and if no result is found or the agent only

      supports IPv4, using an A record.  The rules from section 6 of

      [RFC6724] is followed by fixing the source address to be one from

      the candidate pair to be matched against destination addresses

      reported by FQDN, in cases where the DNS query returns more than

      one IP address.

Thanks
Suhas

On Sun, May 12, 2019 at 8:40 PM Flemming Andreasen <fandreas@cisco.com<mailto:fandreas@cisco.com>> wrote:
Greetings

RFC 8445 does not include support for domain names. There is currently a fairly lengthy thread on the MMUSIC list discussing if (and potentially how) to deal with domain name support in ice-sip-sdp ("FQDN support in ice-sip-sdp). So far only 3 people seem to be interested in this issue, they do not agree on the solution, and it has been more than 2 weeks since we last saw any traffic on this.

We need to move ice-sip-sdp forward, and since RFC 8445 does not support domain names in candidates, and we have yet to find a consensus-based solution to adding such support, we propose that we move forward without domain name support in ice-sip-sdp (note that it can be added latter as an extension in a separate draft).

We are hereby giving people 1 week to object to this (rough) consensus call, and if they do, to provide another solution that can garner support and consensus on the MMUSIC list.

Thanks

-- Flemmming (with MMUSIC chair on).
_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic