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

Bernard Aboba <bernard.aboba@gmail.com> Mon, 20 May 2019 22:07 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC5E120058 for <mmusic@ietfa.amsl.com>; Mon, 20 May 2019 15:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmB2YnL5LIXY for <mmusic@ietfa.amsl.com>; Mon, 20 May 2019 15:07:47 -0700 (PDT)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1ED412004B for <mmusic@ietf.org>; Mon, 20 May 2019 15:07:46 -0700 (PDT)
Received: by mail-vs1-xe31.google.com with SMTP id l20so9944557vsp.3 for <mmusic@ietf.org>; Mon, 20 May 2019 15:07:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r1V//2huAe0wKnC3o2V6hkrRQqu2wQxDqSliUvl9qG0=; b=s25Q6kF3DMrTnhXRDWiFPPntau8fkcmmJAru9vXnoo8J9grmOy926ny/xKKlpoSOFZ X0WZ7oy9JMw9hPoUMM+hMWHZW6mDbtK58NRkYkyGGLVMFB0pGcyM9PdLiKkc5pa1OUCw YD/ifOTtinFmse5ij3Lyb+bg0f9MgP+L8HyM1+MJ8otuJANURxS1ifdyAsqiJL/NeNSj vVUif4pBJoI+d1cOScl2JMtGWZ5wTgNCZV4smAvNiv3t80mgVAyycM7jOzIGu03RChC7 G5IDlI+pQAddtv9wbvis7za03SPU/ihKIoGqU+LPKUe66Ej+SVDm/HRuumpKfkMQu9Qr R2Ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r1V//2huAe0wKnC3o2V6hkrRQqu2wQxDqSliUvl9qG0=; b=NIOgVBIoioO1lvvSIFuECy+rLJAnmEAmMIS1N9Tdx1wcoEQ04it69Mpihc36FjIP9L WeSMSj4GJ8sxOO/CIrw0x56nBimBkrJjsArWk593XCnUxzFWbdkULfkK8dDgszon+H7r 7R+885qCFSDuaitVLrZCdF5KfeHgWAwrn205jtMVtATzSurwy6p/fil+8VP6dlHUME60 Q3LNy9Y/gRKmS1f9Ey9ULh6WzlVB9L15CwU15XDpNKyts7OSR88iRrK60meAequjKD+b 2hAOS5asnv/S+26wQPJV+4WWuiBmSJ44RWwmIP9laxtZxHj0fkvPXj/U4Uz3r+NabcVm 46Kg==
X-Gm-Message-State: APjAAAUbppQfviZ++WSwGTxK7r5cDBTeWKM2W11keMmnosay7ESmqnuA N3LOoPetZwr2LJ3QVrTZoJIlYQOrCAUGi9+2bwk=
X-Google-Smtp-Source: APXvYqzCpx8DQFfkOrxuOuQr0cdKO+gTZT7WGAQznwmRLd9riuHThfn8o6z8vaLKNDwCsvnF1G1WLxR0GN7OSV1kZu8=
X-Received: by 2002:a67:d68e:: with SMTP id o14mr5023018vsj.140.1558390065463; Mon, 20 May 2019 15:07:45 -0700 (PDT)
MIME-Version: 1.0
References: <77400318-1e2c-7d33-ab41-a3b8d0062b00@cisco.com> <CAMRcRGQ0gQ0c-pmBQ2ZOOX-5uGWkfy57Yu0QMuAp9ED2f8drwA@mail.gmail.com> <D7E2876E-E750-40C6-B33E-FC24F9CD0709@ericsson.com>
In-Reply-To: <D7E2876E-E750-40C6-B33E-FC24F9CD0709@ericsson.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 20 May 2019 15:07:33 -0700
Message-ID: <CAOW+2dsy5_cjH2BJJq7mRu9JaQNmh7oqWxUrFDPqBKaceffJaQ@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Suhas Nandakumar <suhasietf@gmail.com>, Flemming Andreasen <fandreas@cisco.com>, mmusic <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000460c5c058958f603"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/v9ybc-WzcpYZwKRL4NigOtEEbyo>
Subject: Re: [MMUSIC] (Rough) Consensus Call - No FQDN support in ice-sip-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 May 2019 22:07:50 -0000

I am also interested in the issue, but support the consensus call made by
the Chairs (e.g. removal of FQDN support from ice-sip-sdp).

The basic problem we have is that legacy implementations do not support
FQDNs, and RFC 8445 maintained that posture for backwards compatibility
reasons. As a result, we need to pursue FQDN support as a negotiated
extension, not try to wedge it into ice-sip-sdp.

On Mon, May 13, 2019 at 2: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
>