Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates?

Bernard Aboba <bernard.aboba@gmail.com> Thu, 04 July 2019 01:37 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3F81200E7 for <rtcweb@ietfa.amsl.com>; Wed, 3 Jul 2019 18:37:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 q6Bj-zSLkeMG for <rtcweb@ietfa.amsl.com>; Wed, 3 Jul 2019 18:36:58 -0700 (PDT)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 838401200D7 for <rtcweb@ietf.org>; Wed, 3 Jul 2019 18:36:58 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id 9so2180481ple.5 for <rtcweb@ietf.org>; Wed, 03 Jul 2019 18:36:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+YuY0DdHILnLO0Pqy/iKJAbXQd25cbPGbyhQ7DdaDBA=; b=UPyytai1qjWuGz0vxKDa/smV4PEszjkNMVTR0RNDLdMe3/UndXY0eV+aEeY44smatB I4QEsOGaYNQBqe54LbQ3CUz6+wvIJNm8zuouopMNxur6BwETV68zepBvWH6Dl9MuMbLc 2STvPQxx3jmls8h1PsnoZxQRrb9iE8NvMNJya6kWzrx5KW8TXdocxL1L+MLelcJuI6nA LMjkGBLGXdY0ONQx72corCH6h174Kosp5DxZwpgGPekAMfwoVPOA8UqLmkEr6u0GeG/S /SDaZUlJBG0mxVmRzhanAXMXZKfqD8P78faTXTjIPif8CXZz0kHWgDd+NXMQNUQ7FMbW YrDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+YuY0DdHILnLO0Pqy/iKJAbXQd25cbPGbyhQ7DdaDBA=; b=Hu36b5ZzGFv3GcwWCQM8E9uD4ZVViczoH99Z8762qFIjTteBPxpNdhkiQ8yirq0HX3 Dha3OKZJ8ppOVvlcE4ZqdqHHZCMAJYZLGAEoymS0EvWiqHyLrlUhyAeHoMOMvFeNHIwE 9tPyC+M1mbrtWR0x3QpeSTuKxQ+tOFYPowqoZc/8m22W+QIldBYHK4evpMkHnOfMJ9Ar Z99y3n4VIAPmGy/OgZk9QKtVEJA/BLY8zp/xtoyoAWU+Yi+9bBnyqMRhZNkwh4pqV6hE JySXrNIrlUCG1ETYF/zDlV6UnLfZaYvEGBjJyVhhRpyiEdNMv98+4GMyRbzgW03rB9/T +Agg==
X-Gm-Message-State: APjAAAXk1FcHu1UXANur2MPX4hDZ1lUPrw1C/L9kudcoTSjCsFmvbcNR XlPXyuomKj9I0AmoZyM7AM3R6Iuw
X-Google-Smtp-Source: APXvYqwcnIj4OiR5ymK3UTthsjVC8y0FLYNuKL96M2noioC/54lUq7MDjPv7JnWht5b7rWqWLcfZIg==
X-Received: by 2002:a17:902:4283:: with SMTP id h3mr12074956pld.15.1562204214684; Wed, 03 Jul 2019 18:36:54 -0700 (PDT)
Received: from ?IPv6:2600:380:7066:c0e9:4866:1543:5359:9d3b? ([2600:380:7066:c0e9:4866:1543:5359:9d3b]) by smtp.gmail.com with ESMTPSA id 85sm3546183pfv.130.2019.07.03.18.36.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 18:36:53 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-726E8203-F349-48FD-A065-7FA39BEC75E6
Mime-Version: 1.0 (1.0)
From: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: iPhone Mail (16F250)
In-Reply-To: <CAOJ7v-1pKuvNfuPVqJQKj1d0U8Z7JH9aqNU0DkNDMYvec7jyUQ@mail.gmail.com>
Date: Wed, 3 Jul 2019 18:36:51 -0700
Cc: Roman Shpount <roman@telurix.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <8FB2B040-852C-44E5-82F8-6A7391EB2F53@gmail.com>
References: <b03853a4-1006-4da0-d52f-9e7462a2cd0c@alvestrand.no> <D80CECAF-B520-40A2-BFBB-E39B73BA943D@sn3rd.com> <CAD5OKxsd-SE8VpwFgto3DLbabs+9O+cHMucy1+Cep7tCJQR6+w@mail.gmail.com> <CAOJ7v-2XrND6YWqo2tEiDbs7TZpEoiP+MGBAk2aF7hfoMiGk0Q@mail.gmail.com> <CAD5OKxtSzOfnN8WrV-duwwfmwa+VJX_3HACiXU43Xeym25GQaQ@mail.gmail.com> <CAOJ7v-1pKuvNfuPVqJQKj1d0U8Z7JH9aqNU0DkNDMYvec7jyUQ@mail.gmail.com>
To: Justin Uberti <juberti=40google.com@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/eZa61a6zwwUx315LnJkYdfFimYM>
Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2019 01:37:02 -0000

I don’t see them as contradictory. ice-sip-sdp requires implementations not suporting rtcweb-mdns-ice to ignore the .local candidates. This combined with ice-pac should enable interop of with implementations of rtcweb-mdns-ice via server reflexive candidates.

The one remaining piece is legacy handling of c= lines with mDNS names. 



> On Jul 3, 2019, at 5:58 PM, Justin Uberti <juberti=40google.com@dmarc.ietf.org> wrote:
> 
> Hmm, that's unfortunate. I think this is a mistake, given that we are about to throw the switch to enable mDNS for 100% of Chrome endpoints; Chrome (and soon all browsers) will have to ignore ice-sip-sdp until this extension spec is written.
> 
> ice-sip-sdp isn't published yet, so it seems an update to that document could still be a possibility. If that's not an option, putting forth #1 as a specific extension that allows FQDN candidates to be generated in certain situations seems like the right path.
> 
> 
> 
>> On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount <roman@telurix.com> wrote:
>> Part of the problem is that mmusic have decided to punt on the FQDN support. In the current mmusic-ice-sip-sdp the final language that was included:
>> 
>> <connection-address>:  is taken from RFC 4566 [RFC4566].  It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs).  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 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, at this point we have two options: 
>> 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and define how FQDN candidates generated by mdns are handled
>> 2. write a new draft in mmusic which defines FQDN handling
>> 
>> In any case some sort of mmusic discussion is needed to reconcile this.
>> 
>> Best Regards,
>> _____________
>> Roman Shpount
>> 
>> 
>>> On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti <juberti@google.com> wrote:
>>> The problem this draft is trying to solve is fairly RTCWEB-specific. If there are individual issues to resolve, we can send them out to mmusic for discussion, but AFAIK no changes to existing ICE specs are needed.
>>> 
>>>> On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount <roman@telurix.com> wrote:
>>>> Hi All,
>>>> 
>>>> Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? This entire draft seems to be ICE/SDP specific and not limited to rtcweb. Also, there are significant interop implications for this draft between browser and non-browser end points which probably warrant larger discussion outside of rtcweb group. I would think mmusic would be a much better place for this draft. I know there is an incentive to complete this draft quickly but this has a potential to break a lot of things (it already did break interop with almost every existing ICE implementation).
>>>> 
>>>> Regards,
>>>> _____________
>>>> Roman Shpount
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb