From scott.brim@gmail.com Mon Aug 6 12:38:41 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B88021E80A6 for ; Mon, 6 Aug 2012 12:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.593 X-Spam-Level: X-Spam-Status: No, score=-103.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiehEhRXVxs1 for ; Mon, 6 Aug 2012 12:38:40 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B959121E80A8 for ; Mon, 6 Aug 2012 12:38:40 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4271103pbb.31 for ; Mon, 06 Aug 2012 12:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=CFHeexy17n/2/bXzeWB5fh7h6ZnRKW6GKM9z7TLpmE0=; b=vsoWm+g2E/p13WL4KS4rUh+rvLfL/YHI41kZEbHF+n0De7QHEgkPzROqConoMGaqof 2AOay/F32QM53bqpduP+E7xZjC2IhXem5EfVPh7ohdlG4LvcSSHQjPrm9eyRbCW6Bx+i rGcE8eed401XZUJd6qzRLzek27AFMEJdb05tIdPcLhvzrGniKnmf7sBMTj4bf2K6KWHp tyGAnvBxpRmRCpZHn0ZS4NtYz50Hnbgto4A5M5kwsQ2QIYljdhnNvb/F60Nj2zNGFtku RfZSGJeqRtaXhQhcy9Tmltgcxl6UmDJkySkYTQ1wXF0gs7q+5p/pOx8EEaAqb1wMXnvn xXZA== Received: by 10.68.220.231 with SMTP id pz7mr21247739pbc.110.1344281920467; Mon, 06 Aug 2012 12:38:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.48.231 with HTTP; Mon, 6 Aug 2012 12:38:19 -0700 (PDT) From: Scott Brim Date: Mon, 6 Aug 2012 15:38:19 -0400 Message-ID: To: dsii@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [dsii] slides please X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 19:38:41 -0000 Could I get the slides that were shown at the meeting? Thanks ... Scott From ted.ietf@gmail.com Mon Aug 6 12:59:47 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD30521F84B5 for ; Mon, 6 Aug 2012 12:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfGpwwzMSUwY for ; Mon, 6 Aug 2012 12:59:47 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B9BEE21F84B3 for ; Mon, 6 Aug 2012 12:59:46 -0700 (PDT) Received: by weyu54 with SMTP id u54so2560677wey.31 for ; Mon, 06 Aug 2012 12:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p/2Y2hGbIoa0N9MRfPpDj8bkxMynLqdhtW2EOXmanm0=; b=FgabyE6YZpK9Z2Ikx4M/VWBVV9tQryZ2DNFWojjnfriNsVNiBxOfmOw2izZFRpoO6u SyvWDC1By7T928sUJdjICGcNVTmBDuVA6atmoC8x8P5nZFdVakaYq1vJciaao1YBliCw ZEt5f/h8DR675LeShUCZA1BFnhed9iv5UoHgf9f/r9DmMJTVsnioEzEdwVmZtX6FSbu/ 3E61AimX3CoBDl7LFzsFUrwLEaNF4HEhDV/0d3KTBBKWMApQ2PP46A7I1fOnmg8o2SxV 1lcPn/K72JlxSihrcAXUhY2Te+NhFRsYUoWStvMmKgIWZriSX7To8l/jHov4BcL/j34d c1CA== MIME-Version: 1.0 Received: by 10.216.242.204 with SMTP id i54mr6052459wer.112.1344283182756; Mon, 06 Aug 2012 12:59:42 -0700 (PDT) Received: by 10.216.90.134 with HTTP; Mon, 6 Aug 2012 12:59:42 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Aug 2012 12:59:42 -0700 Message-ID: From: Ted Hardie To: Scott Brim Content-Type: text/plain; charset=ISO-8859-1 Cc: dsii@ietf.org Subject: Re: [dsii] slides please X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 19:59:47 -0000 Hi Scott, https://datatracker.ietf.org/meeting/84/materials.html should have everything, if you scroll down to the DSII section. regards, Ted On Mon, Aug 6, 2012 at 12:38 PM, Scott Brim wrote: > Could I get the slides that were shown at the meeting? > > Thanks ... Scott > _______________________________________________ > dsii mailing list > dsii@ietf.org > https://www.ietf.org/mailman/listinfo/dsii From scott.brim@gmail.com Mon Aug 6 14:13:55 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3E111E80FA for ; Mon, 6 Aug 2012 14:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.593 X-Spam-Level: X-Spam-Status: No, score=-103.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-+0liC6hFw0 for ; Mon, 6 Aug 2012 14:13:54 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E15BF11E80DE for ; Mon, 6 Aug 2012 14:13:53 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4371150pbb.31 for ; Mon, 06 Aug 2012 14:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=H8gp7o3tWy7whld4mAi2XXjXjoLjLDliLS8XS1CRsVo=; b=cZfYigeBkfhSvSseiqTBrnxrKhfOqjlwW399zYmALkWhFMiElE5HRoyxsng8rqND2z O8dfzd5W7Z9IMjhBaaP4lYEl+zlGWoIElhhdFLLY9VY6tvr/mCvvFuolC9beR8EZijLG Mjmx6/xAn76Ru3PwITGsUAAzYT8q+9B/P7AZKkXu6ep79x5MeDex2WwpTuDi2K5Kh6nX QGMG7SNJCmPJFHmDxdbrVPvXEqsbr8PXCPyFJ0YihynL26y7fWQS9RtePUZVshMv9Bhv 6vrAxDHsYuKfwLtlgKIVMTSthuv+tfIX9mNA1ccRZJ/7wN3W45853ikedqnkeJhhVOSK HmgQ== Received: by 10.68.233.103 with SMTP id tv7mr22341366pbc.124.1344287633548; Mon, 06 Aug 2012 14:13:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.48.231 with HTTP; Mon, 6 Aug 2012 14:13:32 -0700 (PDT) In-Reply-To: References: From: Scott Brim Date: Mon, 6 Aug 2012 17:13:32 -0400 Message-ID: To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Cc: dsii@ietf.org Subject: Re: [dsii] slides please X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 21:13:55 -0000 On Mon, Aug 6, 2012 at 3:59 PM, Ted Hardie wrote: > Hi Scott, > > https://datatracker.ietf.org/meeting/84/materials.html should have > everything, if you scroll down to the DSII section. Thanks, I didn't scroll far enough and got stopped at the Apps Area meeting. From housley@vigilsec.com Tue Aug 14 07:16:31 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC5D21F86D8 for ; Tue, 14 Aug 2012 07:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDBPk4Ol6jU8 for ; Tue, 14 Aug 2012 07:16:30 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5E72321F86B8 for ; Tue, 14 Aug 2012 07:16:30 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id EFE7BF24094 for ; Tue, 14 Aug 2012 10:16:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 9+2n71Fdbfk8 for ; Tue, 14 Aug 2012 10:16:24 -0400 (EDT) Received: from [192.168.1.3] (96-37-2-47.dhcp.sffl.va.charter.com [96.37.2.47]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id DA540F24090 for ; Tue, 14 Aug 2012 10:16:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Russ Housley In-Reply-To: Date: Tue, 14 Aug 2012 10:16:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> References: To: dsii@ietf.org X-Mailer: Apple Mail (2.1084) Subject: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 14:16:31 -0000 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, = http://datatracker.ietf.org/doc/draft-cjlmw-cdni-metadata. =20 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= From melinda.shore@nomountain.net Tue Aug 14 08:56:50 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F333621F8644 for ; Tue, 14 Aug 2012 08:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PI85EP09Eqd for ; Tue, 14 Aug 2012 08:56:49 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6182121F85AC for ; Tue, 14 Aug 2012 08:56:49 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 14AD754075 for ; Tue, 14 Aug 2012 08:56:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=nomountain.net; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=nomountain.net ; b=j1WylPE0SaP8ffBRGOElniq1nCxuo7ZhZW1iZBEM0JPITIHnZssDIrD97k9T ffSRwcoQvmu8UoCJi0Tj7K3P0sbNpxJ/YKRF9EX6xKgibeNpiXHlU6ujkxIdNDwT rlr6INjyBPuaRN+ruDbOc3QrxVLs4TiEgl/VLBFk8rooucU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=6lcL9NTig3CLb5t0ZIgSW7/j+14=; b=J2iL5Q9gFjcrq 9wuK2IQX4XVMFpHAkS8ObPM1XsdsuM8nCZevY/yQw6YH7Q/1S3Ba6Z5A2z/5SYHI BFGLPzW2lpNEsc2hIA1IS8qLTafeD6FRxZDyEbgeXV/jh0FX70GiQ3ZirrPRXPrp ydO8EWj+2UqVgmfuXWTDYU1EVGCKRw= Received: from spandex.local (66-230-82-208-rb1.fai.dsl.dynamic.acsalaska.net [66.230.82.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id BDE565405B for ; Tue, 14 Aug 2012 08:56:48 -0700 (PDT) Message-ID: <502A753F.4010001@nomountain.net> Date: Tue, 14 Aug 2012 07:56:47 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: dsii@ietf.org References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> In-Reply-To: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 15:56:50 -0000 On 8/14/12 6:16 AM, 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? I think that given our history with other standards bodies trying to standardize IP technologies and our reaction to those, it might not be a terrible idea to tread a little lightly here, and make sure that the IETF wouldn't be stepping on anybody else's toes. I'm generally not a fan of bringing this work to the IETF, but if there really is support for it I think that we do have the expertise within the organization for working on identifiers and we definitely do not have the expertise for working on what's basically library metadata. I also think that we shouldn't be in the business of attempting to limit PIDs, because, basically, we can't. I'm unconvinced that much thought has been given to what sort of expertise the IETF can bring to bear on any of these questions. Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.com "Software longa, hardware brevis." From amaffei@whoi.edu Tue Aug 14 09:35:54 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A2F21F8534 for ; Tue, 14 Aug 2012 09:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdNbERM6gZWM for ; Tue, 14 Aug 2012 09:35:53 -0700 (PDT) Received: from postal1.whoi.edu (postal1-e0.whoi.edu [128.128.76.87]) by ietfa.amsl.com (Postfix) with ESMTP id 544C621F850B for ; Tue, 14 Aug 2012 09:35:52 -0700 (PDT) Received: by postal1.whoi.edu (Postfix, from userid 117) id A418F2C8277; Tue, 14 Aug 2012 12:35:51 -0400 (EDT) Received: from dyn-128-128-91-195.whoi.edu (dyn-128-128-91-195.whoi.edu [128.128.91.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal1.whoi.edu (Postfix) with ESMTPSA id 2C9E62C8251; Tue, 14 Aug 2012 12:35:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Andrew Maffei In-Reply-To: <502A753F.4010001@nomountain.net> Date: Tue, 14 Aug 2012 12:35:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2F3EA305-7E9A-4822-BE8C-C937FB2AB3B5@whoi.edu> References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> <502A753F.4010001@nomountain.net> To: Melinda Shore X-Mailer: Apple Mail (2.1278) X-Virus-Status: No Cc: dsii@ietf.org Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 16:35:54 -0000 On Aug 14, 2012, at 11:56 AM, Melinda Shore wrote: > On 8/14/12 6:16 AM, 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? >=20 > I think that given our history with other standards bodies trying to > standardize IP technologies and our reaction to those, it might not be > a terrible idea to tread a little lightly here, and make sure that > the IETF wouldn't be stepping on anybody else's toes. >=20 > I'm generally not a fan of bringing this work to the IETF, but if > there really is support for it I think that we do have the expertise > within the organization for working on identifiers and we definitely > do not have the expertise for working on what's basically library > metadata. I also think that we shouldn't be in the business of > attempting to limit PIDs, because, basically, we can't. >=20 > I'm unconvinced that much thought has been given to what sort of > expertise the IETF can bring to bear on any of these questions. >=20 > Melinda Thanks Melinda, I think the two initiatives are getting at a "getting to know you" = stage. I agree that more thought is required and treading lightly is a sound=20 approach. My list was intended as brain-storming fodder rather than a well-thought out proposal for moving forward. My hope is that there is some way that the lessons-learned over the = decades by the IETF about interoperability approaches would be transferrable to the dsii interests -- whether around indentifers or certain types of metadata. I found that the metadata I-D for the CDNI WG, for example, had some overlap in some types of dsii metadata needs. I agree that IETF is less appropriate for more "Library-type" metadata but the CDNI metadata was not that. Three options for engagement seem worthwhile considering: 1. More dsii-interested folks currently outside IETF could start = participating in WGs w cross-cutting interests, once they are identified. 2. More IETF'ers could be engaged to participate in current dsii initiatives outside the IETF and be offered a platform from which an IETF perspective can be heard. ("Big Data" seems to be getting big these days for better or worse). 3. A dsii working-group might someday be formed within IETF. I think that the first 2 options are pre-requisites for the 3rd so that we can gain familiarity with each others use-cases and cultures and thus lower the risk of a "bad start". As I have gotten older I have learned how important "good starts" are to initiatives. --Andrew Maffei Woods Hole Oceanographic Institution amaffei@whoi.edu From leifj@mnt.se Tue Aug 14 11:13:52 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCF921F8793 for ; Tue, 14 Aug 2012 11:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHtj8V7YsxDV for ; Tue, 14 Aug 2012 11:13:51 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 3478021F878B for ; Tue, 14 Aug 2012 11:13:51 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q7EIDkOQ021574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Aug 2012 20:13:49 +0200 (CEST) Message-ID: <502A9559.1000206@mnt.se> Date: Tue, 14 Aug 2012 20:13:45 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: dsii@ietf.org References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> <502A753F.4010001@nomountain.net> In-Reply-To: <502A753F.4010001@nomountain.net> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 18:13:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/14/2012 05:56 PM, Melinda Shore wrote: > On 8/14/12 6:16 AM, 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? > > I think that given our history with other standards bodies trying > to standardize IP technologies and our reaction to those, it might > not be a terrible idea to tread a little lightly here, and make > sure that the IETF wouldn't be stepping on anybody else's toes. > > I'm generally not a fan of bringing this work to the IETF, but if > there really is support for it I think that we do have the > expertise within the organization for working on identifiers and we > definitely do not have the expertise for working on what's > basically library metadata. I also think that we shouldn't be in > the business of attempting to limit PIDs, because, basically, we > can't. > > I'm unconvinced that much thought has been given to what sort of > expertise the IETF can bring to bear on any of these questions. > > Melinda > I'd agree but for one thing: libraries are increasingly (operated by) content providers which to mind mind increases the likelihood that we'd have the right people at the table. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAqlVkACgkQ8Jx8FtbMZndREACeLUGiFhFJXHKJHJup1Gk+0nKn zGgAoKcE/e3dLYg+ru0s+KTBX9rgZ15g =Zw0l -----END PGP SIGNATURE----- From melinda.shore@nomountain.net Tue Aug 14 11:28:55 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F2621F877B for ; Tue, 14 Aug 2012 11:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bv6-2RcYh3V for ; Tue, 14 Aug 2012 11:28:54 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 71ECB21F86B5 for ; Tue, 14 Aug 2012 11:28:54 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 93A6EBC034 for ; Tue, 14 Aug 2012 11:28:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=nomountain.net; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=nomountain.net ; b=Qsp9bq2rZcRy6FcEZ33paws/Rm8XaA8HS8Xw2ML5KtbZM6a/JO+gsYxSvEBm PZbn/LJY1HK1ze6Dfh2fcOYiCoaCHxQ94JWDvNt5hwdd3h+mCnJhdllUim8gItg+ UP/bO2Oa5IoA0djfc90ANBnDatCmrLzyzzVAQpv62gAQj5g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=NXXYriAAYfocC7Qn4PDqmSPOhTg=; b=eUTaIPzKwslke 9s/1R8dZ4i92hiPRAFsTbeH10HYtCKiD77Uxl4buj6MF4JctWcW1jNsz3A02BUcg OxiBkEeBSeYMc2qpx5XFwDEeZfFPbSsWl8zgxzyhCfSOdxdbIcW6ubg/IG5EmxDd 7DBRA8Ah72uw3F/fQ0kDYxtlKlT0I0= Received: from spandex.local (66-230-82-208-rb1.fai.dsl.dynamic.acsalaska.net [66.230.82.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 4DB5EBC032 for ; Tue, 14 Aug 2012 11:28:53 -0700 (PDT) Message-ID: <502A98E3.4090401@nomountain.net> Date: Tue, 14 Aug 2012 10:28:51 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: dsii@ietf.org References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> <502A753F.4010001@nomountain.net> <502A9559.1000206@mnt.se> In-Reply-To: <502A9559.1000206@mnt.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 18:28:55 -0000 On 8/14/12 10:13 AM, Leif Johansson wrote: > I'd agree but for one thing: libraries are increasingly (operated by) > content providers which to mind mind increases the likelihood that we'd > have the right people at the table. I'm still not buying it. If you're thinking of things like the Internet Archive I'm not convinced that they aren't well-served by current technologies. If they've got some problems they need to have solved it would be far better for them to describe their problems and provide requirements than it is for us to show up on their doorstep and say "Hi, we're the IETF, and we've got technology we want you to use." It seems to me that to the extent there are issues in this space it's in what the proponents of the work (and others) are calling "big data." In the US we're seeing requirements from funding agencies for PIs to share their data, and I know that at the University of Alaska (my previous couple of gigs) they've got some very, very large collections of satellite data, climate data, GIS data, and so on that they're trying to either share for free or sell for $$$. They probably have problems around those. But. They didn't come to the IETF, and for all I know they're not even on this mailing list (I did send pointers to some people involved in the data repository work up there). Personally, I think this is an enormously interesting area but if there's something in here that's appropriate for the IETF (other than fiddly stuff like internationalization of metadata strings) I'm not quite seeing it yet. Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.com "Software longa, hardware brevis." From ed.summers@gmail.com Tue Aug 14 17:47:08 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF4821F8527 for ; Tue, 14 Aug 2012 17:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+TrU3oFujEY for ; Tue, 14 Aug 2012 17:47:08 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id ECEA321F8435 for ; Tue, 14 Aug 2012 17:47:07 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1487980obb.31 for ; Tue, 14 Aug 2012 17:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=R++xsMF84E+ZaB/Vcor/6EbEMaUu/D4PPKE84+kRMMQ=; b=PnqypOgWu4Lx71qs037+aPx34huZQ7GbG4u+6ugeMNjRS6isHge13LspTmiGFnsxtl KfOrWwmZUz/B5kkItPkkyIEBQw/23kL/gVlIyLPCFlOD8AdFiHrl4K1sn9OxpwOvFxK0 gSOtZwyoYuBYzR8RuCE2TV8pjNpLubT+/z+Y3jN7mAUoc+bUD+VX7VX3KHLunknkGjps LDnOORpI5ulbmKqm45XaF6NPfLjflFLSvOKpFlh7TuWInRAz1KRZ8xY4K4KLFzp6DzKZ C0p3l3YOPgJLBMxRnMyM8UncWC1gt2wXvDe5t2Q247t7lLy/tDuqUd5d8n0Rgpb47K+5 vCyQ== MIME-Version: 1.0 Received: by 10.60.6.167 with SMTP id c7mr9778oea.88.1344991627372; Tue, 14 Aug 2012 17:47:07 -0700 (PDT) Sender: ed.summers@gmail.com Received: by 10.60.10.37 with HTTP; Tue, 14 Aug 2012 17:47:07 -0700 (PDT) In-Reply-To: <502A98E3.4090401@nomountain.net> References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> <502A753F.4010001@nomountain.net> <502A9559.1000206@mnt.se> <502A98E3.4090401@nomountain.net> Date: Tue, 14 Aug 2012 20:47:07 -0400 X-Google-Sender-Auth: 0WSybAvK3ztyBL4laxZZY8Jg9EU Message-ID: From: Ed Summers To: dsii@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org 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 00:47:08 -0000 I wasn't at the BOF, but that won't stop me from chiming in :-) I'm personally skeptical of digital library inspired efforts to create identifier schemes and protocols that ultimately try to compete with the URI, HTTP and DNS--work that has largely gone on here at the IETF I might add. I find statements like the following to be a bit of a red flag: 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. The URL and HTTP already provide much of this. I think efforts like the DSII should promote the use of existing standards that have made the Web such a successful publishing platform. The degree to which DSII goes it alone is the degree to which it will fizzle out, and go unnoticed. //Ed From scott.brim@gmail.com Wed Aug 15 07:10:04 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64CD21F8867 for ; Wed, 15 Aug 2012 07:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.593 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfeL0OSW9yqn for ; Wed, 15 Aug 2012 07:10:04 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (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; d=gmail.com; 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 10.66.76.227 with SMTP id n3mr32265845paw.53.1345039803457; Wed, 15 Aug 2012 07:10:03 -0700 (PDT) Received: by 10.68.30.8 with HTTP; Wed, 15 Aug 2012 07:10:03 -0700 (PDT) In-Reply-To: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> Date: Wed, 15 Aug 2012 10:10:03 -0400 Message-ID: From: Scott Brim To: Russ Housley Content-Type: multipart/alternative; boundary=f46d042dfd3db1a14204c74e7b1a Cc: "dsii@ietf.org" Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org 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 --f46d042dfd3db1a14204c74e7b1a Content-Type: text/plain; charset=ISO-8859-1 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, > http://datatracker.ietf.org/doc/draft-cjlmw-cdni-metadata. > > 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. Scott --f46d042dfd3db1a14204c74e7b1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tuesday, August 14, 2012, Russ Housley wrote:
At the DSII BOF in Vancouver, Andy Maffei gave a list of potential= work items. =A0Is 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 identi= fiers (perhaps based on the EZID API)

* Specify a core set of metadata to be provided by all dataset (probably in= cludes 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. =A0They are a= lso considering some metadata issues; see, for example, =A0htt= p://datatracker.ietf.org/doc/draft-cjlmw-cdni-metadata.

Should the IETF specify conventions for paths of PIDs for data objects? =A0= These might include location metadata, access policy, authentication method= s, 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. =A0I asked about this in the halls after the BOF.= =A0If 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 ne= ed for that here. =A0There is a slight overlap with CDNI but not much. =A0H= owever, we (Internet2) need to work on these issues somewhere, and if the I= ETF is glad to host the work, we're glad to be active in it.

-> I suggest a side discussion at the October DSII m= eeting in Arlington about specifics of how the IETF could help. =A0(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 a= ttempt "limiting number of PID schemes"=A0(they, like collaborati= on environments or mail apps, are very subjective and attempts to quash inv= entiveness will be futile). =A0Instead of putting large amounts of effort i= nto unification and not completely succeeding, we should try for federation= : define interfaces for interworking while also supporting local innovation= . =A0 The "core set of metadata" is that which is to be presented= to the "interoperability API" ... whether metadata is constructe= d that way internally should be an independent matter.

Scott

--f46d042dfd3db1a14204c74e7b1a-- From amaffei@whoi.edu Wed Aug 15 07:53:06 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15F321F85AF for ; Wed, 15 Aug 2012 07:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEmwM0zSgeV4 for ; Wed, 15 Aug 2012 07:53:06 -0700 (PDT) Received: from postal2.whoi.edu (postal2-e0.whoi.edu [128.128.76.88]) by ietfa.amsl.com (Postfix) with ESMTP id D0D8F21F86F3 for ; Wed, 15 Aug 2012 07:53:05 -0700 (PDT) Received: by postal2.whoi.edu (Postfix, from userid 117) id E586A5245F3; Wed, 15 Aug 2012 10:53:04 -0400 (EDT) Received: from dyn-128-128-91-202.whoi.edu (dyn-128-128-91-202.whoi.edu [128.128.91.202]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal2.whoi.edu (Postfix) with ESMTPSA id 9263052470F; Wed, 15 Aug 2012 10:53:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Andrew Maffei In-Reply-To: Date: Wed, 15 Aug 2012 10:53:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> To: Scott Brim X-Mailer: Apple Mail (2.1278) X-Virus-Status: No Cc: Russ Housley , "dsii@ietf.org" Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org 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:53:06 -0000 Scott - On Aug 15, 2012, at 10:10 AM, Scott Brim wrote: > -> 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.) I agree. This makes sense. I should be there. > 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. I personally agree on this point. I brought it up in my list not because = I personally agreed with the idea but because I have heard it mentioned = by others and the idea should have an "airing". --Andy= From ted.ietf@gmail.com Wed Aug 15 08:06:05 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7537921F881D for ; Wed, 15 Aug 2012 08:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejXgK+RpK9yK for ; Wed, 15 Aug 2012 08:06:04 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (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; d=gmail.com; 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 10.52.65.141 with SMTP id x13mr11226976vds.43.1345043162150; Wed, 15 Aug 2012 08:06:02 -0700 (PDT) Received: by 10.58.228.232 with HTTP; Wed, 15 Aug 2012 08:06:02 -0700 (PDT) In-Reply-To: References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> 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 , "dsii@ietf.org" Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org 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 From melinda.shore@nomountain.net Wed Aug 15 08:32:23 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C8821E80D0 for ; Wed, 15 Aug 2012 08:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gwQOQ5cEDGS for ; Wed, 15 Aug 2012 08:32:22 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 4731821E80B0 for ; Wed, 15 Aug 2012 08:32:22 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id DEADC678069 for ; Wed, 15 Aug 2012 08:32:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=nomountain.net; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=nomountain.net ; b=ymElqwWTa29qLriZHPeEe9OFRo+GTaHNqypErecx0qe8AM7xNTgnx19zhz9U tXUMbOrcSgYmACVvnv1RxN52ukgvHl8FNBm81ZtULIkyBLSJwoZsjdvynAnKt6G1 B7pHD5cV5vcc0VTwvO9YD0Iy+L8H6qxa7V9wCVsQ+zHOoBw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=HlR8ildf+uGLYG6MpOpJC5G0vS0=; b=wnEKsBZIOTEYM jet1uQZ9rNy5LdlYkUyf3oZY+wbQiXSWdNQG5BeOe/2pdiGunSXRS7YevjQhevqu H3BM550+6xkXBODAZqE4bhnuUH2FIAmsYzL5P/05RCgo+ggIpeAdv6qnjH4YuRRw lMV24IuPk/sMA/X5fSTAK+YMS9r2a8= Received: from spandex.local (66-230-82-208-rb1.fai.dsl.dynamic.acsalaska.net [66.230.82.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 9BB3A678062 for ; Wed, 15 Aug 2012 08:32:21 -0700 (PDT) Message-ID: <502BC103.4040107@nomountain.net> Date: Wed, 15 Aug 2012 07:32:19 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: dsii@ietf.org References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org 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:32:23 -0000 On 8/15/12 7:06 AM, Ted Hardie wrote: > 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. I'm trying to remember whether or not membership was the concern with the ITU-T moving into MPLS and other IP technologies standardization. If I'm recalling correctly it came down to questions about expertise combined with old-fashioned territoriality. Just sayin'. But look: I think I'm possibly the only regular IETF person who's actually done work in this (library/retrieval) space. As nearly as I can tell from the discussion so far there's no piece of work that's been brought up that falls cleanly within the IETF's purview, but of greater concern is that there's been no real problem identified here, just an interest in the IETF doing something - anything! - with "big data." There's also a large body of existing work and a few big hunks of repository software that address some of the topics you've raised, and I wonder how many regular IETF participants can name even one. Sorry to be so negative about this - as I said, it's an area I find enormously interesting - but absent the description of a specific problem I don't see much reason for the IETF to fish for something to work on. The cloud enthusiasts were (rightly) discouraged from doing what's being done here, and it's not as if the IETF has a shortage of existing problems to solve. It seems to me that it might be a good idea for the IETF guys to take a step back and let the non-IETF people with specific expertise to sort out what problems they need to have solved. The DSII meeting in October sounds like a good place to do that. But truly, the IETFers should let the people who know what they're doing drive this. Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.com "Software longa, hardware brevis." From ted.ietf@gmail.com Wed Aug 15 08:46:41 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1653521F8606 for ; Wed, 15 Aug 2012 08:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.897 X-Spam-Level: X-Spam-Status: No, score=-3.897 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-ZgmtH8SGC9 for ; Wed, 15 Aug 2012 08:46:40 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C671321F85A5 for ; Wed, 15 Aug 2012 08:46:39 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1872449vbb.31 for ; Wed, 15 Aug 2012 08:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QZTz/vBUsHzPIK53rls5GjVh7SJ2XK7TCLkFTP/vG3M=; b=wDqLASFiyx8S5y5qE7O71p8YYQDdN786EHCzRsw8PSRQoC8n/KrutH/e6Ah3aOI0vf Hf0DZKVRbZJeSGadjfx/lJIiH/M0MuygNjFf6e7k3ZHGCGWci3otfNyrv2OVr0ZUAfWH r49Ieh+bDEwIPwBFr+zAOCCBRygu0WZbLIcfYesu3PJYQQspIA4cBQRcdZYqR4QNw5HV vzDxOMaY6gi/stYA1uqsdp6Cv6ZwZmqjPwyCAQ53UDanYfDpmmw546Qpt8spHyapyeGT VgqkI4asw1VIqAEndEWBQyF61ugtGmXP4LSkzIH5FYzGROlGnQJx3JDNmeWlaUOcfGyK vFNA== MIME-Version: 1.0 Received: by 10.220.153.7 with SMTP id i7mr13060090vcw.34.1345045599265; Wed, 15 Aug 2012 08:46:39 -0700 (PDT) Received: by 10.58.228.232 with HTTP; Wed, 15 Aug 2012 08:46:39 -0700 (PDT) In-Reply-To: <502BC103.4040107@nomountain.net> References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> <502BC103.4040107@nomountain.net> Date: Wed, 15 Aug 2012 08:46:39 -0700 Message-ID: From: Ted Hardie To: Melinda Shore Content-Type: text/plain; charset=ISO-8859-1 Cc: dsii@ietf.org Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org 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:46:41 -0000 On Wed, Aug 15, 2012 at 8:32 AM, Melinda Shore wrote: > It seems to me that it might be a good idea for the IETF guys > to take a step back and let the non-IETF people with specific > expertise to sort out what problems they need to have solved. I don't think the intent here was for the current IETF guys to drive this; it was to provide a vehicle (WG) for the current DSII folks to drive, without them having to tool up their own set of mechanics, road makers, and so on. If they take us up on that, they become IETF folks as well, which solves the problem you raise. Without them coming to participate, it would be silly and presumptuous for the IETF to take on the work, and I assume the IESG would want solid evidence of participation from the relevant community before chartering the work. But if they do decide to use our structures, I personally believe that we'd get some reasonable cross fertilization. Just my two cents, Ted Hardie From melinda.shore@nomountain.net Mon Aug 20 12:32:22 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A99721F8606 for ; Mon, 20 Aug 2012 12:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezsVTprbyvGw for ; Mon, 20 Aug 2012 12:32:21 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 54A2921F8532 for ; Mon, 20 Aug 2012 12:32:21 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id E87832AC06E for ; Mon, 20 Aug 2012 12:32:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=nomountain.net; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=nomountain.net ; b=MudMpKEDuIEeHBBf4F3yJk/H+TzToxZIs11bddez0cmvQwDomxb0V97r15xU hVT4vSADAIvapuJjwgAUhIKtiYAi+1AIZUHi1y1fYEe+FoxSd8HRSq9+9ptz7BIV bgAbUR76pWrTqpRsESVcR+jhxfX1z+yKvxc0ZenxH6ZCmQY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=J3EDI30+4n8o6CKMT7NY2cUX7ug=; b=tQaQopBkxBzhb j726hEQ0/qOw4bUfWWNAZVQKthIZW5utfUbw3RPNVbsFzZ8RCjAAbHcPQ7/NbD+b GFs71c9J1W+8jviDjcTsCxjPB7bmDfwtKNNEKGTAfCTJZYZYp/Iv/fm9abNiXpVk WOrtzj0VYaQ3BQSwoJqXyWx2yXK0OM= Received: from spandex.local (66-230-81-200-rb1.fai.dsl.dynamic.acsalaska.net [66.230.81.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 98E7F2AC059 for ; Mon, 20 Aug 2012 12:32:20 -0700 (PDT) Message-ID: <503290C2.7060608@nomountain.net> Date: Mon, 20 Aug 2012 11:32:18 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: dsii@ietf.org References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> <502BC103.4040107@nomountain.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 19:32:22 -0000 I'm still trying to figure out what's being proposed here and I realized that my mental model might be considerably different from that being used by the work's proponents. Where I'm coming from, someone who needs a chunk of data and isn't sure where it is (or, in some cases, whether or not it exists) does a search, and the search returns a set of stuff, where "stuff" includes descriptive information (metadata) and an identifier that's actually a locator. The locator is used to access the data. Is that consistent with what proponents have in mind? Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.com "Software longa, hardware brevis." From dgq2011@gmail.com Wed Aug 22 00:54:51 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EC621F8680 for ; Wed, 22 Aug 2012 00:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[AWL=0.654, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZahv7EWYfDf for ; Wed, 22 Aug 2012 00:54:47 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id BED5021F867A for ; Wed, 22 Aug 2012 00:54:47 -0700 (PDT) Received: by yenm5 with SMTP id m5so504067yen.31 for ; Wed, 22 Aug 2012 00:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yS4DRvlpdX/pVWII08VtOz9cXdCXVXUv8f7LqP0VeMU=; b=terQO3MlfnFHwq9efQ0/G7s+bZsSwbGVJG9ikh5HfS/9zzntpxIzR0Oo8tBWS6vSgx O3H672eBQUOxaeDPTBQroBxQ35nGrklmG/iQcm43p32UehMBpZlxsb+HWP4E2iTsXZCT IVVv4W/kqYb/QMHTmBwmAwf6ScNalKvzERickpzWQCsNTWGGU03UicL+XhDN+/zW9i7z /e3WyyusIyr6CRcjkwkmjdFN8isEsR8NgajSOgWXhbMDo7+o3thGZQwp0KsZdGBHhciA oqHJNWFefIsFPstd4SliWlu1SyNFkoBaI6OLSPvIaPm8glZkFm7mi/Tzf7LqQRqITWX5 FDKw== MIME-Version: 1.0 Received: by 10.50.6.225 with SMTP id e1mr1229066iga.31.1345622086578; Wed, 22 Aug 2012 00:54:46 -0700 (PDT) Received: by 10.64.52.68 with HTTP; Wed, 22 Aug 2012 00:54:46 -0700 (PDT) In-Reply-To: <503290C2.7060608@nomountain.net> References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> <502BC103.4040107@nomountain.net> <503290C2.7060608@nomountain.net> Date: Wed, 22 Aug 2012 15:54:46 +0800 Message-ID: From: Guangqing Deng To: dsii@ietf.org Content-Type: multipart/alternative; boundary=e89a8f64662b78f31604c7d60e4d Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org 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, 22 Aug 2012 07:54:52 -0000 --e89a8f64662b78f31604c7d60e4d Content-Type: text/plain; charset=ISO-8859-1 When I see "Data Set Identifier" at the first time, what comes into my mind is the identifier of objects in cloud storage system where all kinds of data are stored with high availability and flexibility. Objects stored in a cloud storage system also need identifying and interoperating, just as those data objects stored in other data infrastructures, such as EUDAT. I have read PPT files discussed in the IETF 84 BOF on DSII and find that no file relates to cloud storage explicitly. Is it because the cloud storage is too commercialized? Somehow it seems that cloud computing is not welcome in IETF though it is very popular in industry. 2012/8/21 Melinda Shore > I'm still trying to figure out what's being proposed here and I > realized that my mental model might be considerably different from > that being used by the work's proponents. Where I'm coming from, > someone who needs a chunk of data and isn't sure where it is (or, > in some cases, whether or not it exists) does a search, and the > search returns a set of stuff, where "stuff" includes descriptive > information (metadata) and an identifier that's actually a > locator. The locator is used to access the data. > > Is that consistent with what proponents have in mind? > > > Melinda > > -- > Melinda Shore > No Mountain Software > melinda.shore@nomountain.com > > "Software longa, hardware brevis." > > > ______________________________**_________________ > dsii mailing list > dsii@ietf.org > https://www.ietf.org/mailman/**listinfo/dsii > -- Guangqing Deng --e89a8f64662b78f31604c7d60e4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable When I see "Data Set Identifier" at the first time, what comes in= to my mind is the identifier of objects in cloud storage system where all k= inds of data are stored with high availability and flexibility. Objects sto= red in a cloud storage system also need identifying and interoperating, jus= t as those data objects stored in other data infrastructures, such as EUDAT= . I have read PPT files discussed in the IETF 84 BOF on DSII and find that = no file relates to cloud storage explicitly. Is it because the cloud storag= e is too commercialized? Somehow it seems that cloud computing is not welco= me in IETF though it is very popular in industry.

2012/8/21 Melinda Shore &l= t;melinda= .shore@nomountain.net>
I'm still trying to figure out what's being proposed here and I
realized that my mental model might be considerably different from
that being used by the work's proponents. =A0Where I'm coming from,=
someone who needs a chunk of data and isn't sure where it is (or,
in some cases, whether or not it exists) does a search, and the
search returns a set of stuff, where "stuff" includes descriptive=
information (metadata) and an identifier that's actually a
locator. =A0The locator is used to access the data.

Is that consistent with what proponents have in mind?


Melinda

--
Melinda Shore
No Mountain Software
melinda.s= hore@nomountain.com

"Software longa, hardware brevis."


_______________________________________________
dsii mailing list
dsii@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dsii



--
Guangqing D= eng

--e89a8f64662b78f31604c7d60e4d-- From amaffei@whoi.edu Wed Aug 22 07:08:19 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3EE21F8619 for ; Wed, 22 Aug 2012 07:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Cptv3l6A-sq for ; Wed, 22 Aug 2012 07:08:14 -0700 (PDT) Received: from postal2.whoi.edu (postal2-e0.whoi.edu [128.128.76.88]) by ietfa.amsl.com (Postfix) with ESMTP id 40F5A21F855F for ; Wed, 22 Aug 2012 07:08:13 -0700 (PDT) Received: by postal2.whoi.edu (Postfix, from userid 117) id 153DD524567; Wed, 22 Aug 2012 10:08:12 -0400 (EDT) Received: from [192.168.5.223] (ip-64-134-98-221.public.wayport.net [64.134.98.221]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal2.whoi.edu (Postfix) with ESMTPSA id 9AA22524396; Wed, 22 Aug 2012 10:08:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Andrew Maffei In-Reply-To: <503290C2.7060608@nomountain.net> Date: Wed, 22 Aug 2012 10:08:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6D125452-6D45-473A-A1B0-5DF461B80D3D@whoi.edu> References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> <502BC103.4040107@nomountain.net> <503290C2.7060608@nomountain.net> To: Melinda Shore X-Mailer: Apple Mail (2.1278) X-Virus-Status: No Cc: dsii@ietf.org Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org 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, 22 Aug 2012 14:08:19 -0000 On Aug 20, 2012, at 3:32 PM, Melinda Shore wrote: > I'm still trying to figure out what's being proposed here and I > realized that my mental model might be considerably different from > that being used by the work's proponents. Where I'm coming from, > someone who needs a chunk of data and isn't sure where it is (or, > in some cases, whether or not it exists) does a search, and the > search returns a set of stuff, where "stuff" includes descriptive > information (metadata) and an identifier that's actually a > locator. The locator is used to access the data. >=20 > Is that consistent with what proponents have in mind? Hi Melinda. The above is the primary use case. I think the "stuff" is all metadata = (attribute/value pairs about the dataset) that includes the "locator" = you mention.=20 I'd like to comment on some of the things I saw of value at the = Vancouver meeting. I don't claim to be an identifier or metadata expert = so perhaps some of these ideas were derived outside of IETF. But they = were new to me. One idea would be to consider working together to agree on the "core = metadata" that would be returned about scientific datasets for data = object access and delivery, etc. One of the more interesting IETF WG docs I found was the CDN Interconnet = Metadata i-d (draft-cjlmw-cdni-metadata-00). The sections on ACLs, = ACLRules, Delivery seemed directly applicable to delivery of science = datasets, some of which are proprietary and some of which are not. There = are all sorts of issues related to delivery of proprietary scientific = data and very large datasets (or their subsets) that seem applicable. I noticed in another I-D (can't find it right now) the practice of = allowing attribute values of type "URI" being either an explicit, fully = qualified URI *or* a regular-expression substitution that can be applied = to a previously defined URI attribute. So, for example, if the URI for my identity as a WHOI employee was = "http://www.whoi.edu/1912/241.11" the URI for a picture of me might be = specified in the metadata associated with this URI as "s/$/.jpg/", = indicating that adding .jpg to the end of the locator URI derives a = picture of the person. Another example might be a way to define the way to express a = substitution string for receiving metadata about a timeslice of a video = that is pointed to by a locator for a scientific data object of type = "Video". If the orginal locator was http://www.whoi.edu/1912/2342.234 = there might be metadata that declares how to modify this URI to one that = specifies a start time and end time. I'm interested in finding "lessons-learned" by the IETF that it would be = worth considering in the realm of dataset identifier interoperability. = Information in the I-Ds represent hours and hours of discussion/argument = and trial in past meetings about what works and what does not work.=20 It would be a shame if we could not find some way to take advantage of = this work done in the past to help with datset identifiers and certain = types of the metadata that would sit behind them. --Andy From leifj@mnt.se Fri Aug 24 00:00:55 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1264A21F861B for ; Fri, 24 Aug 2012 00:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.024 X-Spam-Level: X-Spam-Status: No, score=-3.024 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3ixk95ARyyd for ; Fri, 24 Aug 2012 00:00:54 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id E702E21F860E for ; Fri, 24 Aug 2012 00:00:53 -0700 (PDT) Received: from [109.105.104.220] (dhcp85.se-tug.nordu.net [109.105.104.220] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q7O70lYK001130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Aug 2012 09:00:51 +0200 (CEST) Message-ID: <503726A0.7000201@mnt.se> Date: Fri, 24 Aug 2012 09:00:48 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: dsii@ietf.org X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 24 Aug 2012 07:10:40 -0700 Subject: [dsii] who is here? X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 07:00:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The "Potential IETF Work Items" thread has made me curious about who in on this list are in a position to influence or at least are affiliated with vendors, service providers or other organizations who would consume potential output from this work and who are the usual IETF suspects. Starting with me: I'm in the "usual suspect" box. Anyone care to drop their name in the "might consume results" box? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA3JqAACgkQ8Jx8FtbMZnfjGACgpxHG67PeJ8AQcyvVEEpaetXW EHMAn2eJA02Ri78TMZZnSSCm8H9evGU7 =vGE0 -----END PGP SIGNATURE----- From amaffei@whoi.edu Fri Aug 24 07:26:55 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F29021F86C5 for ; Fri, 24 Aug 2012 07:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cO3KD6t3vc+W for ; Fri, 24 Aug 2012 07:26:54 -0700 (PDT) Received: from postal1.whoi.edu (postal1-e0.whoi.edu [128.128.76.87]) by ietfa.amsl.com (Postfix) with ESMTP id C59EB21F86AA for ; Fri, 24 Aug 2012 07:26:54 -0700 (PDT) Received: by postal1.whoi.edu (Postfix, from userid 117) id C9BAC2C82A6; Fri, 24 Aug 2012 10:26:53 -0400 (EDT) Received: from dyn-128-128-91-202.whoi.edu (dyn-128-128-91-202.whoi.edu [128.128.91.202]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal1.whoi.edu (Postfix) with ESMTPSA id 88FD52C80F6; Fri, 24 Aug 2012 10:26:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Andrew Maffei In-Reply-To: <503726A0.7000201@mnt.se> Date: Fri, 24 Aug 2012 10:26:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <503726A0.7000201@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.1278) X-Virus-Status: No Cc: dsii@ietf.org Subject: Re: [dsii] who is here? X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 14:26:55 -0000 On Aug 24, 2012, at 3:00 AM, Leif Johansson wrote: > who in on this list are in a position to influence or at least are > affiliated with vendors, service providers or other organizations > who would consume potential output from this work and who are the > usual IETF suspects. Hi Leif, Andrew Maffei here.=20 I'm in the "might consume results" box you mention, but from the = academic club.=20 I (try to) coordinate, from an informatics perspective, a number of = data-intensive science projects here at the Woods Hole Oceanographic = Institution. Folks that work with me are working to make data locked = inside "the long tail of science" (apologies for the buzzword), as = linked open data that can be accessed by scientists via webservices, = etc. We have ideas and code we are developing to try and make data set = identifiers from a variety of different science projects to be more = "interoperable" so that we can better deal with inter-disciplinary = science problems (of which the ocean has several). --Andrew Maffei Senior Information Systems Specialist Woods Hole Oceanographic Institution= From scott.brim@gmail.com Fri Aug 24 07:27:29 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACB921F86CB for ; Fri, 24 Aug 2012 07:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.594 X-Spam-Level: X-Spam-Status: No, score=-103.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7NWQ1hC0iU7 for ; Fri, 24 Aug 2012 07:27:28 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFFD21F86C5 for ; Fri, 24 Aug 2012 07:27:28 -0700 (PDT) Received: by dadf8 with SMTP id f8so976006dad.31 for ; Fri, 24 Aug 2012 07:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KiDSWCAR8BEbjY5TZpHsEjML/sPRrELzi1QPHLGfeU8=; b=dE9RKXSnHCCtXFWIvrBxeKwj1y4g/cX5JoQVxPDJu2+uWtiujrr9w8nwzz8b4qM83U AyShjvfyhnE1vWww0M+am5VASOp8BcShLlN+DyPh4avRY1uKwQXVQ1in8GxFKS3jpFAw R0pwvaiLJA9ziRoxsK53E3mHmVP+yaZW9Lh9QbdQXdyAAITDgld9JX4slVm5D5LIKlHK Db2jzs9xs8IUHEt9uKiM91DRxGda2e9P2pSGavvbB8qs6FhMUqsG5sbpYibNkzFq7mJj wWy6C3savgWSh5WqnNRsyKnzHl6JAqE/8lcreI5HGtlpXCn2ZpfNctmaWtSeML/Mnvod Na5w== Received: by 10.68.239.135 with SMTP id vs7mr13353662pbc.38.1345818448196; Fri, 24 Aug 2012 07:27:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.8.97 with HTTP; Fri, 24 Aug 2012 07:27:07 -0700 (PDT) In-Reply-To: <503726A0.7000201@mnt.se> References: <503726A0.7000201@mnt.se> From: Scott Brim Date: Fri, 24 Aug 2012 10:27:07 -0400 Message-ID: To: Leif Johansson Content-Type: text/plain; charset=ISO-8859-1 Cc: dsii@ietf.org Subject: Re: [dsii] who is here? X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 14:27:29 -0000 On Fri, Aug 24, 2012 at 3:00 AM, Leif Johansson wrote: > The "Potential IETF Work Items" thread has made me curious about > who in on this list are in a position to influence or at least are > affiliated with vendors, service providers or other organizations > who would consume potential output from this work and who are the > usual IETF suspects. > > Starting with me: I'm in the "usual suspect" box. > > Anyone care to drop their name in the "might consume results" box? > > Cheers Leif here From ted.ietf@gmail.com Fri Aug 24 16:42:32 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE5721F8605 for ; Fri, 24 Aug 2012 16:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.891 X-Spam-Level: X-Spam-Status: No, score=-3.891 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhb6ragqRdIc for ; Fri, 24 Aug 2012 16:42:31 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 522DD21F85F4 for ; Fri, 24 Aug 2012 16:42:31 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so3023537vcb.31 for ; Fri, 24 Aug 2012 16:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=eaYWhwmISVo5ykkCAmpn34I8jEiVTAZCvZ5LA/ez5xE=; b=prDQrMfdn8HJUZD9dGf3JgkqzU5NsFCiAz1nk+dZepeTJWXpHuGSnFSCutTl/mZXvQ RGE+Zc2QsTglrfXOKdLwaDBEvFnqvL7JaVPvh/VjRZh3NNpc1nK8TxbJ+b2Lm5ZpM1cM YS5E6zhXB/CwMTXUl3Dv3TCTs4/tDaEWPWdL+2Ddl+M0IEtGlmxOWs1EaICsNEoebfDN chm5+Jy8unclkTa190G7da6DxEEpVwFCdLkuxJ+k4sDmpY5Xv3N9rfcZiesDmdrx0tfZ feML7g54lHESXX3pfxGOmQyolsx7+1mRVq1XDbfIsWudBesK5ottmBBXjawWwQ4/HmYw 2Hqg== MIME-Version: 1.0 Received: by 10.58.234.104 with SMTP id ud8mr6772985vec.3.1345851750687; Fri, 24 Aug 2012 16:42:30 -0700 (PDT) Received: by 10.58.228.232 with HTTP; Fri, 24 Aug 2012 16:42:30 -0700 (PDT) Date: Fri, 24 Aug 2012 16:42:30 -0700 Message-ID: From: Ted Hardie To: dsii@ietf.org Content-Type: multipart/mixed; boundary=047d7b86c7f885242e04c80b8783 Subject: [dsii] Draft minutes: please review X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 23:42:32 -0000 --047d7b86c7f885242e04c80b8783 Content-Type: text/plain; charset=ISO-8859-1 Attached are draft minutes for the BoF session at IETF 84. Please review and provide additions and corrections as needed. thanks, Ted Hardie --047d7b86c7f885242e04c80b8783 Content-Type: text/plain; charset=UTF-8; name="DSIIMinutesIETF84.txt" Content-Disposition: attachment; filename="DSIIMinutesIETF84.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h69xdpzu0 77u/RGF0YSBTZXQgSWRlbnRpZmllciBJbnRlcm9wZXJhYmxpdHkgQm9GLCBJRVRGIDg0DQpDaGFp cnM6IEJldGggUGxhbGUsIFRlZCBIYXJkaWUNCkFnZW5kYTogaHR0cDovL3d3dy5pZXRmLm9yZy9w cm9jZWVkaW5ncy84NC9hZ2VuZGEvYWdlbmRhLTg0LWRzaWkNClByZXNlbnRhdGlvbnM6IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy84NC9tYXRlcmlhbHMuaHRtbCNEU0lJDQpS ZWNvcmRpbmdzOiBodHRwOi8vd3d3LmlldGYub3JnL2F1ZGlvL2lldGY4NC9pZXRmODQtcmVnZW5j eWMtMjAxMjA3MzEtMTUyMC1wbTIubXAzICwgaHR0cDovL2Nvbm5lY3QuaXUuZWR1L3AyaG9qMmF3 enM1Lw0KTm90ZSB0YWtlcjogUm9iZXJ0IFBpbmcNCg0KDQpUZWQgSGFyZGllIHdlbGNvbWVkIHRo ZSBncm91cCBhbmQgd2VudCB0aHJvdWdoIHRoZSBOb3RlIFdlbGwgc3RhdGVtZW50IGZvciB0aGUg SUVURiwgcmVpdGVyYXRpbmcgdGhhdCB0aGlzIEJvRiB3YXMgbm90IGludGVuZGVkIHRvIGZvcm0g YSB3b3JraW5nIGdyb3VwLg0KDQoNCkJldGggUGxhbGUgdGhlbiByZXZpZXcgdGhlIGNvbmNlcHR1 YWwgZnJhbWV3b3JrIGZvciB3b3JrIGluIHRoaXMgYXJlYSwgZGlzY3Vzc2luZyBib3RoIHRoZSBm cmFtZXdvcmsgZm9yIHNjaWVudGlmaWMgZGF0YSBzZXRzIGFuZCB0aGUga2V5IHJvbGUgcGxheWVk IGJ5IGFzc29jaWF0aW5nIG1ldGFkYXRhIHdpdGggdGhlIGdlbmVyYXRlZCBkYXRhLiAgQ29yZSBp c3N1ZXMgZm9yIGRhdGEgc2V0cyBhbmQgdGhlaXIgaWRlbnRpZmllcnMgYXJlOiBkaXNjb3Zlcnks IGRhdGEgYWNjZXNzLCBhY2Nlc3MgY29udHJvbCwgbG9naWNhbCBhcnJhbmdlbWVudCwgZ292ZXJu YW5jZSwgZGlzdHJpYnV0aW9uIG1vZGVscywgY29zdHMsIHJlbGF0aW9uc2hpcCBpbnRlcm9wZXJh YmlsaXR5IGFuZCBzZXJ2aWNlIGludGVyb3BlcmFiaWxpdHkuICBUaGUgaXNzdWVzIHJhaXNlZCBh cmUgcGFydGljdWxhcmx5IHByb2JsZW1hdGljIGZvciBsb25nLXRhaWwgZGF0YSwgd2hlcmUgdGhl IGF2YWlsYWJsZSBmdW5kcyBhbmQgZWZmb3J0IGF2YWlsYWJsZSB0byBjdXJhdGUgdGhlIGRhdGEg bWF5IGJlIGxvdy4NCg0KDQoNCg0KIFRoZSBncm91cCB0aGVuIHJldmlld2VkIHNldmVyYWwgY3Vy cmVudCBEYXRhIFNldCBJRCBTeXN0ZW1zIChwbGVhc2Ugc2VlIHNsaWRlcykgLSANCg0KDQogICAg ICBFWklEIC0gSmFuZWUNCiAgICAgIEhhbmRsZSBTeXN0ZW0gLSBMYW5ub20NCiAgICAgIEVQSUMg LSBXaXR0ZW5iZXJnIC0gQ0xBUklOIC0gRVVEQVQNCiAgICAgIE5JIFVSSSBzY2hlbWUgLSBGYXJy ZWxsDQoNCg0KIERpc2N1c3Npb24gb2YgY3VycmVudCBzeXN0ZW1zIC0gUGxhbGUNCg0KDQogUXVl c3Rpb24gb2YgRGF0YSBhbmQgRGF0YSBTaGFyaW5nIGluIHRlcm1zIG9mIEVhcnRoIFNjaWVuY2Vz IGFyZWFzOiBhZG9wdGlvbnMgb2YgRE9JcyBpcyBjb21tb24sIGJ1dCBvdGhlcnMgYXJlIGNyZWF0 aW5nIHRoZWlyIG93biBvciB3aW5naW5nIGl0LiBCZWluZyBhYmxlIHRvIGRvIGRpc2NvdmVyeSBv biB0b3Agb2YgdGhpcyB3aWxsIHRha2Ugc29tZSBhZ3JlZW1lbnQuICBLZXkgcXVlc3Rpb24gaXM6 ICAgQXJlIHdlIGF0IGEgcGFpbiBwb2ludCB3aGVyZSB3ZSBjYW4gZ2V0IHNvbWUgYWdyZWVtZW50 PyAgU2hvdWxkIHdlIGdldCBhZ3JlZW1lbnQgb24gaW5mb3JtYXRpb24gdHlwZXMgYW5kIHVzZSB0 aGF0IHRvIGNyZWF0ZSBsYXJnZXIgcGxhdGZvcm0/ICBEbyB3ZSBuZWVkIHNvbWV0aGluZyBsaWtl IHRoZSBJRVRGIHRvIGdldCB0aGlzIGdvaW5nPyAgSG93IGRvIHdlIGNvbGxhYm9yYXRlPw0KQWxz byBub3RlIHRoYXQgdGhlcmUgYXJlIGNvbW1lcmNpYWwgdXNlcyAtIGNyZWF0ZSBhIGNvbGxlY3Rp b24gdG8gc3RyZWFtIGZyb20gYSBjYWNoZSBvbg0KIHRoZSBuZXR3b3JrIC0gaW5jbHVkZSBhdWRp by92aWRlby9jbG9zZSBjYXB0aW9uaW5nL2FkcyAtIGVhY2ggcG90ZW50aWFsbHkgd2l0aCBkaWZm ZXJlbnQgZGF0YSBpZGVudGlmaWVyIHR5cGVzLiAgV2UgZG9uJ3Qgd2FudCB0byBkbyB0aGlzIG1h bnVhbGx5Lg0KDQoNCiAgICAgICAgICAgU2NvdHQgQnJhZG5lciAtIEFkZGVkIGFzIGNvbW1lbnQg LSBEaXNjdXNzaW9uIHRoaXMgc2hvdWxkIGluY2x1ZGUgIGxvY2FsaXphdGlvbiAtIEkgd2FudCB0 byBnZXQgY29weSB0aGF0IGlzIGNvcnJlY3QgZm9yIG1lIC0gaGFydmFyZCBtYXkgaGF2ZSBsb2Nh bCBjb3B5IC0gbmVlZCB0aGF0IGNvcHkgdnMgSVUgY29weS4gIFRoYXTigJlzIGEgIHByZXR0eSBw b3dlcmZ1bCBhc3BlY3Qgb2YgdGhpcy4gDQoNCg0KICAgICAgICAgICBMZWlmIEpvaGFubnNvbiAt IEFub3RoZXIgcG9pbnQgLSBzbyB3aGF0IGlzIHRoZSBlbmQgZ2FtZSBsb29rIGxpa2UNCiBmb3Ig c3VjY2VzIGZvciB0aGlzPyBEbyB3ZSBwaWNrIGEgd2lubmVyIG9yIGRvZXMgaXQgcmVtYWluICBh IGxpdHRsZSBvZiB0aGlzIGFuZCBhIGxpdHRsZQ0KIG9mIHRoYXQgPyAoQ2hhaXJzIHJlcGx5IHRo YXQgdGhpcyBpcyBub3Qg4oCccGljayBhIHdpbm5lcuKAnSkuDQoNCg0KICAgICAgICAgICBKb2hu IExldmluZSAtIGVtYWlsIGFuZCBtYWx3YXJlIHVzZSBtYW5hZ2VtZW50IGlzIGEgcG90ZW50aWFs IHVzZSBjYXNlOyB0aGV5IGtlZXAgbGFyZ2UgZmlsZXMgIG9mIHNwYW0gKGhlIGFsc28gYXNrZWQg YSBxdWVzdGlvbiBhYm91dCBET0lzIHJlc29sdmluZyB0byBhIGRvY3VtZW50KQ0KDQoNCiAgICAg ICAgICAgTWVsaW5kYSBTaG9yZSAtIEFyZSB3ZSB0YWxraW5nIGFib3V0IHN0YW5kYXJkaXppbmcg bWV0YWRhdGEgb3INCiBzZWFyY2ggaW50ZXJmYWNlcz8gTm90IHN1cmUgd2hhdCBpcyBiZWluZyBh c2tlZCBpbiB0aGlzIGRpc2N1c3Npb24gLSBob3cNCiBkb2VzIElFVEYgZml0IGludG8gdGhpcz8g LSB3aGF0IHBhcnQgb2Ygc3F1aXNoeSB3aG9sZSBjb3VsZCBoYXZlIHRoaW5ncyB0byBiZQ0KIGRv bmUgcmlnaHQgbm93IC0gbWFwcGluZ3MgYmV0d2VlbiBleGlzdGluZyBzeXN0ZW1zIC0gbm90IGRl Zm5pdGl2ZSBtZXRhZGF0YQ0KIHNldCBidXQgYSB3YXkgdG8gbWFwIHRoZW0gdG9nZXRoZXIgd2l0 aCBzb21lIGtpbmQgb2YgcmVnaXN0cnkgLSBpcyBhDQogcmVnaXN0cnkgb2YgdGhvc2UgdGhpbmdz IGEgbWluaW1hbCBzdWNjZXNzIHN0b3J5IC0gd2hhdCBvdGhlciBkaXNjb3Zlcnkgb3INCiBpbmRp cmVjdGlvbiB3b3VsZCB0aGVuIGJlIHBvc3NpYmxlPw0KDQoNCiAgICAgICAgICAgU2luZ2xlIGNv bW1lbnQgLU5lZWQgdG8gZ2V0IHZlcnkgc3BlY2lmaWMgYWJvdXQgIHZvY2FidWxhcnkgb24gdGhp cyBpc3N1ZS4NCg0KDQogICAgICAgICAgIEFuZHkgQnVmZmV0IC0gV29vZHMgSG9sZSAtIGNsZWFy bHkgaWRlbnRpZmllZCBhcyBpbnRlcm9wIHByb2JsZW0sIGFuZCB3ZSBoYXZlIHRlY2huaXF1ZXMv IGFwcHJvYWNoZXMgZm9yIGludGVyb3AuICBXZSBjYW4gdGhhdCBhZGQgaW50byB0aGUgd29yayB0 aGF0IGhhcyBiZWVuIGdvaW5nIG9uIHNvbWUgdGltZSBpbiB0aGUgc2NpZW5jZXMuICBUaGVyZSBp cyBhIGxpbWl0ZWQgbnVtYmVyIG9mIHBpZCBzY2hlbWNlcyBmb3IgIGRhdGFzZXRzIC0gYW4gYXBp IGZvciBkYXRhc2V0IGlkZW50aWZpZXJzLCBhcyBlemlkIGFscmVhZHkgaGFzLCBpcyB1c2VmdWwu ICBXaGVuIGl0IGJlY29tZXMgZG9tYWluIHNwZWNpZmljIHRoZXJlIGlzIGxvdHMgdG8gYmUgZG9u ZS4gDQoNCg0KICAgICAgQ29tbWVudHMgZnJvbSBOYXNzZWVkIFVzYXIgLSBVTkMgQ2hhcGVsLUhp bGwNCg0KDQogSW50ZXJvcGVyYWJpbGl0eSBjb25zaWRlcmF0aW9ucyAtIEhhcmRpZQ0KDQoNClRo ZSBncm91cCBkaXNjdXNzZWQgaW50ZXJvcGVyYWJpbGl0eSBtZWNoYW5pc21zIGJyaWVmbHkuICBU aGUgY2hhaXJzIGNvbmNsdWRlZCBieSB0aGFua2luZyB0aGUgZ3JvdXAgZm9yIHRoZSBkYXlzIGRp c2N1c3Npb24gYW5kIGFza2VkIGZvbGtzIHRvIGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIG9uIHRo ZSBsaXN0Lg== --047d7b86c7f885242e04c80b8783-- From scott.brim@gmail.com Sat Aug 25 13:13:16 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA46621F84F9 for ; Sat, 25 Aug 2012 13:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.594 X-Spam-Level: X-Spam-Status: No, score=-103.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RqI7ixRD1p8 for ; Sat, 25 Aug 2012 13:13:16 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAC121F8501 for ; Sat, 25 Aug 2012 13:13:16 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so5231832pbb.31 for ; Sat, 25 Aug 2012 13:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qSfhdP3VO5ZmS04HzQDZIuJ9JcynFV/AWkr/1pkxNio=; b=y4DVUGID0E5nuj0YZ2Bmroh9NdO/CfrD8s9lmjdEhkA7BMMVvKCRT3rwGJ0q+C7DgK ESH6fm7ksalcHUrpGw29Ixru/QtK9lsqf5xyXMXmI7D0ZEnF/yjCFnf8MvrPQfWzNxE0 PxPr9WxrdMeDBKh8qjt6LVMZP3SUjVmCIj+cEndPGksg5L6Ja44AuU+ZP4b7Lj3/a3rd hYiQ37iUyzNrskG8yxbT7B93vTOs4IePGyi6ZXmdAwBX+FxGUIfpvMI3Jsp1GT7pa+Nu VKY2cT1Q8VHW4SIGBw2c4/TXt9p3rcEwq7kCOqWxeFHQUv2VuoLmReDWiwz/A7tbGKaK KEaQ== Received: by 10.68.224.70 with SMTP id ra6mr22661231pbc.11.1345925595800; Sat, 25 Aug 2012 13:13:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.8.97 with HTTP; Sat, 25 Aug 2012 13:12:55 -0700 (PDT) In-Reply-To: References: From: Scott Brim Date: Sat, 25 Aug 2012 16:12:55 -0400 Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=047d7b16051f0823e604c81cb960 Cc: dsii@ietf.org Subject: Re: [dsii] Draft minutes: please review X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 20:13:16 -0000 --047d7b16051f0823e604c81cb960 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 24, 2012 at 7:42 PM, Ted Hardie wrote: > Attached are draft minutes for the BoF session at IETF 84. Please > review and provide additions and corrections as needed. > "Andy Buffet - Woods Hole" -> Maffei --047d7b16051f0823e604c81cb960 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Aug 24, 2012 at 7:42 PM, Ted Hardie <ted.ietf@gmail.com>= wrote:
Attached are draft minutes for the BoF session at IETF 84. =A0Please
review and provide additions and corrections as needed.

"Andy Buffet - W= oods Hole" -> Maffei

=A0
--047d7b16051f0823e604c81cb960-- From plale@cs.indiana.edu Sun Aug 26 16:41:46 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5635B21F85A1 for ; Sun, 26 Aug 2012 16:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpEeOX9akY+9 for ; Sun, 26 Aug 2012 16:41:45 -0700 (PDT) Received: from newman.cs.indiana.edu (newman.cs.indiana.edu [129.79.247.4]) by ietfa.amsl.com (Postfix) with ESMTP id D38CF21F8489 for ; Sun, 26 Aug 2012 16:41:44 -0700 (PDT) Received: from smtp.cs.indiana.edu (smtp.cs.indiana.edu [129.79.247.7]) by newman.cs.indiana.edu (8.13.8/8.13.8/IUCS_2.97) with ESMTP id q7QNfgaf017533; Sun, 26 Aug 2012 19:41:43 -0400 Received: from [10.0.0.2] (c-71-194-153-96.hsd1.in.comcast.net [71.194.153.96]) (authenticated bits=0) by rage.cs.indiana.edu (8.13.1/8.13.1/IUCS_SMTP_Alternate_Port_1.5) with ESMTP id q7QNfZqf014588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 26 Aug 2012 19:41:42 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_780BE779-54D3-4676-B7B0-2AC7AB44F27E" From: Beth Plale In-Reply-To: <6D125452-6D45-473A-A1B0-5DF461B80D3D@whoi.edu> Date: Sun, 26 Aug 2012 19:41:33 -0400 Message-Id: References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> <502BC103.4040107@nomountain.net> <503290C2.7060608@nomountain.net> <6D125452-6D45-473A-A1B0-5DF461B80D3D@whoi.edu> To: dsii@ietf.org X-Mailer: Apple Mail (2.1278) Cc: Beth Plale Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 23:41:46 -0000 --Apple-Mail=_780BE779-54D3-4676-B7B0-2AC7AB44F27E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is an important conversation. The issues with data identification = are surfacing in science because science data is at multiple levels of = granularity (e.g., national, state, metro area, street) and giving = proper credit to data creators is of burgeoning important in the = sciences. Commercial video can have issues of granularity but once = copyright issues are resolved, ownership is clear. The issue of = ownership/attribution is driving the urgency to come up with solutions = to the data set identifier problem. I see interoperability across ID schemes as something that IETF can help = us think about and propose a solution to. We're not going to accomplish = much by trying to mandate a single ID scheme, not with several already = in existence and with good adoption. Ted and Andrew identified this = problem as well. I wished we'd had more time to discuss = interoperability at the BOF. =20 I like the connections Andrew made to work going on in other IETF = groups. That shows hope that there's existing expertise from which we = can draw. I see this topic as cloud-agnostic. Clouds are heavily researched and = used in academia; identifiers would describe data sets wherever they = "live", and clouds are likely to be or already heavily used for = replication (caching).=20 The library folks bring a lot to the table, but are a subset of those = interested in this topic. Leif's remark libraries are increasingly = operated by content providers (who are at IETF) is a strong tie.=20 Finally, Andrew's suggested 3 options for engagement (copied below) are = very good. =20 On Aug 14, 2012, at 12:35 PM, Andrew Maffei wrote: >=20 > Three options for engagement seem worthwhile considering: >=20 > 1. More dsii-interested folks currently outside IETF could start = participating > in WGs w cross-cutting interests, once they are identified. >=20 > 2. More IETF'ers could be engaged to participate in current dsii > initiatives outside the IETF and be offered a platform from which > an IETF perspective can be heard. ("Big Data" seems to be getting > big these days for better or worse). >=20 > 3. A dsii working-group might someday be formed within IETF. >=20 > I think that the first 2 options are pre-requisites for the 3rd so > that we can gain familiarity with each others use-cases and cultures > and thus lower the risk of a "bad start". As I have gotten older I > have learned how important "good starts" are to initiatives. best beth : Beth Plale : Director, Data to Insight Center : Professor of Computer Science : Indiana University Bloomington : Beth Plale : Director, Data to Insight Center : Professor of Computer Science : Indiana University Bloomington On Aug 22, 2012, at 10:08 AM, Andrew Maffei wrote: > On Aug 20, 2012, at 3:32 PM, Melinda Shore wrote: >=20 >> I'm still trying to figure out what's being proposed here and I >> realized that my mental model might be considerably different from >> that being used by the work's proponents. Where I'm coming from, >> someone who needs a chunk of data and isn't sure where it is (or, >> in some cases, whether or not it exists) does a search, and the >> search returns a set of stuff, where "stuff" includes descriptive >> information (metadata) and an identifier that's actually a >> locator. The locator is used to access the data. >>=20 >> Is that consistent with what proponents have in mind? >=20 > Hi Melinda. >=20 > The above is the primary use case. I think the "stuff" is all metadata = (attribute/value pairs about the dataset) that includes the "locator" = you mention.=20 >=20 > I'd like to comment on some of the things I saw of value at the = Vancouver meeting. I don't claim to be an identifier or metadata expert = so perhaps some of these ideas were derived outside of IETF. But they = were new to me. >=20 > One idea would be to consider working together to agree on the "core = metadata" that would be returned about scientific datasets for data = object access and delivery, etc. >=20 > One of the more interesting IETF WG docs I found was the CDN = Interconnet Metadata i-d (draft-cjlmw-cdni-metadata-00). The sections on = ACLs, ACLRules, Delivery seemed directly applicable to delivery of = science datasets, some of which are proprietary and some of which are = not. There are all sorts of issues related to delivery of proprietary = scientific data and very large datasets (or their subsets) that seem = applicable. >=20 > I noticed in another I-D (can't find it right now) the practice of = allowing attribute values of type "URI" being either an explicit, fully = qualified URI *or* a regular-expression substitution that can be applied = to a previously defined URI attribute. >=20 > So, for example, if the URI for my identity as a WHOI employee was = "http://www.whoi.edu/1912/241.11" the URI for a picture of me might be = specified in the metadata associated with this URI as "s/$/.jpg/", = indicating that adding .jpg to the end of the locator URI derives a = picture of the person. >=20 > Another example might be a way to define the way to express a = substitution string for receiving metadata about a timeslice of a video = that is pointed to by a locator for a scientific data object of type = "Video". If the orginal locator was http://www.whoi.edu/1912/2342.234 = there might be metadata that declares how to modify this URI to one that = specifies a start time and end time. >=20 > I'm interested in finding "lessons-learned" by the IETF that it would = be worth considering in the realm of dataset identifier = interoperability. Information in the I-Ds represent hours and hours of = discussion/argument and trial in past meetings about what works and what = does not work.=20 >=20 > It would be a shame if we could not find some way to take advantage of = this work done in the past to help with datset identifiers and certain = types of the metadata that would sit behind them. >=20 > --Andy >=20 > _______________________________________________ > dsii mailing list > dsii@ietf.org > https://www.ietf.org/mailman/listinfo/dsii --Apple-Mail=_780BE779-54D3-4676-B7B0-2AC7AB44F27E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The library folks bring a lot = to the table, but are a subset of those interested in this topic. =  Leif's remark  libraries are increasingly operated = by content providers (who are at IETF) is a strong = tie. 

Finally, Andrew's suggested 3 = options for engagement (copied below) are very good. =  


On Aug 14, 2012, at 12:35 = PM, Andrew Maffei wrote:

Three options for = engagement seem worthwhile considering:

1. More dsii-interested = folks currently outside IETF could start participating
in WGs w = cross-cutting interests, once they are identified.

2. More = IETF'ers could be engaged to participate in current dsii
initiatives = outside the IETF and be offered a platform from which
an IETF = perspective can be heard. ("Big Data" seems to be getting
big these = days for better or worse).

3. A dsii working-group might someday = be formed within IETF.

I think that the first 2 options are = pre-requisites for the 3rd so
that we can gain familiarity with each = others use-cases and cultures
and thus lower the risk of a "bad = start". As I have gotten older I
have learned how important "good = starts" are to = initiatives.

best

beth

: Beth Plale
: Director, Data to Insight = Center
: Professor of Computer Science
: Indiana University = Bloomington


<= /div>
: Beth Plale
: Director, Data to Insight = Center
: Professor of Computer Science
: Indiana University = Bloomington












On Aug 22, 2012, at 10:08 AM, Andrew Maffei = wrote:

On Aug 20, 2012, at 3:32 PM, Melinda Shore = wrote:

I'm still trying to figure out = what's being proposed here and I
realized that my mental model might be considerably = different from
that being used = by the work's proponents.  Where I'm coming = from,
someone who needs a = chunk of data and isn't sure where it is = (or,
in some cases, whether or = not it exists) does a search, and the
search returns a set of stuff, where "stuff" includes = descriptive
information = (metadata) and an identifier that's actually = a
locator.  The locator = is used to access the data.

Is that = consistent with what proponents have in mind?

Hi = Melinda.

The above is the primary use case. I think the "stuff" = is all metadata (attribute/value pairs about the dataset) that includes = the "locator" you mention.

I'd like to comment on some of the = things I saw of value at the Vancouver meeting. I don't claim to be an = identifier or metadata expert so perhaps some of these ideas were = derived outside of IETF. But they were new to me.

One idea would = be to consider working together to agree on the "core metadata" that = would be returned about scientific datasets for data object access and = delivery, etc.

One of the more interesting IETF WG docs I found = was the CDN Interconnet Metadata i-d (draft-cjlmw-cdni-metadata-00). The = sections on ACLs, ACLRules, Delivery seemed directly applicable to = delivery of science datasets, some of which are proprietary and some of = which are not. There are all sorts of issues related to delivery of = proprietary scientific data and very large datasets (or their subsets) = that seem applicable.

I noticed in another I-D (can't find it = right now) the practice of allowing attribute values of type "URI" being = either an explicit, fully qualified URI *or* a regular-expression = substitution that can be applied to a previously defined URI = attribute.

So, for example, if the URI for my identity as a WHOI = employee was "http://www.whoi.edu/1912/241.11" the URI for a picture of me might be specified in the metadata = associated with this URI as "s/$/.jpg/", indicating that adding .jpg to = the end of the locator URI derives a picture of the = person.

Another example might be a way to define the way to = express a substitution string for receiving metadata about a timeslice = of a video that is pointed to by a locator for a scientific data object = of type "Video". If the orginal locator was http://www.whoi.edu/1912/2342.2= 34 there might be metadata that declares how to modify this URI to = one that specifies a start time and end time.

I'm interested in = finding "lessons-learned" by the IETF that it would be worth considering = in the realm of dataset identifier interoperability. Information in the = I-Ds represent hours and hours of discussion/argument and trial in past = meetings about what works and what does not work.

It would be a = shame if we could not find some way to take advantage of this work done = in the past to help with datset identifiers and certain types of the = metadata that would sit behind = them.

--Andy

_______________________________________________=
dsii mailing list
dsii@ietf.org
https://www.ietf.org/ma= ilman/listinfo/dsii

= --Apple-Mail=_780BE779-54D3-4676-B7B0-2AC7AB44F27E-- From melinda.shore@nomountain.net Sun Aug 26 22:22:07 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1D221F8600 for ; Sun, 26 Aug 2012 22:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+X8srM+-+S1 for ; Sun, 26 Aug 2012 22:22:06 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id DD2D621F85F7 for ; Sun, 26 Aug 2012 22:22:06 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 2584C508072 for ; Sun, 26 Aug 2012 22:22:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=nomountain.net; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=nomountain.net ; b=JIv+4b0HKJsxWI4WHNyJgzY/SbCNfVj1xI/mOtQd/kcMFaM6Ake0Zx66n6uH KEepiGwfU4iQgZCuxhxcrmfTNcndmLRlSSrJ877OjcfL3STrtxSskZrcLe5ohVtl r5GYmOtFrPGfbydxYoDO/0BwCv1WljUpCTwVy0a47j6pc+c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nomountain.net; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= nomountain.net; bh=02n6AsmQEuPNFwk87CBtta/qX0w=; b=t02RB8GLR3YZH vSOSvFP5P6At10xhbW9MOp94Xk9HS2q42FmPL2fax5xKavJTU+n0/g3YcgwDBwOG HfUovkvKsFL2U0P47Wgd5zQatlRRdxM4kyL186nvrRdKpG7Jj3bRo+2qhi2/wa32 mqh2vVHv34A5SkwZrCAYvh0MtISk9Q= Received: from spandex.local (66-230-80-245-rb1.fai.dsl.dynamic.acsalaska.net [66.230.80.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: melinda.shore@nomountain.net) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id D07AB508089 for ; Sun, 26 Aug 2012 22:22:05 -0700 (PDT) Message-ID: <503B03FC.1040903@nomountain.net> Date: Sun, 26 Aug 2012 21:22:04 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: dsii@ietf.org References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> <502BC103.4040107@nomountain.net> <503290C2.7060608@nomountain.net> <6D125452-6D45-473A-A1B0-5DF461B80D3D@whoi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 05:22:07 -0000 On 8/26/12 3:41 PM, Beth Plale wrote: > I see interoperability across ID schemes as something that IETF can help > us think about and propose a solution to. I'm still having some difficulty getting a handle on the scenario(s), here - are you anticipating something along the lines of a unified "catalog?" Melinda -- Melinda Shore No Mountain Software melinda.shore@nomountain.com "Software longa, hardware brevis." From dgq2011@gmail.com Sun Aug 26 23:30:12 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3813921F854B for ; Sun, 26 Aug 2012 23:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=1.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3I9Hgjc4nJq for ; Sun, 26 Aug 2012 23:30:10 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9235721F8472 for ; Sun, 26 Aug 2012 23:30:10 -0700 (PDT) Received: by iabz21 with SMTP id z21so8437914iab.31 for ; Sun, 26 Aug 2012 23:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eg3FvzBnCM8uFfQiVDK5A9SWfQPMaKogy0m0lF5+Cus=; b=Hoq7GXFSGpAf5CbfT81A/zpDTUzXsZWuS9163ZpAjyaN553sqBdQRU8zVmr/rwuS04 UoFwBd0v3NFTzFkW8eM2OVf2o9P14lRqO4vRbYSo63DRGaGn81+WoTOTdtQa5JzSzAaK gY4C2QEEKc6PzH4vHuCT5j+wCwfCkWhukf89tir+3AW1AfHA/qr7TRssbhwU6Fhs2UXF 7kgJsF8Kitcqk51Pq4kKm9iVDuV2cKX3u5/KUaCZNW17FZTnnWTr4ZHwi4VqOohx0PBP AYWOMyPtZgE2bj6blgC9UHynd5DMh8zcdAj/JLa867t6UhNYsclKHdSFnKUzL/WadZ1j DDHw== MIME-Version: 1.0 Received: by 10.50.209.99 with SMTP id ml3mr9211031igc.31.1346049010011; Sun, 26 Aug 2012 23:30:10 -0700 (PDT) Received: by 10.64.52.68 with HTTP; Sun, 26 Aug 2012 23:30:09 -0700 (PDT) In-Reply-To: References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> <502BC103.4040107@nomountain.net> <503290C2.7060608@nomountain.net> <6D125452-6D45-473A-A1B0-5DF461B80D3D@whoi.edu> Date: Mon, 27 Aug 2012 14:30:09 +0800 Message-ID: From: Guangqing Deng To: Beth Plale Content-Type: multipart/alternative; boundary=14dae9340a93178d5b04c83975ec Cc: dsii@ietf.org Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 06:30:12 -0000 --14dae9340a93178d5b04c83975ec Content-Type: text/plain; charset=ISO-8859-1 2012/8/27 Beth Plale > This is an important conversation. The issues with data identification > are surfacing in science because science data is at multiple levels of > granularity (e.g., national, state, metro area, street) and giving proper > credit to data creators is of burgeoning important in the sciences. > Commercial video can have issues of granularity but once copyright issues > are resolved, ownership is clear. The issue of ownership/attribution is > driving the urgency to come up with solutions to the data set identifier > problem. > > I see interoperability across ID schemes as something that IETF can help > us think about and propose a solution to. We're not going to accomplish > much by trying to mandate a single ID scheme, not with several already in > existence and with good adoption. Ted and Andrew identified this problem > as well. I wished we'd had more time to discuss interoperability at the > BOF. > > I like the connections Andrew made to work going on in other IETF groups. > That shows hope that there's existing expertise from which we can draw. > > I see this topic as cloud-agnostic. Clouds are heavily researched and > used in academia; identifiers would describe data sets wherever they > "live", and clouds are likely to be or already heavily used for replication > (caching). > BTW, Cloud also is widely applied in the industry. > The library folks bring a lot to the table, but are a subset of those > interested in this topic. Leif's remark libraries are increasingly > operated by content providers (who are at IETF) is a strong tie. > > Finally, Andrew's suggested 3 options for engagement (copied below) are > very good. > > > On Aug 14, 2012, at 12:35 PM, Andrew Maffei wrote: > > > Three options for engagement seem worthwhile considering: > > 1. More dsii-interested folks currently outside IETF could start > participating > in WGs w cross-cutting interests, once they are identified. > > 2. More IETF'ers could be engaged to participate in current dsii > initiatives outside the IETF and be offered a platform from which > an IETF perspective can be heard. ("Big Data" seems to be getting > big these days for better or worse). > > 3. A dsii working-group might someday be formed within IETF. > > I think that the first 2 options are pre-requisites for the 3rd so > that we can gain familiarity with each others use-cases and cultures > and thus lower the risk of a "bad start". As I have gotten older I > have learned how important "good starts" are to initiatives. > > > best > > beth > > : Beth Plale > : Director, Data to Insight Center > : Professor of Computer Science > : Indiana University Bloomington > > > : Beth Plale > : Director, Data to Insight Center > : Professor of Computer Science > : Indiana University Bloomington > > > > > > > > > > > > > On Aug 22, 2012, at 10:08 AM, Andrew Maffei wrote: > > On Aug 20, 2012, at 3:32 PM, Melinda Shore wrote: > > I'm still trying to figure out what's being proposed here and I > > realized that my mental model might be considerably different from > > that being used by the work's proponents. Where I'm coming from, > > someone who needs a chunk of data and isn't sure where it is (or, > > in some cases, whether or not it exists) does a search, and the > > search returns a set of stuff, where "stuff" includes descriptive > > information (metadata) and an identifier that's actually a > > locator. The locator is used to access the data. > > > Is that consistent with what proponents have in mind? > > > Hi Melinda. > > The above is the primary use case. I think the "stuff" is all metadata > (attribute/value pairs about the dataset) that includes the "locator" you > mention. > > I'd like to comment on some of the things I saw of value at the Vancouver > meeting. I don't claim to be an identifier or metadata expert so perhaps > some of these ideas were derived outside of IETF. But they were new to me. > > One idea would be to consider working together to agree on the "core > metadata" that would be returned about scientific datasets for data object > access and delivery, etc. > > One of the more interesting IETF WG docs I found was the CDN Interconnet > Metadata i-d (draft-cjlmw-cdni-metadata-00). The sections on ACLs, > ACLRules, Delivery seemed directly applicable to delivery of science > datasets, some of which are proprietary and some of which are not. There > are all sorts of issues related to delivery of proprietary scientific data > and very large datasets (or their subsets) that seem applicable. > > I noticed in another I-D (can't find it right now) the practice of > allowing attribute values of type "URI" being either an explicit, fully > qualified URI *or* a regular-expression substitution that can be applied to > a previously defined URI attribute. > > So, for example, if the URI for my identity as a WHOI employee was " > http://www.whoi.edu/1912/241.11" the URI for a picture of me might be > specified in the metadata associated with this URI as "s/$/.jpg/", > indicating that adding .jpg to the end of the locator URI derives a picture > of the person. > > Another example might be a way to define the way to express a substitution > string for receiving metadata about a timeslice of a video that is pointed > to by a locator for a scientific data object of type "Video". If the > orginal locator was http://www.whoi.edu/1912/2342.234 there might be > metadata that declares how to modify this URI to one that specifies a start > time and end time. > > I'm interested in finding "lessons-learned" by the IETF that it would be > worth considering in the realm of dataset identifier interoperability. > Information in the I-Ds represent hours and hours of discussion/argument > and trial in past meetings about what works and what does not work. > > It would be a shame if we could not find some way to take advantage of > this work done in the past to help with datset identifiers and certain > types of the metadata that would sit behind them. > > --Andy > > _______________________________________________ > dsii mailing list > dsii@ietf.org > https://www.ietf.org/mailman/listinfo/dsii > > > > _______________________________________________ > dsii mailing list > dsii@ietf.org > https://www.ietf.org/mailman/listinfo/dsii > > -- Guangqing Deng --14dae9340a93178d5b04c83975ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/8/27 Beth Plale &= lt;plale@cs.india= na.edu>
This is an important conversation.= =A0The issues with data identification are surfacing in science because sc= ience data is at multiple levels of granularity (e.g., national, state, met= ro area, street) and giving proper credit to data creators is of burgeoning= important in the sciences. =A0 =A0Commercial video can have issues of gran= ularity but once copyright issues are resolved, ownership is clear. =A0 The= issue of ownership/attribution is driving the urgency to come up with solu= tions to the data set identifier problem.

I see interoperability across ID schemes as something t= hat IETF can help us think about and propose a solution to. =A0We're no= t going to accomplish much by trying to mandate a single ID scheme, not wit= h several already in existence and with good adoption. =A0Ted and Andrew id= entified this problem as well. =A0 I wished we'd had more time to discu= ss interoperability at the BOF. =A0

I like the connections Andrew made to work going on in = other IETF groups. =A0That shows hope that there's existing expertise f= rom which we can draw.

I see this topic as cloud-a= gnostic. =A0Clouds are heavily researched and used in academia; identifiers= would describe data sets wherever they "live", and clouds are li= kely to be or already heavily used for replication (caching).=A0
=A0
BTW, Cloud also is widely applied in = the industry.


The library folks bring a lot to the table, but are a s= ubset of those interested in this topic. =A0Leif's remark=A0=A0librarie= s are increasingly operated by=A0content providers (who are at IETF) is a s= trong tie.=A0

Finally, Andrew's suggested 3 options for engagemen= t (copied below) are very good. =A0

<= div>
On Aug 14, 2012, at 12:35 PM, Andrew Maffei wrote:
<= div>

=
Three options for engagement seem worthwhile considering:

1. M= ore dsii-interested folks currently outside IETF could start participating<= br> in WGs w cross-cutting interests, once they are identified.

2. More = IETF'ers could be engaged to participate in current dsii
initiatives= outside the IETF and be offered a platform from which
an IETF perspecti= ve can be heard. ("Big Data" seems to be getting
big these days for better or worse).

3. A dsii working-group might s= omeday be formed within IETF.

I think that the first 2 options are p= re-requisites for the 3rd so
that we can gain familiarity with each othe= rs use-cases and cultures
and thus lower the risk of a "bad start". As I have gotten older = I
have learned how important "good starts" are to initiatives.=

best

beth

<= span style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;fon= t-style:normal;font-weight:normal;line-height:normal;border-collapse:separa= te;text-transform:none;font-size:medium;white-space:normal;font-family:Helv= etica;word-spacing:0px">
: Beth Plale
: Director, Data to Insight Center
: Professor of Comput= er Science
: Indiana University Bloomington
<= div style=3D"word-wrap:break-word">
: Beth Plale
: Director, Data to Insight Center
: Professor of Comput= er Science
: Indiana University Bloomington










=

On Aug 22, 2012, at 10:08 AM, Andrew Maffei wrote:

<= blockquote type=3D"cite">
On Aug 20, 2012, at 3:32 PM, Melinda Shore wr= ote:

I'm still trying to figure out wh= at's being proposed here and I
realized that my mental model might = be considerably different from
th= at being used by the work's proponents. =A0Where I'm coming from,
someone who needs a chunk of data an= d isn't sure where it is (or,
in some cases, whether or not it exists) does a search, and the
search returns a set of stuff, where "stuff&= quot; includes descriptive
inform= ation (metadata) and an identifier that's actually a
locator. =A0The locator is used to access the data.

Is that consi= stent with what proponents have in mind?

Hi Melinda.
The above is the primary use case. I think the "stuff" is all met= adata (attribute/value pairs about the dataset) that includes the "loc= ator" you mention.

I'd like to comment on some of the thin= gs I saw of value at the Vancouver meeting. I don't claim to be an iden= tifier or metadata expert so perhaps some of these ideas were derived outsi= de of IETF. But they were new to me.

One idea would be to consider working together to agree on the "co= re metadata" that would be returned about scientific datasets for data= object access and delivery, etc.

One of the more interesting IETF W= G docs I found was the CDN Interconnet Metadata i-d (draft-cjlmw-cdni-metad= ata-00). The sections on ACLs, ACLRules, Delivery seemed directly applicabl= e to delivery of science datasets, some of which are proprietary and some o= f which are not. There are all sorts of issues related to delivery of propr= ietary scientific data and very large datasets (or their subsets) that seem= applicable.

I noticed in another I-D (can't find it right now) the practice of = allowing attribute values of type "URI" being either an explicit,= fully qualified URI *or* a regular-expression substitution that can be app= lied to a previously defined URI attribute.

So, for example, if the URI for my identity as a WHOI employee was &quo= t;http://www.= whoi.edu/1912/241.11" the URI for a picture of me might be specifi= ed in the metadata associated with this URI as "s/$/.jpg/", indic= ating that adding .jpg to the end of the locator URI derives a picture of t= he person.

Another example might be a way to define the way to express a substitut= ion string for receiving metadata about a timeslice of a video that is poin= ted to by a locator for a scientific data object of type "Video".= If the orginal locator was http://www.whoi.edu/1912/2342.234 there might be metad= ata that declares how to modify this URI to one that specifies a start time= and end time.

I'm interested in finding "lessons-learned" by the IETF t= hat it would be worth considering in the realm of dataset identifier intero= perability. Information in the I-Ds represent hours and hours of discussion= /argument and trial in past meetings about what works and what does not wor= k.

It would be a shame if we could not find some way to take advantage of = this work done in the past to help with datset identifiers and certain type= s of the metadata that would sit behind them.

--Andy

________= _______________________________________
dsii mailing list
dsi= i@ietf.org
https://www.ietf.org/mailman/listinfo/dsii


_____________________________________= __________
dsii mailing list
dsii@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dsii




--
Guangqing Deng
<= br> --14dae9340a93178d5b04c83975ec-- From dgq2011@gmail.com Sun Aug 26 23:43:54 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D1321F8533 for ; Sun, 26 Aug 2012 23:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwvLC-LftcU2 for ; Sun, 26 Aug 2012 23:43:53 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 273B221F84B2 for ; Sun, 26 Aug 2012 23:43:53 -0700 (PDT) Received: by iabz21 with SMTP id z21so8460596iab.31 for ; Sun, 26 Aug 2012 23:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2VszImgZKZQSHhUXgsVwL/3NaQ7gyApFFtiWkNm0jcg=; b=r01bkQwF4mWlAsMmibxadALXDVXWNajIFT4bjjtR3A3asqeNaqRvoHcaiVhLfa3E/m IOnbYvfVCK4M2FGkhEbDiaEiZ2l0aQHAmDTcsKey7SoUtYNZzU++zzN/y3Q2oQVNBam8 +i9/h0io4ZG83490PO6s3UsJdlMhjMW17WdNTh3ApbJYfH7wkFuo6LHrLWZwIU7QjYvq H6px3Qlt16b4ROszrb4eaYVkt5N1s5vWp0bI6lfdDZY01uou0IYstl1LKKb9OmMKCoZg F38Z8YRL8sCsKnhFflRKrQdSZFbKQ7vyFSvE8VP5VAXjhl7QqJX0fCED0ZkP6GRu/bpR m8UQ== MIME-Version: 1.0 Received: by 10.50.87.164 with SMTP id az4mr9038409igb.43.1346049832628; Sun, 26 Aug 2012 23:43:52 -0700 (PDT) Received: by 10.64.52.68 with HTTP; Sun, 26 Aug 2012 23:43:52 -0700 (PDT) In-Reply-To: References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> <502BC103.4040107@nomountain.net> <503290C2.7060608@nomountain.net> <6D125452-6D45-473A-A1B0-5DF461B80D3D@whoi.edu> Date: Mon, 27 Aug 2012 14:43:52 +0800 Message-ID: From: Guangqing Deng To: Beth Plale Content-Type: multipart/alternative; boundary=e89a8f3ba6771fafcb04c839a676 Cc: dsii@ietf.org Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 06:43:54 -0000 --e89a8f3ba6771fafcb04c839a676 Content-Type: text/plain; charset=ISO-8859-1 2012/8/27 Beth Plale > This is an important conversation. The issues with data identification > are surfacing in science because science data is at multiple levels of > granularity (e.g., national, state, metro area, street) and giving proper > credit to data creators is of burgeoning important in the sciences. > Commercial video can have issues of granularity but once copyright issues > are resolved, ownership is clear. The issue of ownership/attribution is > driving the urgency to come up with solutions to the data set identifier > problem. > > I see interoperability across ID schemes as something that IETF can help > us think about and propose a solution to. We're not going to accomplish > much by trying to mandate a single ID scheme, not with several already in > existence and with good adoption. Ted and Andrew identified this problem > as well. I wished we'd had more time to discuss interoperability at the > BOF. > > I like the connections Andrew made to work going on in other IETF groups. > That shows hope that there's existing expertise from which we can draw. > > I see this topic as cloud-agnostic. Clouds are heavily researched and > used in academia; identifiers would describe data sets wherever they > "live", and clouds are likely to be or already heavily used for replication > (caching). > BTW, clouds are widely applied by the industry. The aim of replication in clouds is to keep the data "live" (namely to avoid a single point of failure), so replication just is a means but not the purpose. > > The library folks bring a lot to the table, but are a subset of those > interested in this topic. Leif's remark libraries are increasingly > operated by content providers (who are at IETF) is a strong tie. > > Finally, Andrew's suggested 3 options for engagement (copied below) are > very good. > > > On Aug 14, 2012, at 12:35 PM, Andrew Maffei wrote: > > > Three options for engagement seem worthwhile considering: > > 1. More dsii-interested folks currently outside IETF could start > participating > in WGs w cross-cutting interests, once they are identified. > > 2. More IETF'ers could be engaged to participate in current dsii > initiatives outside the IETF and be offered a platform from which > an IETF perspective can be heard. ("Big Data" seems to be getting > big these days for better or worse). > > 3. A dsii working-group might someday be formed within IETF. > > I think that the first 2 options are pre-requisites for the 3rd so > that we can gain familiarity with each others use-cases and cultures > and thus lower the risk of a "bad start". As I have gotten older I > have learned how important "good starts" are to initiatives. > > > best > > beth > > : Beth Plale > : Director, Data to Insight Center > : Professor of Computer Science > : Indiana University Bloomington > > > : Beth Plale > : Director, Data to Insight Center > : Professor of Computer Science > : Indiana University Bloomington > > > > > > > > > > > > > On Aug 22, 2012, at 10:08 AM, Andrew Maffei wrote: > > On Aug 20, 2012, at 3:32 PM, Melinda Shore wrote: > > I'm still trying to figure out what's being proposed here and I > > realized that my mental model might be considerably different from > > that being used by the work's proponents. Where I'm coming from, > > someone who needs a chunk of data and isn't sure where it is (or, > > in some cases, whether or not it exists) does a search, and the > > search returns a set of stuff, where "stuff" includes descriptive > > information (metadata) and an identifier that's actually a > > locator. The locator is used to access the data. > > > Is that consistent with what proponents have in mind? > > > Hi Melinda. > > The above is the primary use case. I think the "stuff" is all metadata > (attribute/value pairs about the dataset) that includes the "locator" you > mention. > > I'd like to comment on some of the things I saw of value at the Vancouver > meeting. I don't claim to be an identifier or metadata expert so perhaps > some of these ideas were derived outside of IETF. But they were new to me. > > One idea would be to consider working together to agree on the "core > metadata" that would be returned about scientific datasets for data object > access and delivery, etc. > > One of the more interesting IETF WG docs I found was the CDN Interconnet > Metadata i-d (draft-cjlmw-cdni-metadata-00). The sections on ACLs, > ACLRules, Delivery seemed directly applicable to delivery of science > datasets, some of which are proprietary and some of which are not. There > are all sorts of issues related to delivery of proprietary scientific data > and very large datasets (or their subsets) that seem applicable. > > I noticed in another I-D (can't find it right now) the practice of > allowing attribute values of type "URI" being either an explicit, fully > qualified URI *or* a regular-expression substitution that can be applied to > a previously defined URI attribute. > > So, for example, if the URI for my identity as a WHOI employee was " > http://www.whoi.edu/1912/241.11" the URI for a picture of me might be > specified in the metadata associated with this URI as "s/$/.jpg/", > indicating that adding .jpg to the end of the locator URI derives a picture > of the person. > > Another example might be a way to define the way to express a substitution > string for receiving metadata about a timeslice of a video that is pointed > to by a locator for a scientific data object of type "Video". If the > orginal locator was http://www.whoi.edu/1912/2342.234 there might be > metadata that declares how to modify this URI to one that specifies a start > time and end time. > > I'm interested in finding "lessons-learned" by the IETF that it would be > worth considering in the realm of dataset identifier interoperability. > Information in the I-Ds represent hours and hours of discussion/argument > and trial in past meetings about what works and what does not work. > > It would be a shame if we could not find some way to take advantage of > this work done in the past to help with datset identifiers and certain > types of the metadata that would sit behind them. > > --Andy > > _______________________________________________ > dsii mailing list > dsii@ietf.org > https://www.ietf.org/mailman/listinfo/dsii > > > > _______________________________________________ > dsii mailing list > dsii@ietf.org > https://www.ietf.org/mailman/listinfo/dsii > > -- Guangqing Deng --e89a8f3ba6771fafcb04c839a676 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/8/27 Beth Plale &= lt;plale@cs.india= na.edu>
This is an important conversation.= =A0The issues with data identification are surfacing in science because sc= ience data is at multiple levels of granularity (e.g., national, state, met= ro area, street) and giving proper credit to data creators is of burgeoning= important in the sciences. =A0 =A0Commercial video can have issues of gran= ularity but once copyright issues are resolved, ownership is clear. =A0 The= issue of ownership/attribution is driving the urgency to come up with solu= tions to the data set identifier problem.

I see interoperability across ID schemes as something t= hat IETF can help us think about and propose a solution to. =A0We're no= t going to accomplish much by trying to mandate a single ID scheme, not wit= h several already in existence and with good adoption. =A0Ted and Andrew id= entified this problem as well. =A0 I wished we'd had more time to discu= ss interoperability at the BOF. =A0

I like the connections Andrew made to work going on in = other IETF groups. =A0That shows hope that there's existing expertise f= rom which we can draw.

I see this topic as cloud-a= gnostic. =A0Clouds are heavily researched and used in academia; identifiers= would describe data sets wherever they "live", and clouds are li= kely to be or already heavily used for replication (caching).=A0
=A0

BTW, clouds are widely applied = by the industry. The aim of replication in clouds is to keep the data "live&q= uot; (namely to avoid a single point of failure), so replication just is a means= but not the purpose.

=A0

The library folks bring a lot to the table, but are a= subset of those interested in this topic. =A0Leif's remark=A0=A0librar= ies are increasingly operated by=A0content providers (who are at IETF) is a= strong tie.=A0

Finally, Andrew's suggested 3 options for engagemen= t (copied below) are very good. =A0

<= div>
On Aug 14, 2012, at 12:35 PM, Andrew Maffei wrote:
<= div>

=
Three options for engagement seem worthwhile considering:

1. M= ore dsii-interested folks currently outside IETF could start participating<= br> in WGs w cross-cutting interests, once they are identified.

2. More = IETF'ers could be engaged to participate in current dsii
initiatives= outside the IETF and be offered a platform from which
an IETF perspecti= ve can be heard. ("Big Data" seems to be getting
big these days for better or worse).

3. A dsii working-group might s= omeday be formed within IETF.

I think that the first 2 options are p= re-requisites for the 3rd so
that we can gain familiarity with each othe= rs use-cases and cultures
and thus lower the risk of a "bad start". As I have gotten older = I
have learned how important "good starts" are to initiatives.=

best

beth

<= span style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;fon= t-style:normal;font-weight:normal;line-height:normal;border-collapse:separa= te;text-transform:none;font-size:medium;white-space:normal;font-family:Helv= etica;word-spacing:0px">
: Beth Plale
: Director, Data to Insight Center
: Professor of Comput= er Science
: Indiana University Bloomington
<= div style=3D"word-wrap:break-word">
: Beth Plale
: Director, Data to Insight Center
: Professor of Comput= er Science
: Indiana University Bloomington










=

On Aug 22, 2012, at 10:08 AM, Andrew Maffei wrote:

<= blockquote type=3D"cite">
On Aug 20, 2012, at 3:32 PM, Melinda Shore wr= ote:

I'm still trying to figure out wh= at's being proposed here and I
realized that my mental model might = be considerably different from
th= at being used by the work's proponents. =A0Where I'm coming from,
someone who needs a chunk of data an= d isn't sure where it is (or,
in some cases, whether or not it exists) does a search, and the
search returns a set of stuff, where "stuff&= quot; includes descriptive
inform= ation (metadata) and an identifier that's actually a
locator. =A0The locator is used to access the data.

Is that consi= stent with what proponents have in mind?

Hi Melinda.
The above is the primary use case. I think the "stuff" is all met= adata (attribute/value pairs about the dataset) that includes the "loc= ator" you mention.

I'd like to comment on some of the thin= gs I saw of value at the Vancouver meeting. I don't claim to be an iden= tifier or metadata expert so perhaps some of these ideas were derived outsi= de of IETF. But they were new to me.

One idea would be to consider working together to agree on the "co= re metadata" that would be returned about scientific datasets for data= object access and delivery, etc.

One of the more interesting IETF W= G docs I found was the CDN Interconnet Metadata i-d (draft-cjlmw-cdni-metad= ata-00). The sections on ACLs, ACLRules, Delivery seemed directly applicabl= e to delivery of science datasets, some of which are proprietary and some o= f which are not. There are all sorts of issues related to delivery of propr= ietary scientific data and very large datasets (or their subsets) that seem= applicable.

I noticed in another I-D (can't find it right now) the practice of = allowing attribute values of type "URI" being either an explicit,= fully qualified URI *or* a regular-expression substitution that can be app= lied to a previously defined URI attribute.

So, for example, if the URI for my identity as a WHOI employee was &quo= t;http://www.= whoi.edu/1912/241.11" the URI for a picture of me might be specifi= ed in the metadata associated with this URI as "s/$/.jpg/", indic= ating that adding .jpg to the end of the locator URI derives a picture of t= he person.

Another example might be a way to define the way to express a substitut= ion string for receiving metadata about a timeslice of a video that is poin= ted to by a locator for a scientific data object of type "Video".= If the orginal locator was http://www.whoi.edu/1912/2342.234 there might be metad= ata that declares how to modify this URI to one that specifies a start time= and end time.

I'm interested in finding "lessons-learned" by the IETF t= hat it would be worth considering in the realm of dataset identifier intero= perability. Information in the I-Ds represent hours and hours of discussion= /argument and trial in past meetings about what works and what does not wor= k.

It would be a shame if we could not find some way to take advantage of = this work done in the past to help with datset identifiers and certain type= s of the metadata that would sit behind them.

--Andy

________= _______________________________________
dsii mailing list
dsi= i@ietf.org
https://www.ietf.org/mailman/listinfo/dsii


_____________________________________= __________
dsii mailing list
dsii@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dsii




--
Guangqing Deng
<= br> --e89a8f3ba6771fafcb04c839a676-- From plale@cs.indiana.edu Mon Aug 27 04:20:05 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C686921F8581 for ; Mon, 27 Aug 2012 04:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouus7uuOqlWT for ; Mon, 27 Aug 2012 04:20:04 -0700 (PDT) Received: from newman.cs.indiana.edu (newman.cs.indiana.edu [129.79.247.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFF221F8627 for ; Mon, 27 Aug 2012 04:20:03 -0700 (PDT) Received: from smtp.cs.indiana.edu (smtp.cs.indiana.edu [129.79.247.7]) by newman.cs.indiana.edu (8.13.8/8.13.8/IUCS_2.97) with ESMTP id q7RBK1oX032015; Mon, 27 Aug 2012 07:20:02 -0400 Received: from [10.0.0.2] (c-71-194-153-96.hsd1.in.comcast.net [71.194.153.96]) (authenticated bits=0) by rage.cs.indiana.edu (8.13.1/8.13.1/IUCS_SMTP_Alternate_Port_1.5) with ESMTP id q7RBJud2031225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Aug 2012 07:20:00 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_66878577-0D5E-4BD9-A38B-744BB4C1277D" From: Beth Plale In-Reply-To: Date: Mon, 27 Aug 2012 07:19:58 -0400 Message-Id: <3EB30CBE-60E1-4229-9821-9DFF9A5F14C2@cs.indiana.edu> References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> <502BC103.4040107@nomountain.net> <503290C2.7060608@nomountain.net> <6D125452-6D45-473A-A1B0-5DF461B80D3D@whoi.edu> To: Guangqing Deng X-Mailer: Apple Mail (2.1278) Cc: dsii@ietf.org Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 11:20:05 -0000 --Apple-Mail=_66878577-0D5E-4BD9-A38B-744BB4C1277D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Aug 27, 2012, at 2:43 AM, Guangqing Deng wrote: > replication just is a means but not the purpose. >=20 as all of us good distributed systems folks know, this is a true = statement :-) beth On Aug 27, 2012, at 2:43 AM, Guangqing Deng wrote: >=20 >=20 > 2012/8/27 Beth Plale > This is an important conversation. The issues with data = identification are surfacing in science because science data is at = multiple levels of granularity (e.g., national, state, metro area, = street) and giving proper credit to data creators is of burgeoning = important in the sciences. Commercial video can have issues of = granularity but once copyright issues are resolved, ownership is clear. = The issue of ownership/attribution is driving the urgency to come up = with solutions to the data set identifier problem. >=20 > I see interoperability across ID schemes as something that IETF can = help us think about and propose a solution to. We're not going to = accomplish much by trying to mandate a single ID scheme, not with = several already in existence and with good adoption. Ted and Andrew = identified this problem as well. I wished we'd had more time to = discuss interoperability at the BOF. =20 >=20 > I like the connections Andrew made to work going on in other IETF = groups. That shows hope that there's existing expertise from which we = can draw. >=20 > I see this topic as cloud-agnostic. Clouds are heavily researched and = used in academia; identifiers would describe data sets wherever they = "live", and clouds are likely to be or already heavily used for = replication (caching).=20 > =20 > BTW, clouds are widely applied by the industry. The aim of replication = in clouds is to keep the data "live" (namely to avoid a single point of = failure), so replication just is a means but not the purpose. >=20 > =20 >=20 > The library folks bring a lot to the table, but are a subset of those = interested in this topic. Leif's remark libraries are increasingly = operated by content providers (who are at IETF) is a strong tie.=20 >=20 > Finally, Andrew's suggested 3 options for engagement (copied below) = are very good. =20 >=20 >=20 > On Aug 14, 2012, at 12:35 PM, Andrew Maffei wrote: >>=20 >> Three options for engagement seem worthwhile considering: >>=20 >> 1. More dsii-interested folks currently outside IETF could start = participating >> in WGs w cross-cutting interests, once they are identified. >>=20 >> 2. More IETF'ers could be engaged to participate in current dsii >> initiatives outside the IETF and be offered a platform from which >> an IETF perspective can be heard. ("Big Data" seems to be getting >> big these days for better or worse). >>=20 >> 3. A dsii working-group might someday be formed within IETF. >>=20 >> I think that the first 2 options are pre-requisites for the 3rd so >> that we can gain familiarity with each others use-cases and cultures >> and thus lower the risk of a "bad start". As I have gotten older I >> have learned how important "good starts" are to initiatives. >=20 > best >=20 > beth >=20 > : Beth Plale > : Director, Data to Insight Center > : Professor of Computer Science > : Indiana University Bloomington >=20 >=20 > : Beth Plale > : Director, Data to Insight Center > : Professor of Computer Science > : Indiana University Bloomington >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Aug 22, 2012, at 10:08 AM, Andrew Maffei wrote: >=20 >> On Aug 20, 2012, at 3:32 PM, Melinda Shore wrote: >>=20 >>> I'm still trying to figure out what's being proposed here and I >>> realized that my mental model might be considerably different from >>> that being used by the work's proponents. Where I'm coming from, >>> someone who needs a chunk of data and isn't sure where it is (or, >>> in some cases, whether or not it exists) does a search, and the >>> search returns a set of stuff, where "stuff" includes descriptive >>> information (metadata) and an identifier that's actually a >>> locator. The locator is used to access the data. >>>=20 >>> Is that consistent with what proponents have in mind? >>=20 >> Hi Melinda. >>=20 >> The above is the primary use case. I think the "stuff" is all = metadata (attribute/value pairs about the dataset) that includes the = "locator" you mention.=20 >>=20 >> I'd like to comment on some of the things I saw of value at the = Vancouver meeting. I don't claim to be an identifier or metadata expert = so perhaps some of these ideas were derived outside of IETF. But they = were new to me. >>=20 >> One idea would be to consider working together to agree on the "core = metadata" that would be returned about scientific datasets for data = object access and delivery, etc. >>=20 >> One of the more interesting IETF WG docs I found was the CDN = Interconnet Metadata i-d (draft-cjlmw-cdni-metadata-00). The sections on = ACLs, ACLRules, Delivery seemed directly applicable to delivery of = science datasets, some of which are proprietary and some of which are = not. There are all sorts of issues related to delivery of proprietary = scientific data and very large datasets (or their subsets) that seem = applicable. >>=20 >> I noticed in another I-D (can't find it right now) the practice of = allowing attribute values of type "URI" being either an explicit, fully = qualified URI *or* a regular-expression substitution that can be applied = to a previously defined URI attribute. >>=20 >> So, for example, if the URI for my identity as a WHOI employee was = "http://www.whoi.edu/1912/241.11" the URI for a picture of me might be = specified in the metadata associated with this URI as "s/$/.jpg/", = indicating that adding .jpg to the end of the locator URI derives a = picture of the person. >>=20 >> Another example might be a way to define the way to express a = substitution string for receiving metadata about a timeslice of a video = that is pointed to by a locator for a scientific data object of type = "Video". If the orginal locator was http://www.whoi.edu/1912/2342.234 = there might be metadata that declares how to modify this URI to one that = specifies a start time and end time. >>=20 >> I'm interested in finding "lessons-learned" by the IETF that it would = be worth considering in the realm of dataset identifier = interoperability. Information in the I-Ds represent hours and hours of = discussion/argument and trial in past meetings about what works and what = does not work.=20 >>=20 >> It would be a shame if we could not find some way to take advantage = of this work done in the past to help with datset identifiers and = certain types of the metadata that would sit behind them. >>=20 >> --Andy >>=20 >> _______________________________________________ >> dsii mailing list >> dsii@ietf.org >> https://www.ietf.org/mailman/listinfo/dsii >=20 >=20 > _______________________________________________ > dsii mailing list > dsii@ietf.org > https://www.ietf.org/mailman/listinfo/dsii >=20 >=20 >=20 >=20 > --=20 > Guangqing Deng >=20 > _______________________________________________ > dsii mailing list > dsii@ietf.org > https://www.ietf.org/mailman/listinfo/dsii --Apple-Mail=_66878577-0D5E-4BD9-A38B-744BB4C1277D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Aug 27, = 2012, at 2:43 AM, Guangqing Deng wrote:

 replication just is a means but not the = purpose.

as all of us good distributed systems = folks know, this is a true statement = :-)

beth



On Aug 27, 2012, at 2:43 AM, Guangqing Deng = wrote:



2012/8/27 Beth Plale = <plale@cs.indiana.edu>
This is an important = conversation.  The issues with data identification are surfacing in = science because science data is at multiple levels of granularity (e.g., = national, state, metro area, street) and giving proper credit to data = creators is of burgeoning important in the sciences.   =  Commercial video can have issues of granularity but once copyright = issues are resolved, ownership is clear.   The issue of = ownership/attribution is driving the urgency to come up with solutions = to the data set identifier problem.

I see interoperability across ID schemes as = something that IETF can help us think about and propose a solution to. =  We're not going to accomplish much by trying to mandate a single = ID scheme, not with several already in existence and with good adoption. =  Ted and Andrew identified this problem as well.   I wished = we'd had more time to discuss interoperability at the BOF.  

I like the connections Andrew made to work going on = in other IETF groups.  That shows hope that there's existing = expertise from which we can draw.

I see this = topic as cloud-agnostic.  Clouds are heavily researched and used in = academia; identifiers would describe data sets wherever they "live", and = clouds are likely to be or already heavily used for replication = (caching). 
 

BTW, clouds are widely applied by the industry. The aim of replication in clouds is to keep the data "live" (namely to avoid a single point of failure), so replication just is a = means but not the purpose.

 

The library folks = bring a lot to the table, but are a subset of those interested in this = topic.  Leif's remark  libraries are increasingly = operated by content providers (who are at IETF) is a strong = tie. 

Finally, Andrew's suggested 3 options for engagement = (copied below) are very good.  


On Aug 14, 2012, at 12:35 = PM, Andrew Maffei wrote:

Three options for = engagement seem worthwhile considering:

1. More dsii-interested = folks currently outside IETF could start participating
in WGs w cross-cutting interests, once they are identified.

2. = More IETF'ers could be engaged to participate in current = dsii
initiatives outside the IETF and be offered a platform from = which
an IETF perspective can be heard. ("Big Data" seems to be = getting
big these days for better or worse).

3. A dsii working-group = might someday be formed within IETF.

I think that the first 2 = options are pre-requisites for the 3rd so
that we can gain = familiarity with each others use-cases and cultures
and thus lower the risk of a "bad start". As I have gotten older = I
have learned how important "good starts" are to = initiatives.

best

= beth

: Beth Plale
: Director, Data to Insight Center
: Professor of = Computer Science
: Indiana University Bloomington


=
: Beth Plale
: Director, Data to Insight Center
: Professor of = Computer Science
: Indiana University = Bloomington






=






On Aug 22, 2012, at 10:08 AM, Andrew Maffei = wrote:

On Aug 20, 2012, at 3:32 = PM, Melinda Shore wrote:

I'm still = trying to figure out what's being proposed here and I
realized that my mental model = might be considerably different from
that being used by the work's proponents.  Where I'm = coming from,
someone who needs a chunk of data = and isn't sure where it is (or,
in some cases, whether or not it exists) does a search, = and the
search returns a set of stuff, where "stuff" = includes descriptive
information= (metadata) and an identifier that's actually = a
locator.  The locator is used to access the = data.

Is that = consistent with what proponents have in mind?

Hi = Melinda.

The above is the primary use case. I think the "stuff" is all metadata = (attribute/value pairs about the dataset) that includes the "locator" = you mention.

I'd like to comment on some of the things I saw of = value at the Vancouver meeting. I don't claim to be an identifier or = metadata expert so perhaps some of these ideas were derived outside of = IETF. But they were new to me.

One idea would be to consider working together to agree on the "core = metadata" that would be returned about scientific datasets for data = object access and delivery, etc.

One of the more interesting IETF = WG docs I found was the CDN Interconnet Metadata i-d = (draft-cjlmw-cdni-metadata-00). The sections on ACLs, ACLRules, Delivery = seemed directly applicable to delivery of science datasets, some of = which are proprietary and some of which are not. There are all sorts of = issues related to delivery of proprietary scientific data and very large = datasets (or their subsets) that seem applicable.

I noticed in another I-D (can't find it right now) the practice of = allowing attribute values of type "URI" being either an explicit, fully = qualified URI *or* a regular-expression substitution that can be applied = to a previously defined URI attribute.

So, for example, if the URI for my identity as a WHOI employee was = "http://www.whoi.edu/1912/241.11" the URI for a = picture of me might be specified in the metadata associated with this = URI as "s/$/.jpg/", indicating that adding .jpg to the end of the = locator URI derives a picture of the person.

Another example might be a way to define the way to express a = substitution string for receiving metadata about a timeslice of a video = that is pointed to by a locator for a scientific data object of type = "Video". If the orginal locator was http://www.whoi.edu/1912/2342.234 there might be = metadata that declares how to modify this URI to one that specifies a = start time and end time.

I'm interested in finding "lessons-learned" by the IETF that it = would be worth considering in the realm of dataset identifier = interoperability. Information in the I-Ds represent hours and hours of = discussion/argument and trial in past meetings about what works and what = does not work.

It would be a shame if we could not find some way to take advantage = of this work done in the past to help with datset identifiers and = certain types of the metadata that would sit behind = them.

--Andy

_______________________________________________=
dsii mailing list
dsii@ietf.org
https://www.ietf.org/mailman/listinfo/dsii
=
=


____________________________________= ___________
dsii mailing list
dsii@ietf.org
https://www.ietf.org/mailman/listinfo/dsii




--
Guangqing = Deng

_______________________________________________
dsii mailing = list
dsii@ietf.org
https://www.ietf.org/ma= ilman/listinfo/dsii

= --Apple-Mail=_66878577-0D5E-4BD9-A38B-744BB4C1277D-- From swb@internet2.edu Mon Aug 27 04:56:04 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F0621F8639 for ; Mon, 27 Aug 2012 04:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5n65pgSMGpF for ; Mon, 27 Aug 2012 04:56:04 -0700 (PDT) Received: from int-proxy01.merit.edu (int-proxy01.merit.edu [207.75.116.230]) by ietfa.amsl.com (Postfix) with ESMTP id D8FA421F8625 for ; Mon, 27 Aug 2012 04:56:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by int-proxy01.merit.edu (Postfix) with ESMTP id 4E8F0100090; Mon, 27 Aug 2012 07:56:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at int-proxy01.merit.edu Received: from int-proxy01.merit.edu ([127.0.0.1]) by localhost (int-proxy01.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0g5hprsEPb24; Mon, 27 Aug 2012 07:56:01 -0400 (EDT) Received: from swbi2mbp.local (cpe-74-79-27-61.twcny.res.rr.com [74.79.27.61]) by int-proxy01.merit.edu (Postfix) with ESMTPSA id 5C07210008E; Mon, 27 Aug 2012 07:56:01 -0400 (EDT) Message-ID: <503B6050.2010407@internet2.edu> Date: Mon, 27 Aug 2012 07:56:00 -0400 From: Scott Brim Organization: Internet2 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Beth Plale References: <7F45CB6F-2FE2-4A25-8A18-C94674489E39@vigilsec.com> <502BC103.4040107@nomountain.net> <503290C2.7060608@nomountain.net> <6D125452-6D45-473A-A1B0-5DF461B80D3D@whoi.edu> <3EB30CBE-60E1-4229-9821-9DFF9A5F14C2@cs.indiana.edu> In-Reply-To: <3EB30CBE-60E1-4229-9821-9DFF9A5F14C2@cs.indiana.edu> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dsii@ietf.org, Guangqing Deng Subject: Re: [dsii] Potential IETF Work Items X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 11:56:04 -0000 Hi Beth. On Sun, Aug 26, 2012 at 7:41 PM, Beth Plale wrote: > This is an important conversation. The issues with data > identification are surfacing in science because science data is at > multiple levels of granularity (e.g., national, state, metro area, > street) and giving proper credit to data creators is of burgeoning > important in the sciences. Commercial video can have issues of > granularity but once copyright issues are resolved, ownership is > clear. The issue of ownership/attribution is driving the urgency > to come up with solutions to the data set identifier problem. > > I see interoperability across ID schemes as something that IETF can > help us think about and propose a solution to. We're not going to > accomplish much by trying to mandate a single ID scheme, not with > several already in existence and with good adoption. Ted and Andrew > identified this problem as well. I wished we'd had more time to > discuss interoperability at the BOF. > > I like the connections Andrew made to work going on in other IETF > groups. That shows hope that there's existing expertise from which > we can draw. It shows that it is fairly straightforward to build a mechanism for higher layer communications ... but the key issue will be exactly what to carry. That's something the IETF can't solve. Given the large number of ID schemes, finding a set of useful common semantics is, well, daunting. Once you have that, a framework for communication using those semantics will be relatively easy. > I see this topic as cloud-agnostic. Clouds are heavily researched > and used in academia; identifiers would describe data sets wherever > they "live", and clouds are likely to be or already heavily used for > replication (caching). Yes, the interoperability issues exist regardless of where or how the identities are being used -- cloud or not. > Finally, Andrew's suggested 3 options for engagement (copied below) > are very good. > > On Aug 14, 2012, at 12:35 PM, Andrew Maffei wrote: > > Three options for engagement seem worthwhile considering: > > 1. More dsii-interested folks currently outside IETF could start > participating in WGs w cross-cutting interests, once they are > identified. Existing WGs' work might be useful to DSII but I don't think you're going to be able to inject DSII concerns into them. They are focused on specific problems, not on interoperability of identifiers per se. > 2. More IETF'ers could be engaged to participate in current dsii > initiatives outside the IETF and be offered a platform from which > an IETF perspective can be heard. ("Big Data" seems to be getting > big these days for better or worse). This would be good if people have the time. What other groups do you think are effectively working on the DSII problem? > 3. A dsii working-group might someday be formed within IETF. > > I think that the first 2 options are pre-requisites for the 3rd so > that we can gain familiarity with each others use-cases and cultures > and thus lower the risk of a "bad start". As I have gotten older I > have learned how important "good starts" are to initiatives. OK. Thanks ... Scott From amaffei@whoi.edu Mon Aug 27 08:45:23 2012 Return-Path: X-Original-To: dsii@ietfa.amsl.com Delivered-To: dsii@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908F921F851E for ; Mon, 27 Aug 2012 08:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPavEkLpjSZF for ; Mon, 27 Aug 2012 08:45:23 -0700 (PDT) Received: from postal2.whoi.edu (postal2-e0.whoi.edu [128.128.76.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9786321F84B3 for ; Mon, 27 Aug 2012 08:45:15 -0700 (PDT) Received: by postal2.whoi.edu (Postfix, from userid 117) id 67C9F52451A; Mon, 27 Aug 2012 11:45:14 -0400 (EDT) Received: from dyn-128-128-91-192.whoi.edu (dyn-128-128-91-192.whoi.edu [128.128.91.192]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal2.whoi.edu (Postfix) with ESMTPSA id 2FBA95244BD; Mon, 27 Aug 2012 11:45:14 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Andrew Maffei In-Reply-To: Date: Mon, 27 Aug 2012 11:45:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <31D8C7C5-53BF-447D-908E-D5E897B7AE7C@whoi.edu> References: To: Scott Brim X-Mailer: Apple Mail (2.1278) X-Virus-Status: No Cc: Ted Hardie , dsii@ietf.org Subject: Re: [dsii] Draft minutes: please review X-BeenThere: dsii@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:45:23 -0000 On Aug 25, 2012, at 4:12 PM, Scott Brim wrote: > "Andy Buffet - Woods Hole" -> Maffei Thanks Scott :) A minor fix and then clarification of notes on my statement. > Beth Plale then review the conceptual framework for work in this area, = discussing both the framework for=20 review --> reviewed >=20 > Andy Buffet - Woods Hole - clearly identified as interop = problem, and we have techniques/ approaches for interop. We can that = add into the work that has been going on some time in the sciences. = There is a limited number of pid schemces for datasets - an api for = dataset identifiers, as ezid already has, is useful. When it becomes = domain specific there is lots to be done. Andy Maffei - Woods Hole Oceanographic Institution - clearly identified = as an interoperability problem, and IETF has extensive = experience/techniques/approaches for how to develop interoperability. = IETF can contribute valuable perspective to work that had been going on = some time in sciences. Topics for future discussion: recommending = limited# of PID schemes for science datasets, agreed-upon API for = assigning identifiers for scientific datasets (EZID as a model), = defining core non-domain-specific metadata. Agrees that realm of = domain-specific metadata there is lots of v hard work that needs to be = done (that is probably out-of-scope for IETF). Establishing = interoperability frameworks and core metadata for science dataset = identification is suggested as in-scope.