Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13

Martin Thomson <> Wed, 27 May 2015 23:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BAEA51B2AD3; Wed, 27 May 2015 16:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uVbfycZBf6fG; Wed, 27 May 2015 16:41:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D38B61B2AD1; Wed, 27 May 2015 16:41:41 -0700 (PDT)
Received: by yhom41 with SMTP id m41so7015223yho.1; Wed, 27 May 2015 16:41:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HDP9NdQvVgkUN7K/kGilmG+FwZ+h3vHclOoVw+ee2F8=; b=UCNhCzOSbjJwh1E4mmBtulJ9szKRPY1oNERoacLMIkjsBcQwKc3ZZUCBXH9U025cVb uJhMsLPz06wRTF1Jlbf/8/eZv90K2pVKrKtXC3hevAv5pvyZL99TllhIh5eCxbkiki8y n3vCmpcJnPNTnIVApSMzPp9tshe/BekBNmKQJjYELmcmUKkGrCFtYTmDhv60hFGxU220 A3qyT6Tmwnkd2iOG5rEGeua/KW3imxZSam3zn9YRwNc9l5SbTynTL+Q9lNsIkUgzOMQL dMKvjn1qfTs77ZwuvqCQN5TYIYAzPa9LlD5B6zOmO4CDkEaHm3Jx8Zy/9dBT3p/pTIZf 7X9Q==
MIME-Version: 1.0
X-Received: by with SMTP id m83mr21791758ykb.110.1432770101205; Wed, 27 May 2015 16:41:41 -0700 (PDT)
Received: by with HTTP; Wed, 27 May 2015 16:41:41 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 27 May 2015 16:41:41 -0700
Message-ID: <>
From: Martin Thomson <>
To: "Black, David" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
X-Mailman-Approved-At: Thu, 28 May 2015 09:13:01 -0700
Cc: "" <>, "" <>, joel jaeggli <>, "" <>
Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
X-Mailman-Version: 2.1.15
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: Wed, 27 May 2015 23:41:43 -0000

I apologize for not catching these, but I think that you are
collectively headed toward changing the intent of the draft in ways
that might not be good.  Unfortunately, I'm not always able to consume
the amount of email that is produced in relation to this draft.

On 27 May 2015 at 15:05, Black, David <> wrote:
> However, the first sentence in section 10 of RFC 5245 says:
>    All endpoints MUST send keepalives for each media session.
> Therefore, this draft normatively modifies RFC 5245, but there was no
> indication of that modification during IETF Last Call, as the draft
> contains neither an Updates: header nor a summary description of changes
> to RFC 5245.

That's one interpretation.  Or, we could say - more explicitly - that
this is intentionally contrary to the advice in RFC 5245.  We're
overriding 5245, not patching it.  Other users of RFC 5245 can
continue to be bound by the restriction.

BTW, no ICE implementation I'm aware of follows the requirement to
send keep-alives (I'm certain that some compliant implementations
exist, just that my limited exposure hasn't included one).  That
reduces the risk that a recipient is checking and enforcing that peers
are sending keepalives to nil, in case you are concerned about the
interop risk.

>> >> [4] In Section 4.1, please explain or provide a reference for what "paced"
>> >> means in "paced STUN connectivity checks or responses."
>> Pacing is explained in the same section below. Let us know if this is not
>> sufficient/not clear.

Actually, "paced" has a specific meaning in ICE and the word was used

The intent is to permit ICE connectivity checking, no more, no less.
Absolutely not consent maintenance.

Perhaps something like:

   An endpoint MUST NOT send data toward any transport address unless
the receiving endpoint has consented to receive data, unless the
messages are those that are used to establish consent.  Connectivity
checks that are paced as described in Section 16 of [RFC5245] and
responses to connectivity checks are permitted.

I disagree with David about the editorial nature of some of the
changes he suggests, but I'm prepared to wait for proposals and
discuss them.  I'd be very happy if those changes manifested in the
form of pull requests.