Re: [tcpm] WGLC for UTO

Mark Allman <> Mon, 15 October 2007 11:50 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IhOSu-0000pR-1g; Mon, 15 Oct 2007 07:50:32 -0400
Received: from tcpm by with local (Exim 4.43) id 1IhOSr-0000f7-9B for; Mon, 15 Oct 2007 07:50:29 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IhOSq-0000PI-Dt for; Mon, 15 Oct 2007 07:50:28 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1IhOSl-0000Dx-SN for; Mon, 15 Oct 2007 07:50:24 -0400
Received: from ( []) by pork.ICSI.Berkeley.EDU ( with ESMTP id l9FBoKLU021056; Mon, 15 Oct 2007 04:50:20 -0700
Received: from ( []) by (Postfix) with ESMTP id 1E9BD10B52FE; Mon, 15 Oct 2007 07:50:14 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id DBF9F2C9F99; Mon, 15 Oct 2007 07:48:34 -0400 (EDT)
To: Pasi Sarolahti <>
From: Mark Allman <>
Subject: Re: [tcpm] WGLC for UTO
In-Reply-To: <>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Who Are You
MIME-Version: 1.0
Date: Mon, 15 Oct 2007 07:48:34 -0400
Message-Id: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============1029258808=="

> The draft looks fine to me to go forward.

Many thanks for the note!

I have a couple questions (with my hat off) ...

> Regarding the Proposed Standard vs. Experimental issue, I think this
> draft, like the other new TCP extensions, should first go to
> Experimental as a rule of thumb. I'm concerned about the increasing
> complexity and size of "the standards track" TCP implementation. It
> would be a good practice to have a careful evaluation in Experimental
> RFC phase before adding up things to standards track TCP that is
> expected to be implemented by most vendors.

(1) What 'careful evaluation' do you think should be done during

    Or, put another way, how would we know that it was OK for UTO to
    later move to PS?

    My own opinion here is that this draft specifies a way to share some
    information and that is pretty benign.  I can't see where it hurts
    anything if stacks want to do it.  It is advisory information if
    stacks want to ignore it.  So, what's the real harm here in putting
    it on the standards track?  Or, what would be the benefit of going
    experimental?  My own answer to both questions is "very little".

(2) While I sympathize with the goal of keeping things simple and
    avoiding needless complexity, I do not believe that just because we
    put something on the standards track we expect it to be implemented
    in every TCP implementation.  Perhaps that is flawed reading of
    these things.

Just my two bits.


tcpm mailing list