IETF Logo Mail Archive

Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11

Alissa Cooper <alissa@cooperw.in> Fri, 01 May 2015 23:19 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEBA1A6FEB for <rtcweb@ietfa.amsl.com>; Fri, 1 May 2015 16:19:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 XKuH3DOt_iR8 for <rtcweb@ietfa.amsl.com>; Fri, 1 May 2015 16:19:23 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C881A6EED for <rtcweb@ietf.org>; Fri, 1 May 2015 16:19:23 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9543D20BCA for <rtcweb@ietf.org>; Fri, 1 May 2015 19:19:22 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 01 May 2015 19:19:22 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=7zaWpW7FtCqMDgjHovo7OUMdjac=; b=aWy8y3 5+c+g3g/1uWmgs1JrhsWbwmueW8VcojDAMAFWDhjp/cAAGtHAkACfmiFeXsd/Tec 1pZvs73R3E5fJ8a3fI6iYMXpJd9TH2pd9Qdgp8AxNTslcvrNOozb+cUT5S/9NOcE JMohSmvK49D9oAOjdblMAIPAPv3PBm2I5F3uY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=7zaWpW7FtCqMDgj Hovo7OUMdjac=; b=AF5CsuNrcavICsdAzbkRvl9g+B7I1hKFQeQux6NNg9ushPP NVzbpkvMvjlDt+81HKLP7e+UjrKaAeatG8JLn6jjp0NX848zzGV7d2Fht59yqtNt Ad72HdTfDcIvrJid7G8wM0aHCRg18m3k8WSo863TpWS29sEjh9CEI45a+UjA=
X-Sasl-enc: XuG0t35P0pwQtcMGfRjNplRtArnZOPyEURA6AUIehi4G 1430522362
Received: from [192.168.1.203] (unknown [24.6.61.198]) by mail.messagingengine.com (Postfix) with ESMTPA id 9EAB5C00013; Fri, 1 May 2015 19:19:21 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <CABkgnnU=NeP7MzqxE1Mg+ZN8EZf=3FtayyLP1Q-z=6vaPUtAuA@mail.gmail.com>
Date: Fri, 01 May 2015 16:19:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in>
References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> <CABkgnnU=NeP7MzqxE1Mg+ZN8EZf=3FtayyLP1Q-z=6vaPUtAuA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/RBjSz678EsD5lJgn0SjrgQi0GOY>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Fri, 01 May 2015 23:19:24 -0000

On May 1, 2015, at 9:54 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 30 April 2015 at 17:32, Alissa Cooper <alissa@cooperw.in> wrote:
>> "An endpoint that is not sending any application data does not need to
>>   maintain consent.  However, failure to send could cause any NAT or
>>   firewall mappings for the flow to expire.  Furthermore, having one
>>   peer unable to send is detrimental to many protocols."
>> 
>> It sounds like the unstated implication here is that if you are such an endpoint, you should keep doing consent checks anyway to maintain consent. Should that be stated explicitly, or am I misunderstanding?
> 
> Can you tell that this is my text?
> 
> Yep, the unspoken implication is that if you stop maintaining consent,
> a flow is highly likely to break.  I'm OK with making that explicit.
> 
> ... .  Absent better information about the network, an endpoint SHOULD
> maintain consent if there is any possibility that a flow might be
> needed again.

WFM

> 
> (Thanks for the suggestion on Sec7.  I wasn't happy with it before.)

v2.23.0 | Report a Bug | By Email