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

Christer Holmberg <> Fri, 29 May 2015 01:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A20F41A00F0; Thu, 28 May 2015 18:23:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sjfAtF3OFoxU; Thu, 28 May 2015 18:23:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 441E81A006C; Thu, 28 May 2015 18:23:46 -0700 (PDT)
X-AuditID: c1b4fb25-f79b66d000001131-bf-5567bfa18d7e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id FC.E2.04401.1AFB7655; Fri, 29 May 2015 03:23:45 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Fri, 29 May 2015 03:23:44 +0200
From: Christer Holmberg <>
To: Ted Hardie <>, "Black, David" <>
Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
Date: Fri, 29 May 2015 01:23:44 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D86E037ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM+Jvre7C/emhBismylpsPbyW3eLVqTWM Fr1NS5gt5ux6wGSx9l87u0XjXDsHNo+zRxYwehw5MpvFY+esu+weS5b8ZPL4cvkzWwBrFJdN SmpOZllqkb5dAldG194VzAX3KioW3DrM0sC4p7SLkZNDQsBEouH2XkYIW0ziwr31bF2MXBxC AkcZJc4+mcAC4SxmlGj9M5m1i5GDg03AQqL7nzaIKSLgKXHqpwhICbPAFkaJabM/sIMMEhYI lbg7cRWYLSIQJvH26DImCNtPYvOfJ+wgvSwCqhLrzrKBhHkFfCVWfTnICLHqLpPEo43/wHo5 BQIl3s9YCtbLCHTc91NrwGxmAXGJW0/mM0EcLSCxZM95ZghbVOLl43+sELaSxKLbn6Hq8yU2 Xb3PDrFMUOLkzCcsExhFZyEZNQtJ2SwkZbOATmUW0JRYv0sfokRRYkr3Q3YIW0Oidc5cdmTx BYzsqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjECI/bglt+qOxgvv3E8xCjAwajEw/tgXVqo EGtiWXFl7iFGaQ4WJXFez66QUCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MXrWfVCskLwav ccmq+SnQUn01LzC1+cKa4nq7hm3Gc7WY+433N7/l5BLUP3g9Y/3eu8ePNVeyTNvlFHHg6Oek hUy1azesVHc2zF4v+rLUaGLhvO8S+W5r/tSv0ghVYTzR7Nhtv4C3dsE/d6Epy6V/NIQETH4u 1pF3oOTjQutzFdeuCWeZH8lXYinOSDTUYi4qTgQALkM9HrkCAAA=
Archived-At: <>
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: Fri, 29 May 2015 01:23:50 -0000


Section 20.2.3 of RFC 5245 says:

“STUN keepalives (in the form of STUN Binding Indications) are sent in
              the middle of a media session.  However, they are sent only in the
              absence of actual media traffic.”

So, in the consent draft we could say that, from a keepalive perspective, consent requests are considered media traffic. That would then implicitly mean that actual keepalives aren’t sent when consent is used. That way, the consent spec would be compliant to 5245, and there would be no need for any update etc…



From: rtcweb [] On Behalf Of Ted Hardie
Sent: 28 May 2015 23:26
To: Black, David
Cc:; joel jaeggli;;
Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13

Hi David,

On Thu, May 28, 2015 at 12:36 PM, Black, David <<>>

I'd expect that even overriding RFC 5245 counts as an Update,
because the result would be that the original RFC 5245 "MUST" requirement
is no longer globally applicable to all uses of RFC 5245.  In other words,
overriding RFC 5245 effectively rewrites the "MUST" to become "MUST, except
as further specified by the consent RFC."

​So I agree with you that this must be called out, but I think "Updates" is wrong for the draft's current intent.  I think what Martin has said amounts to "We have chosen to follow RFC 5245 except as detailed in sections X and Y, where we use a different set of messages to optimize the combination of heartbeat and consent."  We are not updating RFC 5245 thereby, because we are neither changing its core semantics nor offering to add a new, general semantic to RFC 5245 (we could have made that choice, but are not doing so now).  Instead of updating RFC 5245, in other words, we are limiting our reference to it.
That should be done explicitly, and I think it should be called it suffiiciently that a new spin of the draft likely needs a new round of review.  But I don't think we are required to update RFC 5245 to get that done.
I've referred the matter to our friendly AD, and we await her reading on next steps on this.  In either approach, however, this will get called out.
Ted HArdie​