Re: [dsii] Potential IETF Work Items

Ted Hardie <> Wed, 15 August 2012 15:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7537921F881D for <>; Wed, 15 Aug 2012 08:06:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.632
X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ejXgK+RpK9yK for <>; Wed, 15 Aug 2012 08:06:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E405321F87B2 for <>; Wed, 15 Aug 2012 08:06:02 -0700 (PDT)
Received: by vcbfo14 with SMTP id fo14so1831413vcb.31 for <>; Wed, 15 Aug 2012 08:06:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=50vt9Ll0Khf8FQ8vPLjPq6Q7O174GTAWoBwLnokN9dA=; b=WpE2kWGOjrP0jm81SayQoYelH+/9eabysi1WAFK6pfWXTaexFsswdst50cXwbYs+Zr /N/D/YKXoMyXLeiTEInddMHI60cuOYOSP1qtf8YOwWGZboiNIfmfWDcKwvH82l/bHbgL dkE/1JvhZ8/Aqp1yhPKmaFclsRLWMalYrudkCY8lfM7hCrkFOR6gePViozErikXZ8tI4 v6RGXB/Xq8f6t/qHS0hR7CQ/hYNslD4yJW9aZ1/LH8q4ypMsj11saYLVbVyoh87YQcN0 6vJGVIEpNRJgRcOEpHR7Tagcp6XXfH20QrfqbpCaSrgZswAEnOENBLOmBufRIgBfeLm3 tTTg==
MIME-Version: 1.0
Received: by with SMTP id x13mr11226976vds.43.1345043162150; Wed, 15 Aug 2012 08:06:02 -0700 (PDT)
Received: by with HTTP; Wed, 15 Aug 2012 08:06:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 15 Aug 2012 08:06:02 -0700
Message-ID: <>
From: Ted Hardie <>
To: Scott Brim <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Russ Housley <>, "" <>
Subject: Re: [dsii] Potential IETF Work Items
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Aug 2012 15:06:05 -0000

On Wed, Aug 15, 2012 at 7:10 AM, Scott Brim <> wrote:
> The problems are large but I also wonder what part of this is in IETF scope.
> I asked about this in the halls after the BOF.  If this work takes place in
> the IETF I will be very involved, but IETF expertise is primarily in
> protocol engineering, and I don't see much need for that here.

Well, one way to look at the IETF is as a set of structures the enable
whoever is interested in a specific technical topic to come together
under known rules; so if the big data community does the work here,
that community is part of the IETF and thus does have the related
expertise.  One of advantages of participation as the key identifier,
rather than membership, is that we have that fluidity.

But beyond that, there is a lot of IETF-relevant protocol work to be
done in this space: in  network discovery, online access methods,and
in access control.  We didn't focus on that part of the work in the
BoF because it generally needs to come after the core identifier
interoperability work has gotten a mental framework built.  In many
ways, though, that's when real cross-fertilization with existing IETF
work will get going.   While you could argue that that is after that
core interoperability story is ready that it should come to the IETF,
I think we all benefit if it gets early exposure.

To take one example, a simple way to create interoperability in a
system like this is to have a layer of indirection which creates a new
identifier in a distributed global namespace by hashing the existing
identifier with other metadata so as to create a new globally unique
name within the new namespace.  You go to the new namespace manager to
retrieve the mapping and there you go, right? Of course the access
control methods on such a scheme are three kinds of nightmare and the
new namespace manager needs a global caching scheme to prevent the
index from being unwieldy, but that creates a discovery/redirection
scheme that looked so easy to avoid with a single, global, trusted
namespace manager.

If you know what a particular interoperability method will end
implying in terms of related network infrastructure, access methods,
and access control, you avoid that simplistic method of creating
interoperability via single indirection (or at least you know what
you're getting into).  Giving the Big Data folks a home here helps
makes sure that those issues get surfaced early, and that may be a
benefit to all of us.

Just my two cents,

Ted Hardie