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

What I mean is that FQDN can be included in the ICE candidate
connection-address, but agent MUST ignore such ICE candidate, unless this
agent implements a future specification that defines how FQDN in ICE
candidate connection address is handled.

Please read the proposed text in the other email thread.
_____________
Roman Shpount

On Mon, May 20, 2019 at 5:34 PM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> What do you mean by ”supported and ignored”? Do you mean “not supported”?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From: *Roman Shpount <roman@telurix.com>
> *Date: *Monday, 20 May 2019 at 22.23
> *To: *Christer Holmberg <christer.holmberg@ericsson.com>
> *Cc: *Suhas Nandakumar <suhasietf@gmail.com>, Flemming Andreasen <
> fandreas@cisco.com>, "mmusic@ietf.org" <mmusic@ietf.org>
> *Subject: *Re: [MMUSIC] (Rough) Consensus Call - No FQDN support in
> ice-sip-sdp
>
>
>
> Since there was little feedback on this discussion I would suggest to
> specify that FQDN is supported and ignored. I have provided the language in
> a separate email.
>
> _____________
> Roman Shpount
>
>
>
>
>
> On Mon, May 13, 2019 at 5:49 AM Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> 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>
> 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
> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>