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

Roman Shpount <> Sat, 06 July 2019 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0891120077 for <>; Sat, 6 Jul 2019 13:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HgtFJO1Hy_GG for <>; Sat, 6 Jul 2019 13:16:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68D4412008B for <>; Sat, 6 Jul 2019 13:16:07 -0700 (PDT)
Received: by with SMTP id c14so6167028plo.0 for <>; Sat, 06 Jul 2019 13:16:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5KVZl+5phb9rkeChY5+DLk6aeFkeoRjrqQgYSCprBFM=; b=svTjYbni2V7cAritVR9JxFUUAydJ7TGUG4T/x9/mgIpHFkXrfkrNNYLWlgLXgh903D WE2acaqJX2YojGS0kFi98AzDix7/L4vMsr/nAR35gTDIidMcEZlKNz7aSHgAn46gWqdd KthbcSJMZHB6+BXLABFbx7eEl5PQu7cnfDzbUxR53nsQ7EsLYg9cH2R/U8abiGAflxUt TWtIU78SGXnMxF+vcA1antx89uS8pbW02Mm5eTwE043T7CjBid7eWH+kgGXWeHKHyFb4 sKqAo7E1CwvyOHmCEDIl2OvIvCFYCkGYqNGxE1ZByY36fTgF4BJschu0BEqxSwqIvzpa L2EA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5KVZl+5phb9rkeChY5+DLk6aeFkeoRjrqQgYSCprBFM=; b=TVdCd1fTyNz839euJIRpXp4BzwvKvbXu/EyN6kre6NSmCD1A+GOwkjVAiJV7cCfKZc 1VDCfHIRUpMW/cKNk7gLOXPF+3xFLc/jMwF1YVCJhBxNNLdT2+/BWL7gAr9w2I9hQ0/T 4T7np7N+LlB6k+n6wsun35trRKZgK2y5n3smhP/lbLn4XrXjM/rARmyKvZc5PcYtiufx YoWEegTx5/kYV44xB51ItIg0u9H5C1sScjkDLng57dy53yW5OAak+8QjZn1ccZF6b+n5 3fyKNZZb/Ap7qNAPQzAGem6s5CSwVVIlaOL7oSaSSJ6Ho6H+fTaLetild3yzC0WQCkSD nweA==
X-Gm-Message-State: APjAAAXKO+Ax4GhLJzBFNqQWqTP4dazXRcGVjsCDSZVwNeus4ONOt8/0 /T7OwuceukaVwDFQZyXJr3scuTk5/vA=
X-Google-Smtp-Source: APXvYqyGuOm4Zo4FHGUEur/SNIYOMQkdGeY+c1fuSrUSpQ0csljTyOMd24xwyFP6qjjsVlKVo7LNaA==
X-Received: by 2002:a17:902:8f87:: with SMTP id z7mr12893609plo.65.1562444166654; Sat, 06 Jul 2019 13:16:06 -0700 (PDT)
Received: from ( []) by with ESMTPSA id q4sm12414018pjq.27.2019. for <> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jul 2019 13:16:05 -0700 (PDT)
Received: by with SMTP id c2so4601537plz.13 for <>; Sat, 06 Jul 2019 13:16:05 -0700 (PDT)
X-Received: by 2002:a17:902:a413:: with SMTP id p19mr7536437plq.134.1562444164958; Sat, 06 Jul 2019 13:16:04 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Roman Shpount <>
Date: Sat, 6 Jul 2019 16:15:53 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Harald Alvestrand <>
Cc: RTCWeb IETF <>
Content-Type: multipart/alternative; boundary="0000000000006f0f5e058d08e1cb"
Archived-At: <>
Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 06 Jul 2019 20:16:10 -0000

On Thu, Jul 4, 2019 at 5:24 PM Harald Alvestrand <>

> Den 04.07.2019 20:46, skrev Roman Shpount:
> > I understand that running experiments before proposing a solution is
> > probably a good thing and this is what Chrome was doing up until this
> > point. At the same time, rolling this feature into production before at
> > least documenting it, will definitely cause interop problems. What we
> > have now is a fairly major feature with a fairly outdated specification
> > where all the interop issues weren't considered.
> >
> To be precise, we have documentation for the feature
> (draft-ietf-rtcweb-mdns-ice-candidates), it's been largely unchanged for
> quite some time, and it's what Chrome is in the process of shipping.

Are you saying that draft-ietf-rtcweb-mdns-ice-candidates provides an
accurate description of what is being shipped in Chrome? As far as I know
this document is outdated. It also has implementation issues  like stating "An
ICE agent SHOULD ignore candidates where the hostname resolution returns
more than one IP address". There are platforms which return both IPv6 and
IPv4 for a DNS record which points to a single IPv4 address. There are two
fundamental problems with FQDN in ICE candidates. First being legacy
interop. Second being that handling FQDN is under-specified and  FQDN in
ICE candidate line is likely missing necessary information required to
resolve it (address family). Dealing with the default candidate which is a
FQDN is another are which has no existing specification leading to FQDN
with unknown address family in the c= line.

It addresses a quite substantive issue (as in "millions of occurences
> per day" of the behavior we want to prevent).

I understand the desire to block one of the client fingerprinting methods.
After all, there are few hundred others that will need to blocked after.

The fact that we're only getting the interoperability issues discovered
> as we roll out the feature to stable is sad; I don't know how to get
> other people's software tested earlier in the cycle, which is what would
> have given us more time to work through these issues.

The software was tested and issues were identified and fixed. Unfortunately
not everyone has a luxury of simply pushing the software update to all
customer. When dealing with telecom, it is common for them to deploy new
software every 3-6 months and only after running a limited deployment for a
few months before hand. It literally takes a year to push a new version to
them, which is not usually a problem, unless some breaking protocol change
is introduced, like unified plan or mdns.

Given mmusic's traditional processing speed, I am not sure there's any
> point in formally moving the document at this point.

It is especially slow when none of the people interested in the specific
feature (FQDN in ICE candidates) participate in the discussion. So far this
looks like this feature is going to be shipped regardless of what anybody
thinks about it and without even attempting to discuss it in the group
which is responsible for this functionality.

Best Regards,
Roman Shpount