Re: [tcpm] Zaheduzzaman Sarker's Discuss on draft-ietf-tcpm-rfc793bis-25: (with DISCUSS and COMMENT)

Wesley Eddy <> Wed, 22 September 2021 22:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E7263A1167 for <>; Wed, 22 Sep 2021 15:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zpNNUoyN59U5 for <>; Wed, 22 Sep 2021 15:27:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 19E093A116C for <>; Wed, 22 Sep 2021 15:27:54 -0700 (PDT)
Received: by with SMTP id d8so4358945qtd.5 for <>; Wed, 22 Sep 2021 15:27:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=ZWxv+YNjinPn36MBZTLp7IxycyqKiGR2zslGgd3txTI=; b=CmTV18WoI7M7Mix1jXxp8xU1Liz0YzbrESsWLqGQl9ZfZMj+DW2464gAzpUkYvg1Je lssRe5Q/vUQBtC31ROVjNSMb3XIKhJEDrcfkyFtmf+PUp2JUbgSwy7++Rb0CFFlVVJtF XeCWHd76XkJu1uBs5ZtO0og9+IEcx7I6Lp9HwQwQFw+BVoE4MR+JiLfcgxB19KwKFbd/ C+y/tILEsiGPJ/0q80mbjYnbng97x6coEHf1PNl1WKBa4Fn4byJtbuI3mjllb9dWmDNu qw4bg8ltbyPbprcKRmjD0FYg/ze9oPGDLzLKCmp3kqIye1CYYuB2V1C7qfGXic1cw7XW LJ+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ZWxv+YNjinPn36MBZTLp7IxycyqKiGR2zslGgd3txTI=; b=KVdblZm8u8LFYd/iJhiN3+1S6bGPixOR/32jtk7CkQF7yBorc0R2wQ2zaFTaiKzsXw jvXvO5t1ma84JbxMRCbBJ2ZAOoN0qqJO3LxWwF9GwaJN9ZhZa13eWuBhgobo0rBkDWZa eNFm+SOd7r8N0h6jXMRS3yLy//ryLnUu4/yK+FUeP9Ebp0YrOLnhQ2jvNO3zo0bJa4fq GxwrWcgpJvZ/Nw4koK9v+mirPgi+LvGb0wsmQCqjGjPtvfUHGSZIsgpJixQ9+gwICuZI ABI65fnaRfZg2jPyoXEwxmBQSlfwOcCRRvLqveUE0vLQQXaPW09Xhuf8WOyh0dnv3rDY DxlA==
X-Gm-Message-State: AOAM532UrqHXsYoNN7jQjnLKZBWD8B3MGNwYirZuQ2W5PAXVrZGIVtzi AElt4VdY0p0VZhKnH61x1bLbnA==
X-Google-Smtp-Source: ABdhPJyR2JhID9ef/K5MSnQG5ngKVbQAqnPa0BenUOI4NACR92FJ0PpyiYs5olvVERk7l/7xgykXJg==
X-Received: by 2002:ac8:57d4:: with SMTP id w20mr1751034qta.261.1632349673559; Wed, 22 Sep 2021 15:27:53 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id bi10sm2657019qkb.36.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Sep 2021 15:27:52 -0700 (PDT)
To: Zaheduzzaman Sarker <>, The IESG <>
Cc:,,, Michael Scharf <>
References: <>
From: Wesley Eddy <>
Message-ID: <>
Date: Wed, 22 Sep 2021 18:27:49 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------FBF94EF39C38344C389DC0FD"
Content-Language: en-US
Archived-At: <>
Subject: Re: [tcpm] Zaheduzzaman Sarker's Discuss on draft-ietf-tcpm-rfc793bis-25: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Sep 2021 22:28:00 -0000

Hi Zahed, I'll get to your (and the rest of the IESG's) other comments 
later, but wanted to answer to your DISCUSS points more immediately.  
See below.

On 9/22/2021 4:46 PM, Zaheduzzaman Sarker via Datatracker wrote:
> * I found at least one reference that should be normative reference but they
> are not. Section 3.8.5 : describes --
>      TCP implementations MUST still include support for the urgent mechanism
>      (MUST-30). Details can be found in RFC 6093 [38]
>    This to ne makes RFC6093 a must to read and understand to deploy this
>    specification. Hence it should in the normative references.

I propose to change this to say "Details on how some TCP implementations 
interpret the urgent pointer can be found in RFC 6093 [38]."  I think 
that would be more of what we want to convey, since it has been done 
differently (and incompatibly), thus why we say that applications 
shouldn't rely on it!  I think this is the right thing to do rather than 
a normative reference, because our goal was to incorporate the normative 
parts of 6093 into this 793bis.

Does this sound okay to you?

> * (This perhaps more process thing than technical), me and Benjamin Kaduk
> discussed another issue regarding urgent pointer. This specification specifies -
>         Pointer indicates first non-urgent octet       | MUST-62|
>    RFC1011 rectifies RFC973 to -
>        The urgent pointer points to the
>           last octet of urgent data (not to the first octet of non-urgent
>           data).
>    So what does happen to RFC1011 rectification then when 793bis is not bis
>    anymore? Is this a known fact and there is conscious decision not to do
>    anything about it? or was this a unknown fact and that part of RFC1011 need
>    to be obsoleted (how?)?

RFC 6093 was written to solve all of this confusion :).  There is really 
nice explanation in 6093 that when implementations were surveyed, most 
were not following 1011 (and 1122's incorporation of that bit from 
1011).  The logic and situation is explained more in 6093, but the most 
relevant short passage I can quote that is clear on the current 
situation is:

    we hereby
    updateRFC 793  <>  [RFC0793  <>],RFC 1011  <>  [RFC1011  <>], andRFC 1122  <>  [RFC1122  <>]
    such that "the urgent pointer points to the sequence number of the
    octet following the urgent data" (in segments with the URG control
    bit set), thus accommodating virtually all existing TCP

Hopefully that helps!