Re: [dsii] Potential IETF Work Items

Scott Brim <> Wed, 15 August 2012 14:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D64CD21F8867 for <>; Wed, 15 Aug 2012 07:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.593
X-Spam-Status: No, score=-103.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dfeL0OSW9yqn for <>; Wed, 15 Aug 2012 07:10:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 17D0F21F8864 for <>; Wed, 15 Aug 2012 07:10:04 -0700 (PDT)
Received: by yenm5 with SMTP id m5so1963909yen.31 for <>; Wed, 15 Aug 2012 07:10:03 -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=b+TbZbLAxrjZztlDRWhBth/glOSiec1fmSKNfjkn5ZY=; b=jKN4HjothnhlL5ge43H58itorVAmmPqUpveq7ubnLKWrNU5tvfYdsz6CQeafqDzPNj 4DwiW45BWRu+s/z9t89jMttQY83AhiuPc456vZTolDtAsWqhXo9Mxvn7H7/ePdi0sJFP NQodeLN+w0rJ70yJ3QISN6xZTS+D6IrXgT9X9Tqi23YcI1BFzXJjs9lEC4EfrARwBVXj ULr7DoIsGjgGehdZdKQiW7KGILZ//7wRJoghu6Zdtq3f2vjjLFswrRMomD9OfQRK5aBR /kWGbQ8yK4t/lF4XSUwqbIrqEE9myv5VqT2V5+vALisAcK/bssCy+8qyzIRBvLMf29Vr qiPg==
MIME-Version: 1.0
Received: by with SMTP id n3mr32265845paw.53.1345039803457; Wed, 15 Aug 2012 07:10:03 -0700 (PDT)
Received: by with HTTP; Wed, 15 Aug 2012 07:10:03 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 15 Aug 2012 10:10:03 -0400
Message-ID: <>
From: Scott Brim <>
To: Russ Housley <>
Content-Type: multipart/alternative; boundary=f46d042dfd3db1a14204c74e7b1a
Cc: "" <>
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 14:10:05 -0000

On Tuesday, August 14, 2012, Russ Housley wrote:

> At the DSII BOF in Vancouver, Andy Maffei gave a list of potential work
> items.  Is there interest in pursuing any of them in the IETF?
> Tom my memory, Andy raised this list of potential action items:
> * Summarize existing schemes being used for PIDs
> * Develop recommendations on a limiting number of PID schemes
> * Define an "Interoperability API" for registering dataset identifiers
> (perhaps based on the EZID API)
> * Specify a core set of metadata to be provided by all dataset (probably
> includes a number of dublin core attributes as well as a digital
> fingerprint)
> * Specify a set of conventions for resolving PIDs associated with datasets.
> In addition, there seems to be some overlap with the CDNI WG.  They are
> also considering some metadata issues; see, for example,
> Should the IETF specify conventions for paths of PIDs for data objects?
>  These might include location metadata, access policy, authentication
> methods, authentication credential, and so on.
> Russ

These issues are very significant to us (Internet2), as we serve
researchers and they ALL have data issues.

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.  There is
a slight overlap with CDNI but not much.  However, we (Internet2) need to
work on these issues somewhere, and if the IETF is glad to host the work,
we're glad to be active in it.

-> I suggest a side discussion at the October DSII meeting in Arlington
about specifics of how the IETF could help.  (Alas, I can't be there, it
overlaps with our member meeting.)

Regardless of where the work is done, I do not think we should attempt
"limiting number of PID schemes" (they, like collaboration environments or
mail apps, are very subjective and attempts to quash inventiveness will be
futile).  Instead of putting large amounts of effort into unification and
not completely succeeding, we should try for federation: define interfaces
for interworking while also supporting local innovation.   The "core set of
metadata" is that which is to be presented to the "interoperability API"
... whether metadata is constructed that way internally should be an
independent matter.