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

OKUMURA Shinji <ietf.shinji@gmail.com> Sat, 11 July 2020 04:11 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 4D3633A0DF6 for <sipcore@ietfa.amsl.com>; Fri, 10 Jul 2020 21:11:09 -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 KgsyrcgfSbRS for <sipcore@ietfa.amsl.com>; Fri, 10 Jul 2020 21:11:07 -0700 (PDT)
Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) (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 85ED63A0DF4 for <sipcore@ietf.org>; Fri, 10 Jul 2020 21:11:07 -0700 (PDT)
Received: by mail-pl1-x642.google.com with SMTP id f2so3047675plr.8 for <sipcore@ietf.org>; Fri, 10 Jul 2020 21:11:07 -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=OJrzo4PzdXLtD3KCVr5dbbTdfmK6RYhQu1k8qg1/EvI=; b=fcXOerLiuzNdeWzC5YHyBBEwL3UYcOoEkfcYKnqPAnDuuClJ+EV/A7sqmvjcaT3YMu NnE4qRtAea6J7/RRTKLbbVPQAtJnILqR7VCl2mIzcsqRaEhWVa9SogQR6v5Hteax0XBW iNKuXceXXtdOWid+qRmKZLrtmK4MndLp4eXlZiI8ONeEMsy5k8iz9pP8UVxZOjcp2+VE TySv0Hdfk5BveH8hCpUxZTxG7N80pxnWluLSpp06AxjzZolES6kA1SuaCZYip8pWJWID MR6xDhjGQKMgAhYCLQpbsA+jGLTc1PqUX+BEvj9GUwy4uzaMVTyXLNMBZbwhBsifYaT6 q6OA==
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=OJrzo4PzdXLtD3KCVr5dbbTdfmK6RYhQu1k8qg1/EvI=; b=sXhU9MWlXvlBNh4BsuprtAPCoomdVqO4AJROf0iw3i5mYgAoJc0eO4LD9mJD+Fxvmf cwrYNEn6Sis2agIa/NPb3Y4C8Y18674kOgXYos9VOxG6qaee9UhQ0Dk93FFnli6Ev1z3 WYN4NUumFmUtaxaq7Pf6aZCOTVe1oL86ueugb//FWcxg05u8ngEiEt3TW4sbfCx5LtvW fTreemVENAihCdL7RkqA5gi32M86D2cgZ7mRY3Dv9qQPncDwLQFWu1aKFleH+GJAXgnz ReuyJJjuKibCp9CXhzLXJapnL2M6ALKPsi7Yc2xtGikQCMn8hHS8y1KAVCemFt8YC5/i JdQw==
X-Gm-Message-State: AOAM531w7nKvqVg3Eqx/VTQB7ujZVYhQZBU1PLoZK9jTUp89ky2mBbuK C5iBGTXK56j7Ec1QdRnqKTQ=
X-Google-Smtp-Source: ABdhPJzkwuSelgY/R06iGEYNlUETIAJlSGtHqC09N9Dq2Oc9xmUtr2uGgtHuhg4CTapMJ8nI+uiUvg==
X-Received: by 2002:a17:90a:a608:: with SMTP id c8mr8506481pjq.114.1594440667018; Fri, 10 Jul 2020 21:11:07 -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 g22sm7269502pgb.82.2020.07.10.21.11.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jul 2020 21:11:06 -0700 (PDT)
From: OKUMURA Shinji <ietf.shinji@gmail.com>
To: SIPCORE <sipcore@ietf.org>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>, Roman Shpount <roman@telurix.com>
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> <1554aecb-fad1-436c-947c-088ddf71b5b5@gmail.com> <66b73776-1c57-33ac-09a9-d60b7e6996b7@alum.mit.edu>
Message-ID: <36562af9-bb48-74b1-0ffa-a90c3ad45c5b@gmail.com>
Date: Sat, 11 Jul 2020 13:11:00 +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: <66b73776-1c57-33ac-09a9-d60b7e6996b7@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-8, 2020/07/11), Outbound message
X-Antivirus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/-ryD_tld3uHkW5DaM3xbwSZVyNA>
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: Sat, 11 Jul 2020 04:11:09 -0000

Hi,

On 2020/07/11 0:26, Paul Kyzivat wrote:
> On 7/10/20 10:56 AM, OKUMURA Shinji wrote:
>> 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.
> 
> Where do you find this in 4028.

P.13
    If the value of the Session-Expires header field is lower
    than the value of the Min-SE header field (possibly because the proxy
    increased the value of the Min-SE header field, as described below),
    the proxy MUST increase the value of the Session-Expires header field
    to make it equal to Min-SE header field value.

Of course, negotiation with downstream proxies and UAS will occur.

>> 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.
> 
> If proxies along the path (and the UAS) could both increase and decrease the value of SE, then you don't have a negotiation. Rather, those further along the path have priority over the earlier ones.
> 
> By having both SE and Min-SE, with SE only being reduced and Min-SE only increased, everybody on the path has input into the final result.

I understand the basic policy, but when the UAC that received the 422 response retransmits the INVITE with a larger SE and MSE set, the proxy cannot reduce the SE. I think the result will be the same as if the proxy increased SE.

Regards,
Shinji