IETF Logo Mail Archive

Re: [sipcore] RFC4028 : Very basic question in 8.1

OKUMURA Shinji <ietf.shinji@gmail.com> Fri, 10 July 2020 14:56 UTC

Return-Path: <ietf.shinji@gmail.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DB13A0E01 for <sipcore@ietfa.amsl.com>; Fri, 10 Jul 2020 07:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 aVTl273cPNfB for <sipcore@ietfa.amsl.com>; Fri, 10 Jul 2020 07:56:50 -0700 (PDT)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629E43A0CF8 for <sipcore@ietf.org>; Fri, 10 Jul 2020 07:56:50 -0700 (PDT)
Received: by mail-pg1-x532.google.com with SMTP id l63so2622665pge.12 for <sipcore@ietf.org>; Fri, 10 Jul 2020 07:56:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=R0GbCH6OiaAXNyVeY/lLGrid+1faJVVQDw5FYC7cA08=; b=shQ4INJAQiU/AdzT7UeQ/Tad/kchTXdYlFi52KUFUjBfOK8/buJEMsY/0H6QyWaADl duJ4qzVa8Yb+92o2XP7Lwbkh0FnArA0VUoxcEjm9tQovlWRITDSzveju2LwIw05HFH9p MO1aYF4B/+nrNdgVB+FV0xGL9tmBXYE8XoDAG2w+m6To0aQO2+ekfTZdYsL+jGXwMSnc OtIHwrumRs56G4K/dunc1aShQdow7HfyV1KP5jolslv1spnhumDeaVolPF3bCSVDUC7v PCb10WW4A7pMEO4Oe1yoFjtjOcIbYxXaiwg41n2D9dypmJFTUeF+OGyk9M4ZKMJHQvNg J/LQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=R0GbCH6OiaAXNyVeY/lLGrid+1faJVVQDw5FYC7cA08=; b=HkVFEGZSBpXRhoBd1noiZbt06fY4W5EIFAxe7pfhToVCwAdjVanNxZFlJ3sNXqqh8/ d46g5swpA8VJ3pQ9mv6iZwZzR7Jsb+WPPoA4evhQZ5404ZctcdRwIKFz6WX4Z9orq334 ksWwJxA06H2vRSUwr2XxbqElRKiRabI2DIFLvLJ4FLIwyHht2/K2WIP2o7Py+rBhkUGD GE/MxQpelJiPwEwLde4VRRZ8Hg5u7a7YnWgRoezv1ARcXppOXRZDpQMnSEZgn1IzKCFt x6W2vEhO5vHVkvkJ8u17gRc5KgssddJ0WBcHTkWpjNrqGhVnXk+BGlT0Xn9QhyUNQFHB erLA==
X-Gm-Message-State: AOAM532V7DaBKdrcb28W/5wixQiR+2prrfruQnQg+2nw34I15nB3Yt1g xHIwFizBkt5lrB2fh0QaXBmtycq7
X-Google-Smtp-Source: ABdhPJy6Rb6/rkMPaPX9mEZKFdLmHXQOC7AYOiWhFywO7cu2fc6rTjgOgaJeRhlR8PSStFJ0hMbHAg==
X-Received: by 2002:a05:6a00:15c3:: with SMTP id o3mr60916654pfu.304.1594393009618; Fri, 10 Jul 2020 07:56:49 -0700 (PDT)
Received: from [192.168.128.64] (112.136.2.241.er.eaccess.ne.jp. [112.136.2.241]) by smtp.gmail.com with ESMTPSA id m6sm6603248pjb.34.2020.07.10.07.56.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jul 2020 07:56:49 -0700 (PDT)
From: OKUMURA Shinji <ietf.shinji@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Roman Shpount <roman@telurix.com>
Cc: SIPCORE <sipcore@ietf.org>
References: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com> <CAD5OKxu1Ua79rEg-udgD-RxZjrfTmmyZMmDGvPQXp5xc1kzn1Q@mail.gmail.com> <8ab9ef7d-1df0-2adc-70fa-0473526442cb@gmail.com> <CAD5OKxuNsf1YDMZw6_KvONMafCE+vaHeNLEQoqCscp5wqHFHrA@mail.gmail.com> <7c1e3969-af88-80ca-96c4-7e6bb1d2a172@alum.mit.edu> <CAD5OKxvhoHhurMx==DLw8DWPYJ5XXoqcS1d1L2-Xp304egCeow@mail.gmail.com> <30d2b673-ed42-45f9-c8c7-58f99ae347af@alum.mit.edu>
Message-ID: <1554aecb-fad1-436c-947c-088ddf71b5b5@gmail.com>
Date: Fri, 10 Jul 2020 23:56:46 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <30d2b673-ed42-45f9-c8c7-58f99ae347af@alum.mit.edu>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Antivirus: Avast (VPS 200710-0, 2020/07/10), Outbound message
X-Antivirus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/528kEjBFdh1DhjQtQeRejj4Pjto>
Subject: Re: [sipcore] RFC4028 : Very basic question in 8.1
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jul 2020 14:56:52 -0000

On 2020/07/10 2:11, Paul Kyzivat wrote:
>> What I am trying to avoid is ending up with a non-obvious set of changes to an existing specification which will act as a barrier to implementation. Letting proxies increase SE would be an example of such change.
> 
> Upon rereading 4028 I was surprised to discover that proxies MAY increase SE to the extent necessary to conform with an increased Min-SE! I hadn't remembered that part. But AFAIK that is the only case where it is allowed.

In fact, proxy is conditionally allowed to increase SE directly without renegotiation. And RFC does not specify the procedure to reject if too large.
This is why I interpret the RFC does not attach importance to increase of SE.

And you said,
> If the Min-SE and SE are higher than one of the proxies desires, then it is pretty much out of luck. In some sense this is futile for it to complain because the timer refreshes are only part of the traffic.

So, I want to know why must a proxy not increase SE-value?
I think this is a very basic and important premise of RFC, but there is no specific explanation.
I say again, this is not a suggestion, but a question.

Regards,
Shinji

v2.23.0 | Report a Bug | By Email