[rtcweb] Consent Freshness: Some suggestions for editorial clarifications

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 17 September 2014 07:41 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 2B76E1A0349 for <rtcweb@ietfa.amsl.com>; Wed, 17 Sep 2014 00:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL4aRbcdeuQp for <rtcweb@ietfa.amsl.com>; Wed, 17 Sep 2014 00:41:33 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F001A0310 for <rtcweb@ietf.org>; Wed, 17 Sep 2014 00:41:32 -0700 (PDT)
X-AuditID: c1b4fb30-f79736d0000053b8-ce-54193b2adde9
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DB.87.21432.A2B39145; Wed, 17 Sep 2014 09:41:30 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Wed, 17 Sep 2014 09:41:30 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: Consent Freshness: Some suggestions for editorial clarifications
Thread-Index: Ac/SSsrqFkDxItNJTuG8HxXaj35NUA==
Date: Wed, 17 Sep 2014 07:41:29 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D44E72A@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D44E72AESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvja6WtWSIwZdOeYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVceksZ8Fj04rV+08zNTCu1Oti5OSQEDCRmDrnOxOELSZx4d56 ti5GLg4hgaOMEtPvdrGDJIQEljBKNBwt7WLk4GATsJDo/qcNEhYRUJe4/PACWImwgKfE5kXP mSDiARKNryayg5SLCOhJrHngDRJmEVCVWH7iMiOIzSvgK/Hqyg6wVkagtd9PrQFrZRYQl7j1 ZD7UOQISS/acZ4awRSVePv7HCmErSfzYcIkFoj5fYtalBewQMwUlTs58wjKBUWgWklGzkJTN QlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGKFqcWJ+WmGxnppRZlJhcX5+fp5aWW bGIERsPBLb8NdjC+fO54iFGAg1GJh1fhtUSIEGtiWXFl7iFGaQ4WJXHehefmBQsJpCeWpGan phakFsUXleakFh9iZOLglGpgbHskV5DGbNfx++7+p8pdGxgWs3k3h/1p2NviufFh4+Zdl4tF F8+XdL4/L+Hs9izjsgnzXfiXrfpXE1V6Q7SyLtNAYH5cn0Oxd8C07YbCgl0hk5Mz9sudmv/0 pdbeyuT84k2P+dQsBI6xBRUknVln9L5rRU9IyLb0jDOljxjKW/ey9QWp1f5VYinOSDTUYi4q TgQALxGKiGcCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DyZeQNxL27f8aWog1YF_tP2mxhA
Subject: [rtcweb] Consent Freshness: Some suggestions for editorial clarifications
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: Wed, 17 Sep 2014 07:41:35 -0000

Hi,

Based on feedback I receive from implementers, there are a couple of clarifications I think would be useful in the consent freshness draft.



Q1:
-----

As STUN binding requests for consent are sent unreliably, and are not re-transmitted, I think it would be useful to have some explicit text saying that individual requests (and/or their associated responses) may get lost in the network, and that a sender must be prepared that a response to such requestmay never arrive.

It may be obvious to us, but maybe not as clear to the first-time reader of the draft.




Q2:
-----

Section 4.1 says:

"That is, if a valid STUN binding response corresponding to one of the STUN requests sent in the last 30 seconds
                has not been received from the remote peer's Transport Address, the endpoint MUST cease transmission on that 5-tuple."

First, I suggest the following clarification:

s/"to one of the STUN requests sent in the last 30 seconds"/"to one of the STUN requests (not necessarily the last one) sent in the last 30 seconds".


Second, there is no explicit text on for how long the client keeps the STUN transaction alive, i.e. for how long it waits for the response.

I assume that, after 30 seconds, the client does not need to maintain state and wait for the response anymore. I think it would be useful to explicitly indicate that, and also say that responses that are received after that time must be discarded.

Thanks!

Regards,

Christer