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

Wesley Eddy <> Thu, 06 January 2022 19:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 854AE3A1588 for <>; Thu, 6 Jan 2022 11:54:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Status: No, score=-2.611 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.714, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gWXmm4J4YdEJ for <>; Thu, 6 Jan 2022 11:54:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 022E93A1583 for <>; Thu, 6 Jan 2022 11:54:10 -0800 (PST)
Received: by with SMTP id v4so3439594qtk.0 for <>; Thu, 06 Jan 2022 11:54:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=+ogxuO5k0632yi9+tj5fYOxuFxpYMR3AE/9n21VJV5c=; b=09iGI5Hs3851/6Gt5RzlEVRS7KBpN4pC45ea3f1SRh4NSVKphNIuocsPkVGJQRwCwk ks8X2RqRpTZ+R2Xpp18VBfqBCZwEu0rzCu0VoYdiuwPx+vbPFgQA6EXSQ0Jrk5diCoSR iWZyeivbJ+LxYtIKu3jkvU8Ep4EcY2vtKV7+2XWnEb5CjZ7H7FXX5ui3BTnRLs7h0+ic ogeU3z7kGQ/39QHvfQvfpfnzb8QEed+h7kwNdTAxL6sfwApzwgm7XPjlbDNR4aA8UxvK 805YxNd0GXvwL52338kelsCUjwj3DSmQ3jk/CwrM3Z0jFPM9mZw+YYRJzdL5tALkJVlQ pbhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=+ogxuO5k0632yi9+tj5fYOxuFxpYMR3AE/9n21VJV5c=; b=zgJ3Z5GLmmWtSNcdysYXf0TX/uqcyWxjJm9FOZJW8OuUywsl8tP5wdGGpXIiDb9QmY g6yT5DVBLz1iyqYlOch+n84TbJxUl73o0t2ioNL0czt48sdGWacVQUACgSvLxy8/0ig7 oqCSHOmDw9RsiESPRQTxRT6ikCHwFCI93vVMmhCls+3xmnP1oXhxrmXrJj6ErMzCiwha zWuRY0sqC/Wl2go0DStJ9vsgWeunMm+d6pSMfc7EruEXc4+ca2YTYaLz33nigCtn1ZoD QyzOCbSy6i1Dvcdhh4dIDs4NnOCT0HS8ak7TIoCKuEQ+PqRyNncEUcj8ze/+4CTAS0G1 7xrg==
X-Gm-Message-State: AOAM531Brmu80A3Aa3CZpCgcJjfoJUdzOaDk8PPEV9NMaLzIcWtFEudy zEwVKFnxtpqjr6RkC/qiTtlvHQ==
X-Google-Smtp-Source: ABdhPJzFZVu/VQ87L6T26aIyNnnLnlg4w+sFMvmUKyi9RXpbia4EZ3NsLHk1yLg/EaztDz3UNDE5Ug==
X-Received: by 2002:ac8:5c4a:: with SMTP id j10mr3753024qtj.449.1641498849247; Thu, 06 Jan 2022 11:54:09 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id s3sm1972244qkp.93.2022. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Jan 2022 11:54:08 -0800 (PST)
Content-Type: multipart/alternative; boundary="------------YUoXb72QLxgi0tJwxtKbuoOp"
Message-ID: <>
Date: Thu, 6 Jan 2022 14:54:07 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1
Content-Language: en-US
To: Zaheduzzaman Sarker <>, The IESG <>
Cc: "" <>, "" <>, "" <>, Michael Scharf <>
References: <> <> <>
From: Wesley Eddy <>
In-Reply-To: <>
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: Thu, 06 Jan 2022 19:54:13 -0000

This has been on the back burner for a while, but looping back to it now 
... here are some changes I've got ready for submission in a -26 
revision, to see if they sound good to you.

On 9/24/2021 6:01 AM, Zaheduzzaman Sarker wrote:
> As we are not deprecating the use of urgent mechanism and it is MUST 
> to support any details to support that is still normative. One 
> alternative would be to bring the related parts of 6093 to the 793bis 
> and be explicit about the warning ( different and incompatible), this 
> fits to intention you describes also perhaps fits better to the fact 
> that 793bis is obsoleting 6093.
In 793bis, the change in the definition of the urgent pointer from 6093 
has been fully incorporated.  The only value to referencing 6093 is to 
point to historic and contextual information to explain the odd 
situation.  In the working copy, I've changed the sentence referencing 
to it from:

    Details can be found in RFC 6093.


    Information on how some TCP implementations interpret the urgent
    pointer can be found in RFC 6093.

To be clear, there are no details required for a correct implementation 
in 6093 that aren't in 793bis; 6093 just provided a lot of explanation 
about the situation of the urgent pointer, implementation status, usage 
by applications, and then made the SHLD-13 and MUST-30 statements (that 
are in 793bis) as a result.

> Feels like 793bis then should update 1011 as well, as it does to 1122.
You're right, since this is the new TCP specification, it should update 
1011 to say that the things noted there have been included.  I've added 
that in the working copy, and some text explaining it as:

    RFC 1011 contains a number of comments about RFC 793, including some
    needed changes to the TCP specification.  [...]  The present
    document updates RFC 1011, since the comments noted in 1011 have
    been incorporated.:w