Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16

Marc Petit-Huguenin <petithug@acm.org> Mon, 23 April 2018 17:46 UTC

Return-Path: <petithug@acm.org>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D888512D88A; Mon, 23 Apr 2018 10:46:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.442
X-Spam-Level:
X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 HPBso3AI8B1S; Mon, 23 Apr 2018 10:46:07 -0700 (PDT)
Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C885312D889; Mon, 23 Apr 2018 10:46:06 -0700 (PDT)
Received: from [IPv6:2601:648:8301:730f:fdb6:1cc8:478a:5b55] (unknown [IPv6:2601:648:8301:730f:fdb6:1cc8:478a:5b55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 747AAAE844; Mon, 23 Apr 2018 19:46:04 +0200 (CEST)
To: Peter Saint-Andre <stpeter@mozilla.com>, art@ietf.org
Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org
References: <152270998513.17947.16209089088681034529@ietfa.amsl.com> <ec1d7013-4886-6f96-21a2-3c758fc633cf@petit-huguenin.org> <c6df754b-8aea-637c-a8bf-7ccadc0d8704@mozilla.com> <6422219a-5c2d-4590-3088-0f1afa3feb8f@petit-huguenin.org> <00ddbc05-2a96-d77e-f260-7d0b3c0f4074@petit-huguenin.org> <5f036c89-07b1-8d9d-cd18-8d9381ef8adf@mozilla.com>
From: Marc Petit-Huguenin <petithug@acm.org>
Message-ID: <d27e3cbf-41a4-7fb0-9791-8995721e4d92@acm.org>
Date: Mon, 23 Apr 2018 10:46:02 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <5f036c89-07b1-8d9d-cd18-8d9381ef8adf@mozilla.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HbSK1bmpKHBO7Al1fHJB33Ot8fFkTISvn"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/34kATnNDQU_eMi0QceJgK8qFBCM>
Subject: Re: [tram] Artart telechat review of draft-ietf-tram-stunbis-16
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Apr 2018 17:46:09 -0000

On 04/22/2018 08:30 PM, Peter Saint-Andre wrote:
> On 4/21/18 3:39 PM, Marc Petit-Huguenin wrote:
> 
>>>>>> Section 6.3.4 states:
>>>>>>
>>>>>>    o  If the error code is 500 through 599, the client MAY resend the
>>>>>>       request; clients that do so MUST limit the number of times they do
>>>>>>       this.
>>>>>>
>>>>>> It is reasonable to provide guidance as to the number of re-sends?
>>>>>
>>>>> Same issue here, that's a section that is unmodified from RFC 5389. 
>>>>
>>>> I understand. Now is our chance to fix it. :-)
>>>>
>>>>>  As long as the client does not enter an endless loop of retransmission, choosing different numbers of re-sends does not affect interoperability.
>>>>
>>>> Choosing different numbers is OK, but choosing an infinite number is
>>>> not. Can we provide guidance as to how many is too many? 10? 50? 100?
>>>
>>> Well, the text already states that an infinite number of of re-sends is not compliant.  Anyway, I am not sure how to determine a reasonable number, but I'll try.
>>
>> I chose 4 as the maximum number of retransmissions.  I based that on error code 508 in TURN that defines a delay of 60 seconds between retransmissions, so we now get a delay of 5 minutes before the client gives up in case of insufficient capacity.  The new text reads like this:
>>
>> "o  If the error code is 500 through 599, the client MAY resend the
>>     request; clients that do so MUST limit the number of times they do
>>     this.  Unless a specific error code specifies a different value,
>>     the number of retransmissions MUST be limited to 4."
>>
> 
> "SHOULD be limited to 4" seems fine, but MUST is OK too.
> 

Changed to SHOULD.

Thanks.

-- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug