Subject: [dsii] Potential IETF Work Items

From: Russ Housley <[email-masked]>
Date: Tue, 14 Aug 2012 10:16:25 -0400

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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 14 Aug 2012 07:56:47 -0800

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
[email-masked]

"Software longa, hardware brevis."

---

From: Andrew Maffei <[email-masked]>
Date: Tue, 14 Aug 2012 12:35:52 -0400

> expertise the IETF can bring to bear on any of these questions.

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 
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
  [email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Tue, 14 Aug 2012 20:13:45 +0200

On 08/14/2012 05:56 PM, Melinda Shore 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.
> 
> 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'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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 14 Aug 2012 10:28:51 -0800

> 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

---

From: Ed Summers <[email-masked]>
Date: Tue, 14 Aug 2012 20:47:07 -0400

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 <[email-masked]>
Date: Wed, 15 Aug 2012 10:10:03 -0400

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?
>
> * 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)
>
> 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

---

From: Andrew Maffei <[email-masked]>
Date: Wed, 15 Aug 2012 10:53:07 -0400

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 Hardie <[email-masked]>
Date: Wed, 15 Aug 2012 08:06:02 -0700

On Wed, Aug 15, 2012 at 7:10 AM, Scott Brim <[email-masked]> 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 <[email-masked]>
Date: Wed, 15 Aug 2012 07:32:19 -0800

> 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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 15 Aug 2012 08:46:39 -0700

> 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 <[email-masked]>
Date: Mon, 20 Aug 2012 11:32:18 -0800

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

---

From: Guangqing Deng <[email-masked]>
Date: Wed, 22 Aug 2012 15:54:46 +0800

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 <[email-masked]>

> ______________________________**_________________
> dsii mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/dsii<https://www.ietf.org/mailman/listinfo/dsii>
>

-- 
Guangqing Deng

---

From: Andrew Maffei <[email-masked]>
Date: Wed, 22 Aug 2012 10:08:11 -0400

> 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

---

From: Beth Plale <[email-masked]>
Date: Sun, 26 Aug 2012 19:41:33 -0400

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). 

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.  

> 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:

> _______________________________________________
> dsii mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dsii

---

From: Melinda Shore <[email-masked]>
Date: Sun, 26 Aug 2012 21:22:04 -0800

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

---

From: Guangqing Deng <[email-masked]>
Date: Mon, 27 Aug 2012 14:30:09 +0800

2012/8/27 Beth Plale <[email-masked]>

> 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.
>
> 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.
>
> 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
>

-- 
Guangqing Deng

---

From: Guangqing Deng <[email-masked]>
Date: Mon, 27 Aug 2012 14:43:52 +0800

> "live", and clouds are likely to be or already heavily used for replication

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.

-- 
Guangqing Deng

---

From: Beth Plale <[email-masked]>
Date: Mon, 27 Aug 2012 07:19:58 -0400

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:

> 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.
> 
>   
>

---

From: Scott Brim <[email-masked]>
Date: Mon, 27 Aug 2012 07:56:00 -0400

Hi Beth.

On Sun, Aug 26, 2012 at 7:41 PM, Beth Plale <[email-masked]>
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.

> 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.

> 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?

> have learned how important "good starts" are to initiatives.

OK.

Thanks ... Scott