Re: [Nsaas] OpenSource v.s. IETF standards

Melinda Shore <> Thu, 11 September 2014 23:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 62BC31A0240 for <>; Thu, 11 Sep 2014 16:39:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gJ2NXIZazt80 for <>; Thu, 11 Sep 2014 16:38:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF0461A001E for <>; Thu, 11 Sep 2014 16:38:58 -0700 (PDT)
Received: by with SMTP id y13so10597128pdi.21 for <>; Thu, 11 Sep 2014 16:38:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=K1bZubSZ6oTslXfMgFhLvTqTGZ3b1u4dpg33g9QV/to=; b=Tj7+Rcv4Ks1sKnjpz1q3UY7KnG9on6ydKixQ2dvL66z570aLceGhqVTfVDHTZ9uRHA WsNn4+If2pgjGHf0qlfcZCq1m6tDAYGUiSzKVx1PtPNyvRzzyu4BPn2Ac+mBkw0RUTWe cKvWd/mzIGubYQrgSGUEj0w+me3+7SEEKDdaihkHBbkn0C42B9MhaY+KjPMpklGdjdIg gbwv2NjaikNR4s+QxxdlDog+PyOLn+/VeixV1WLkDx+t6OPBRRguHxALkfTneN0DAa5z xmH4480zE0KfXUYWZOuVuUqNuFWCiWlNTC/5ziyrYWpz3jTErIBCA1nmGAyCswvE8wGg 5fjw==
X-Received: by with SMTP id dq10mr6687993pdb.112.1410478738534; Thu, 11 Sep 2014 16:38:58 -0700 (PDT)
Received: from spandex.local ( []) by with ESMTPSA id rk11sm2183217pab.22.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Sep 2014 16:38:57 -0700 (PDT)
Message-ID: <>
Date: Thu, 11 Sep 2014 15:38:56 -0800
From: Melinda Shore <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
References: <4A95BA014132FF49AE685FAB4B9F17F645DEAEEE@dfweml701-chm>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645DEAEEE@dfweml701-chm>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Nsaas] OpenSource v.s. IETF standards
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "*NSaaS: Network Security as a Service mailing list*" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Sep 2014 23:39:02 -0000

On 9/11/14 3:21 PM, Linda Dunbar wrote:
> This writing has really good suggestion. Looking for feedback.

I actually think he may be preaching to the choir.  Standards
people are going to tend to think standardization is a good thing.
He might get a rather different response from a group developing
open source implementations.

At any rate I don't think the question is whether or not standards
are good, but rather in this *specific* case, where there are
implementations underway, who would benefit from standardization
of some of these services and how they would benefit.  If there
is exactly one implementation, there is not an interoperability
issue.  And you'll note that one of the principal arguments for
open source is that the code is reviewed and vetted by a large
number of people, allowing the verification of the correctness of
the code (and algorithms).   So, this would not be considered
a distinguishing feature of the standards process.

At any rate this is why I keep asking about product plans and
customers - there needs to be a reason to do this work, one that
would benefit someone besides document authors.  I think that
the immediate task is to identify a few specific pieces of work
(i.e. protocols) that are needed for specific applications and/or
deployment scenarios, and have a good story about its relationship
to other work underway in other bodies (standards, implementation,
whatever).  We should also be clear that if we start from a
very, very high level - "We want to standardize something to do
with security in the cloud and we propose work to figure out what
that might be," you're guaranteeing at least an additional
year before something gets published (on top of however long it
takes to develop and publish a specification or three).  Given
how slowly the IETF is now working in the best of circumstances,
it seems like one might wish to avoid that.