Re: [Patient] the IETF participant choice

Ted Lemon <> Mon, 19 March 2018 21:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A30A9127058 for <>; Mon, 19 Mar 2018 14:23:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZbrKGrpSViU3 for <>; Mon, 19 Mar 2018 14:23:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64AEC1200A0 for <>; Mon, 19 Mar 2018 14:23:52 -0700 (PDT)
Received: by with SMTP id v194-v6so12127479itb.0 for <>; Mon, 19 Mar 2018 14:23:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L0jC4FGVPoRC5JcO01W1SvWQ50mQ/yHjXsKiNuiucfU=; b=VgtU5YLfmfD8q4ansB2LApj/emvqG4E37DrGZdDQx5Gt1yyAp/FonLnTWhzBIw2GQP wC2sAOjZSoEOQlGhBmeTH6kT3IES9qR33TQPYRaa22hCZukuUCG85qSvn0L90c7xj14I pQZvl5nQgFgOFnOwA0Ode1FsZ69nQ2pYvYezWOmXwt0kdMm/WdoOfjS0EVK6zL/eUyr0 IFXWTra4m8HYik+BvmZ3LYMJg7hwpHZUxIfRInAQxbBuPtl5+oAF1kLZRosKR0DAdrj7 vjp29L27PPEgU7dE82mXOSfGpMxIDrZFiX8eqoGK9CIj7kgZf29qLoHw/w3v66g2ygUI saYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=L0jC4FGVPoRC5JcO01W1SvWQ50mQ/yHjXsKiNuiucfU=; b=CCXPLFiAI2kcHGlVduQW91ZtaIo56gA3x1zgJJJsPPNi/R6g9tWUcY6BbFjM6hDB3F l7Fftzk8Fq7YLPmyty6G+cMvkZJwEV4pfLVcHN/m3Pdvodt7HvVFAFrEwVTllPw4yeHR +MK3Y1B+KG14Bjnn7oUZEjk9rvc3gHp8+DM8tDw9P4Fvjqaq1abBMwiWfy0dqzz2xr/q kgRtQsnc+oDKsXq3EoxOffTGnkqEpBD/PfAIxNEHNyAhRJaf/fgXbf8b0qWmnthjxWjf B6uKOeDiRuhWTup5xV7nmEHyW0BwpME2958mE6PHXI3g6YRcx8XRbn7x3Ln1veTdGgTX wDuw==
X-Gm-Message-State: AElRT7FURuEXM7diOBOMDlrdS+fmDVaJn1ZbJC5Bi31CI1MMaX+b1AUy qm5MZpLJqhz8vJMPCvm5GPukCNSoDxICVGwMMkdV+w==
X-Google-Smtp-Source: AG47ELsQy5RCQTuN3Rp0/CNcYdnEhq7bQQGPKG4Ndn0nr27Ys5R8ogkK8v7vy+hjmzfvBoGP2TVKt3XOESfOH0sPJfI=
X-Received: by 2002:a24:9b8a:: with SMTP id o132-v6mr337227itd.82.1521494631653; Mon, 19 Mar 2018 14:23:51 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 19 Mar 2018 14:23:51 -0700 (PDT)
Received: by with HTTP; Mon, 19 Mar 2018 14:23:51 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Ted Lemon <>
Date: Mon, 19 Mar 2018 21:23:51 +0000
Message-ID: <>
Cc: "" <>, Brian Witten <>
Content-Type: multipart/alternative; boundary="0000000000000c3eef0567ca93c1"
Archived-At: <>
Subject: Re: [Patient] the IETF participant choice
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Protecting against Attacks Tunneling In Encrypted Network Tunnels <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Mar 2018 21:23:55 -0000

There are individuals who show up here to talk about why they need stuff
and use their own operational problems as examples. That's how we always do
this. It's really a process of successive approximation.

On Mar 19, 2018 20:38, "Tony Rutkowski" <> wrote:

> The concern here begs the question, "whose" systems analysis?  The IETF is
> not some kind of Land of Oz where a wizard has the answers to all manner of
> complex systems requirements.  There are many competing requirements across
> all manner of data centres, architectures, providers, and user
> communities.  Meaningful implementations will also require acceptance and
> adoption by an equally broad array of communities.
> There are no solution singularities here, and multiple tailored
> specifications are certain to emerge.  The academic and patent literature
> evidences several dozen of them. Indeed, whatever any standards body does
> will be competing with a large number of proprietary solutions.  The only
> certainty is the demand for effective solutions.
> In TC CYBER, we are moving ahead with our own and evolving them in light
> of this reality - hopefully with essential reflection and criticism from
> IETF participants.
> --tony
> On 19-Mar-18 4:07 PM, Ted Lemon wrote:
> On Mar 19, 2018, at 8:01 PM, Tony Rutkowski <> wrote:
> In participating remotely, it was apparent that although the proponents of
> the data centre visibility proposal did an excellent job in articulating
> the need, the solution was not going to be undertaken by the IETF.  The
> result in consonant with countless other similar initiatives sought in the
> IETF over the past several decades.
> The thing is, at least from my perspective, we haven't done a systems
> analysis yet, and so it was just premature to try to get the TLS working
> group to weaken TLS in order to solve the problem.   For example, the claim
> was made that it would be "too expensive" to do anything _other_ than
> modify TLS, but where's the analysis to support that position?   Too
> expensive to use middleboxes, but where's the analysis there?
> This is really an ops problem.   IETF can do ops work, but ops isn't about
> changing protocols—it's about figuring out good solutions to problems.
> Sometimes the answer to an ops problem is "we need some protocol work
> done," but that's not the starting point.
> As a consequence, I feel like some very well-meaning people came to the
> IETF with hat in hand and didn't get what they'd hoped for, and probably
> have the impression that people here don't care about their problem, when
> that's not actually the case.   Lots of people I talked to who were against
> the proposed solution care very much about the problem.
> _______________________________________________
> PATIENT mailing listPATIENT@ietf.org