Re: [MINUTES] W3C Traceability Vocabulary Call - 2021-04-13 12pm ET

Huge thanks to Manu and Heather for helping the traceability call level up.

We're excited to be able to move quickly together, while meeting the
process bars set by the W3C CCG.

OS

On Tue, Apr 13, 2021 at 3:18 PM W3C CCG Chairs <w3c.ccg@gmail.com> wrote:

> Thanks to Manu Sporny for scribing this week! The minutes
> for this week's Traceability Vocabulary telecon are now available:
>
> https://w3c-ccg.github.io/meetings/2021-04-13-traceability
>
> Full text of the discussion follows for W3C archival purposes.
> Audio from the meeting is available as well (link provided below).
>
> ----------------------------------------------------------------
> Traceability Vocabulary Telecon Minutes for 2021-04-13
>
> Agenda:
>
> https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0058.html
> Topics:
>   1. Process for IPR-protected CCG Meetings
> Organizer:
>   Juan Caballero
> Scribe:
>   Manu Sporny
> Present:
>   Orie Steele, Mike Prorock, Jordan Windsor, Juan Caballero, Manu
>   Sporny, Heather Vescent
> Audio:
>   https://w3c-ccg.github.io/meetings/2021-04-13/audio.ogg
>
> Manu Sporny is scribing.
>
> Topic: Process for IPR-protected CCG Meetings
>
> Manu Sporny:  Emails to CCG list need [AGENDA] prefix and
>   date/time in subject, agenda in body. followup email with notes
>   also good.
> Juan Caballero:  Since I didn't send the Agenda link, but there
>   are people from CCG here. Shoudl we have the meeting? Happy to
>   end early, send out proper email, for next week. We could spend
>   time trying to make the next call productive.
> Orie Steele:  We should cover procedure and run next week's as a
>   public call; as long as no substantive proposals THIS call, I'm
>   happy to provide feedback and talk about the proposal
>   ...also happy to cover VC-HTTP-API backstory
> Manu Sporny:  I share the frustruation and want to get the
>   procedure sorted and propose a strategy that adds less work to
>   all of your schedule, but we don't have quorum
> Orie Steele:  We have given a lot of work to V-H-A and I agree
>   that we don't have enough UCR there; everyone seems to contribute
>   only to the extent that it helps their use cases
> Orie Steele:  Markus has his own opinion about it; wasn't it
>   originally created as part of a Danube contract?
> Orie Steele:  We're building stuff, we know what the API should
>   do, to some degree it's not exactly lying but kinda transitive
>   interoperability -- A === B, C supports B, therefore A supports
>   C. There's nothing wrong with that, it's just not good enough.
>   The first version of anything isn't right - the first version of
>   the VC HTTP API isn't good -- took a year to get a revision --
>   pacing is too slow for our needs - interop space. We've moved the
>   Traceability vocab faster, git pull request -- merged even if
>   they're not super great. Others come in behind that fix them.
>   Mesur has fixed problems I created, etc. We have been operating
>   in a healthy and productive way. It's totally different from what
>   it is like to work on VC HTTP API. Not that future of
>   Traceability API overrides VC HTTP API -- only way for it to
>   become broken would be for VC HTTP API changes. I'll stop there
>   -- other companies, other than Transmute - Direct Exchange
>   problem -- postman collection test work - excited to invest on
>   those flows across multiple parties. Test different interop
>   flows, different mechanisms, doesn't do stuff that we want it to
>   do. In a way it's a fork, but in a way it's not -- doesn't make
>   sense to include them, as Markus agreed in a PR.
> Heather Vescent: https://github.com/w3c-ccg/meetings/issues/41
> <heathervescent> sorry, I guess I am going to join this and
>   listen.
> Mike Prorock:  I share the timeline frustration, with both priv
>   and public sector customers
> Mike Prorock:  Manu, you had mentioned about alternate paths to
>   go tackle issue -- definitely echo frustrations that Orie
>   provided... similar concerns around pacing - rate that we need to
>   move at for our customers -- both commercial and government
>   customers -- that is top of mind for myself -- owner of business,
>   CTO, etc. There is a pace we need to keep up to work on interop
> Mike Prorock:  That's the big concern that we need to get at from
>   the Mesur.io side -- even if this ends up folding back in --
>   recombined split... I'm cool with that, doesn't bother me as long
>   as there is a place where we can make progress, ahve these
>   meetings, all the various items that we need to -- notify someone
>   of VC, all those various use cases -- starting to get at.
>   Proposal that orie made.
> Mike Prorock:  What Orie said, but Manu, want to hear your
>   insight... Welcome your input on this.
> <orie> same, eager to see progress
> <orie> I don't think we "all want the same thing"... evidenced by
>   the thread
> Manu Sporny:  I sympathize, but i want us to consider how this
>   looks from the outside like a hostile takeover of a spec process
>   by 1 or more companies
> Manu Sporny:   This is the big tech standards playbook, and it
>   will not look good in retrospect
> <juan_(spherity_gmbh)> ... this call is what people were asking
>   for
> <juan_(spherity_gmbh)> ... this kind of public call is the way
>   forward, and calls like this will get us back on track here
> <juan_(spherity_gmbh)> ... i had to rearrange my day and delay
>   other (standards) work to be here, and many people who should be
>   aren't
> <juan_(spherity_gmbh)> ... i think a markdown or a long-open PR
>   is a way of parallel/independent work without signaling a hostile
>   takeover
> <juan_(spherity_gmbh)> ... i don't think this group of companies
>   is trying to do an endrun around consensus, but a fork (and the
>   SVIP aspect) aren't helping the optics of consensus being endrun
>   around
> <juan_(spherity_gmbh)> ... i find it hard to talk about the API
>   itself on this call without more people here
> <mprorock> so what is the alternate path?
> Orie Steele:  Describing what we've done in that way is a
>   self-fulfilling prophecy
> Manu Sporny:  There are two kinds of forks-- PR forks and spec
>   forks.  the latter is dangerous
> Orie Steele:  I disagree
> Manu Sporny:  Unfortunately W3C history supports my concern
> Orie Steele:  I don't think is a work item (yet), there is no
>   working group being forked
> Manu Sporny:  It is a CCG work item
> Orie Steele:  We need to move things forward, conversations like
>   this are only one part of what will move us forward
> Orie Steele:  I am trying to make as clear as possible that this
>   proposal is to extend peaceably the V-H-A
> Manu Sporny:  But this creates more work for people, incl me and
>   other editors, and i think we need
> <juan_(spherity_gmbh)> ... to run queue
> Heather Vescent:  I hear what Manu is saying about the
>   constraints of the CCG Process in which things have to occur at
>   W3C.
> Heather Vescent:  I saw TallTed make those comments as well in
>   the thread -- I know there is disagreement and desire to move
>   fast and forward, and I'm not a fan of bureaucracy or W3C rules.
> Heather Vescent:  I think you should seriously consider what Manu
>   is saying -- and the way it is read in the W3C.
> Heather Vescent:  I do believe the way that Manu described it, is
>   not what you intend. I also hear and respect and understand the
>   slow pace of the work item -- that can address the need to go
>   fast.
> Heather Vescent:  I'd like to ask both sides to go back into your
>   corners and truly consider other's perspectives, goals, needs --
>   even if you 100% agree... try to get a view of the other place.
> Heather Vescent:  Let's come to this fresh, with a fresh view on
>   how to address it with constraints of W3C and companies
>   involved... companies that need resolutionf aster.
> Juan Caballero:  I wanted to just mention, now or end of call --
>   hear from Justin and Brian -- they may be at a disadvantage --
>   everyone has been participating for a while -- seprate work item
>   created, separate branch, next steps are kinda the same either
>   way... sake of setting an agenda for next tuesday -- one thing in
>   multiple threads... this change... multiple models proposed,
>   different models, markus was saying he had a backlog of things --
>   verifier API... EU
> Thing about ESSIF -- verifier needs, etc.
> Juan Caballero:  However we do it, there are parallel work
>   streams -- not attached to a particular mechanism... there is a
>   lot of work that's held up by ... doing the work... should be
>   mindful of other work relevant to this.
> Juan Caballero:  The workload on the Editors, might get to be a
>   lot of work if it stays to be one repo -- maybe a
>   heather/manu/markus question.
> Mahmoud: What I think would not be helpful is to continue the
>   conversation on whether we should split or go back into VC HTTP
>   API -- I believe there are four or five that want to speak on
>   that -- rest of this call, what would we like to do next week. To
>   that point, Juan and Spherity have made a wonderful use case
>   document... it needs some comments, changes, I have made some
>   comments... lot of work to be done there.
> Mahmoud: What I'm seeing that's missing from VC HTTP API -- what
>   it is, what it's going to be -- fork for traceability API --
>   everyone wants it -- idea of if we can't agree on foundational
>   principles, then nothing good is going to done, we're going to
>   return to gridlock... agree on use cases, actual requirements,
>   then move on requirements.
> Orie Steele:  It's my understanding that even if work items seem
>   similar, or start on similar items -- all vocabularies start w/
>   assumption of VC spec, it's my understanding that you don't need
>   permission to create a new work item if it has similarities with
>   other ones... I realize it's uncomfortable, people that don't
>   work with software all the time, don't feel comfortable w/
>   forks... Is there anything legally preventing us to work in
>   parallel and contribute to
> Both work items in parallel.
> <orie> great, we're happy to help on both sides of the problem
> <orie> speaking for Transmute
> <juan_(spherity_gmbh)> /me and boy does it happen int he Web
>   Advertising group...
> <juan_(spherity_gmbh)> /me adtech is like 100% hostile takeovers
>   haha
> <orie> happy to keep talking about it, as long as we are not
>   blocked
> <orie> we're eager to see actual work on the vc http api...
>   obviously for supply chain traceability we want to keep those
>   APIs together... based on our use case.
> Orie Steele: Well in fairness watching a thing that is not
>   changing at all isn't super challenging :)
> <juan_(spherity_gmbh)> /me
>
> https://docs.google.com/document/d/1-u0_Ub6feiX6DH3jXFJFjt6n3CwKGpkmC3VISqDkWL4/edit?disco=AAAAL-KhbVY&ts=6075b66a&usp_dm=false
> <juan_(spherity_gmbh)> 3 chairs
> <orie> Transmute is in all the processes
> <orie> we are not saying we won't help the vc http api grow up
> Heather Vescent:  I don't want to add a roadblock to it -- doing
>   minutes from previous meeting -- don't think it's planned
>   obscuration of VC HTTP API -- these have been raised privately
>   between the Chairs and ... there are at least two Chairs that
>   have concerns. I wish Kim was on this call -- I think it's good
>   community participation to go through the process we have, which
>   I know is annoying and frustrating, but that's where it is --
>   don't want to roadblock you guys, there are annoyances with
>   working w/ W#C.
> <orie> we are saying we want to work on other issues in parallel
> Mike Prorock:  Many, that's well said, with ReSpec stuff -- what
>   the hell are we testing again, what's this VC HTTP API even mean,
>   which is why you saw my commits last year -- just around README
>   side of things -- what is this doing, try to describe this
>   stuff... if nothing else, 100% supportive of exchange of
>   information and what are we after. I am also supportive of going
>   about it in parallel -- if that's the case, let's correct the
>   perception, key thing
> Here... supply chain side of the world -- companies we're
>   involved with -- commercial market, we have a need to demonstrate
>   interop with them as customers, do that with open specs, trace
>   vocab exists for that reason.
> Mike Prorock:  If we have an API that does that cleanly, if that
>   spec happens in VC HTTP API -- that's also cool... somehow,
>   something has to happen... that's the issue.
> Mrprorock: I'm very open -- not set on anything specific -- need
>   something to point to w/ customers, whatever gets us to that path
>   quickest is what I'm going to back.
> Juan Caballero:  For the record, for the future people that might
>   attend CCG calls, topic calls on the subject, coming in late,
>   it's hard to figure out where to start. Kim's broader questions
>   on where use cases are, where requirements are, everyone every
>   customer or potential partner of Spherity doesn't understand
>   where this is coming from. A year and a half of backstory
>   there... that's just my concern, adding use cases to a document
>   I'm not even sure what I'm adding it to... personally, confused
>   about next steps. Tiny bit of explicit guidance would help. If
>   this is going to all stay in kitchen sink repo, feature branches,
>   what's the UCR of that API?
> Juan Caballero:  Started on Google doc based on architecture --
>   formatting... how do we get from here to CCG regularity --
>   retrofit previous works so future work can build on it.
> Orie Steele:  Speaking as one of the folks that contributes to a
>   large number of CCG items -- you open PRs, you discuss on PRs,
>   you try and make actual changes -- can't just talk about how
>   things should be better... you have to be the change in the
>   world. Speaking as Transmute, we'll continue to support VC HTTP
>   API -- we will continue to help w/ that API, but we can't shape
>   the vision for it -- we can't dictate the vision for it, it's a
>   community effort -- it can't just be one company doing it, it has
>   to be people agreeing to what it will be.
> Orie Steele:  From a UCR document, a number of us have been
>   working on supply chain VC use cases, DID Core, EDV spec... we've
>   worked on presentations w/ companies on VCs... to say we need a
>   use case for exchanging VCs in supply chain credentials, we have
>   a document for it -- feels like we have a clear understanding for
>   supply chain oriented credentials... we've demonstrated interop
>   on those credential formats... we're going to continue to do that
>   work in parallel.
> <juan_(spherity_gmbh)> /me straw man if anyone wants to help me
>   PR in something for the UCR of V-H-A:
> Orie Steele:  I do agree with Manu, if we could get a sane VC
>   HTTP API single source of truth, that would be best scenario --
>   but often w/ standards, you don't get the best thing... totally
>   sympathetic that VC HTTP API is confusing, it's brutal...
>   vaccination test suite -- use case driven interop for vertical
>   make a lot more sense. I don't think VC HTTP API can tell that
>   story by itself.
> Orie Steele:  We've already been doing that in test suite today.
>   Relies on traceability vocab, vaccination vocab, endpoints we
>   used were built on top of those vocabularies. There has always
>   been a use case oriented API... haven't successfully conveyed
>   stuff to it... people are asking people to do more work when
>   we've already put in a lot of work... support new APIs, all these
>   things that we want, who is going to do the work. Fundamentally,
>   who is going to do the work?
> Orie Steele:  I don't know that I agree with idea that use case
>   specific interop is something we should shy away from... easier
>   for us to tell a story, use case based interop can be built on
>   other things... use case oriented interop would do a better job
>   at first -- excited about opportunity to explore that, not
>   something we can explore by ourselves... but if there were PRs
>   merged, shape visibly change, my opinion would change.
> <heathervescent> Could we do a VC HTTP API knowledge transfer to
>   broaden what it covers to a broader audience in the community?
> Orie Steele:  But it would need to have PRs and work requests
>   done to get it there... in the meantime, we need to be able to
>   tell interop stories w/o being blocked by that particular API.
> <heathervescent> *broaden who knows
> Manu Sporny:  I don't disagree with a whole lot of that. i think
>   the standards process is always held up by how much work various
>   participants can or cannot submit
> Manu Sporny:  Doing things in parallel sounds great to everyone,
>   i understand the temptation. i can't work on it at the moment and
>   there are very few people who can balance this with the did-core
>   test suite, for example. at some point, tho
> <juan_(spherity_gmbh)> ... you'll need to merge this with the
>   other work, and earlier is better for the literal and figurative
>   merge conflicts that arise naturally from that
> <orie> I'd rather see objections to something that works, than to
>   something that does not.
> <juan_(spherity_gmbh)> ... i am putting some resources into
>   advancing v-h-a to pay forward future work
> <juan_(spherity_gmbh)> ... that might come of parallel efforts
> <juan_(spherity_gmbh)> ... i'm hearing everyone here could be
>   happy
> <orie> we have fairly low confidence in the probability that the
>   vc http api will change / move fast enough.
> Manu Sporny:  Let me see if next week we could talk about ideal
>   structure
> <heathervescent> Manu - were you talking about the CCG call or
>   another one?
> Juan Caballero:  Ok, next week could do UCR agenda next week and
>   how to split the work up.
> <juan_(spherity_gmbh)> oh right duh
> Heather Vescent:  I thought you said work in preparation during
>   CCG call.
> <juan_(spherity_gmbh)> yes let's all do that!
> <juan_(spherity_gmbh)> i can send an agenda for THIS time
> Heather Vescent:  Kim will be moderating, need to make sure she's
>   in the loop on that.
> Juan Caballero:  I can follow up with Kim. I'll do that.
> Juan Caballero:  I do want her help regularizing the back history
>   of that group, she was the one pushing for that.
> <heathervescent> Can I ask a dumb question, what is this meeting?
> Juan Caballero:  We can keep agenda for next week... week
>   after... agenda for this group -- use cases in the...
>   Traceability Vocab meeting -- once we're finished w/ API -- going
>   back to Vocab.
> <orie> traceability vocab is already a work item
> Heather Vescent:  Is this a Task Force, a separate call? Is it
>   part of DIF -- have you talked to any of the Chairs?
> Juan Caballero:  Good question, don't know answer to those
>   questions...
> <orie> its just a work item
> <orie> with folks trying to get stuff done
> Heather Vescent:  Task Force has a formal process and structure,
>   and work item is separate... everyone in this community is
>   stretched thing, so many meetings... just not sure where to slot
>   it, where CCG needs to manage it... want it to go on autopilot
>   and not micromanage.
> <orie> keep adding meetings until no progress can be made?
> Orie Steele: :)
> <orie> We actually tried to do our contributions on github
> Juan Caballero:  This was a weekly meeting for SVIP companies...
>   SVIP companies were encouraged to make sure output is useful for
>   CCG and public and published.. I didn't think about why we aren't
>   scribing, not emailing Agendas, thought... I don't know.
> <orie> because it has a version control system built in
> <orie> easier to audit
> Mike Prorock:  A little history -- I setup a standing meeting,
>   anyone from SVIP, focused on supply chain / traceability meetings
>   -- ensure we were aligned for interop tests... specific to SVIP
>   topics only, obviously, ther was a lot of "we're also working on
>   this stuff out in the open"
> Mike Prorock:  What we're seeing w/ VC HTTP API -- the second
>   this moved past, talking closed vs. talking open -- that was
>   immediately the flag, create a work item, open this call up as a
>   public call to anyone that wants to join. Any issues to
>   traceability. That's how this whole meeting started. The four of
>   us on a call, we're here, were discussing plugfest, need public
>   vehicle.
> Mike Prorock:  Last week, at that point, Juan just emailed it out
>   to a list -- wanted to avoid creation work or backroom
>   discussions that could prevent ... make things not clear -- Trace
>   Vocab, interop tests... that's whole history of how this whole
>   thing got started... internal call -- other companies w/ shared
>   customer.
> Mike Prorock:  Wasn't anything beyond that... we tested it, we
>   worked on trace vocab stuff... other trace issues on VCs and
>   DIDs, make sure there is ability to talk out in open about this
>   stuff... avoid problems in communities... how did I get input
>   into that... does that make sense?
> Heather Vescent:  Thanks that helps, you guys have been doing
>   this stuff for years now... I think I might, same goals... this
>   is what I think needs to happen: You guys need to conclude your
>   SVIP work and end that, and I think you've done that... and then
>   it needs to consciously transition into openness, part of that
>   transition, what is that knowledge, what did you build? Watching
>   what was happening, I didn't get what this was w/o sitting in
>   those 15 hours
> Of meetings.
> Heather Vescent:  How do you tech transfer this from your
>   internal project and productize and make it accessible to other
>   people in community that have no clue about these discussions.
> Akc heathervescent_
> <orie> lets start from scratch!
> Heather Vescent:  You need to build that community -- you've been
>   working fast... but you have to slow down a bit -- let people get
>   on, let people get onboarded... separately with CCG 101 -- trying
>   to do that as well. That's what I'm thinking of as Chair... make
>   tech accessible to more people... part of that is, formal
>   beginning of what this meeting is... you need to consciously
>   start from ground-zero so it's accessible to new people.
> Orie Steele: At DIF :)
> <orie> lol jk
> <orie> yeah lol
> <juan_(spherity_gmbh)> DizMe-2.0
> <heathervescent> Here I am, VOR (Voice of Reason)
> <orie> I will say that calls are never the time to be inclusive
>   of different timezones
> Mike Prorock:  Obviously engaged on 101 side as well... this is
>   what we want to avoid -- we have a good place to do that... we
>   have people engaged... let's make sure people are engaged...
>   moment it's a possibility - once it became clear, early in the
>   process... this process should be out in the open.
> <orie> there is a reason async work in github is critical to
>   inclusion
> Mike Prorock:  Companies working w/ one common customer base...
>   that's intent of this call... but got side tracked a bit w/ API
>   -- otherwise, we'd just be talking about traceability stuff...
>   how do we exchange this stuff... how do we do this right.
> <heathervescent> How can I as a chair, or the CCG 101 group
>   assist you in this?
> Mike Prorock:  This does need to be out in the open, there is a
>   balance on pacing... async and github is good, there needs to be
>   good alignment, need to do this stuff and make progress w/o
>   waiting weeks for PRs to get merged.
> Heather Vescent: +1 Manu
> <juan_(spherity_gmbh)> 60min
> Heather Vescent:  Part of my role as co-chair is to assist -- how
>   can I help in kick-off and make this more accessible to broader
>   community and address other concerns.
> Orie Steele:  The thing to do is have these calls, in context as
>   Supply Chain Traceability as it's own concept -- let's not start
>   w/ VC HTTP API -- want to start w/ Supply Chain
>   Traceability/Security, why it's important, this call is the
>   opportunity to be more open about it. We've been doing it on
>   Github... and that is where progress is made, we do need to
>   introduce supply chain traceability, non-technical
>   contribution... work backwards from there to standards to support
>   it. Specific issues on some of those standards.
> Orie Steele:  We just need regular calls that are open... we've
>   been having a closed version of that for a whole bunch of
>   items... it needs to stop, problematic for entire community --
>   sounds like there is a group of companies for work items, that
>   needs to stop, you need to do that across the board.
> Orie Steele:  Every other work item needs to be treated equally.
> Heather Vescent:  This sounds like it's a Supply Chain Task Force
>   vs. just a specific work item.
> <mprorock> at this time
> Orie Steele:  I don't know if we need any more process... we'd
>   love to share that progress w/ IPR protected space... otehr work
>   items, as a part of that. I thik we'll continue to do that...
>   don't want more formal process for this work unless we need that
>   for aircover to have open meetings.
> Heather Vescent:  I'd like to reduce task forces... some have
>   value, but lots of meetings.
> Heather Vescent:  Work items so far, specific technical work
>   items, use cases and stuff -- does it make sense to have work
>   item that's broader? That would address -- supply chain work
>   items with other things?
> Orie Steele:  Traceability vocab has nice preamble... that
>   vocabulary -- asserting that if that's not soft enough, let's not
>   create a new thing to make it better... level up in technical
>   complexity -- data model, how do I exchange these things. Today,
>   we announced we want to work on Traceability HTTP API -- would
>   love to be able to talk about both of those things on this call,
>   if folks don't have background on it... can explain why.
> Mike Prorock: +1 Intro call
> Heather Vescent:  As part of kick-off... could you put together
>   different work items... supply chain traceability have that
>   meeting be one of those first meetings.
> Orie Steele:  We could do that -- PRs to Traceability vocab as
>   landing spot... you really don't want another asset to do the
>   introduction.
> Heather Vescent:  Maybe as part of intro call... could pull CCG
>   101 folks into it -- 101 intro to specific set of work items...
>   cover content - intro content.
> <orie> Take the IIW mindset
> Heather Vescent: +1 Manu
> <orie> You are where you need to be
> <heathervescent> well.... not always Orie
> <orie> I am not here to make you a believer Manu, what you choose
>   to believe is your own businessess
> Orie Steele: :)
> <heathervescent> Manu - what if we have semi-regular updates to
>   the main ccg call?
> <orie> setup a regular call for the vc http api
> <orie> and I will be happy to attend
> <juan_(spherity_gmbh)> lololol
> <juan_(spherity_gmbh)> i don't think i'm cut out to run meetings
>   in this mode
> Heather Vescent:  This all sounds fine, hear your concern,
>   updates sent to list -- sent quarterly, 3x a year -- we can fold
>   in what's going on, what's going on in this community, back to
>   main CCG list, so we have coverage.
> Heather Vescent:  Main meeting, Markus' meeting -- not meant to
>   be weekly update/monthly update -- just 3x a year.
> <orie> this call isn't about the vc http api anymore, we are
>   focused on traceability... I am sure you wouldn't say folks need
>   to attend every call that might cover LD Proofs
> <orie> You should setup a call
> <orie> and invite folks to it
> <orie> like we did for this
> <heathervescent> YOu want to do these in the CCG call slot?
> <mprorock> 1 have a hard stop
> <orie> ehh, i would guess the vc http api is not relevant to the
>   entire CCG....
> <mprorock> apologies all, and thank you for the time
> <orie> should have its own topic call time
> Heather Vescent:  Think of CCG call as a place where we can
>   discuss these things.. if it's short term, we can use CCG slot.
> Orie Steele:  I'm not sure that's a solution to the VC HTTP API
>   problem.
> Orie Steele:  This is very clearly a Traceability call... we
>   don't spend a lot of time about VC HTTP API and LDS.
> Heather Vescent:  Trying to understand what you are transitioning
>   into a public venue.
> Orie Steele:  Regular recurring call for Traceability -- we've
>   set it up... we'll do intro.
> Orie Steele:  2Nd part, addressing VC HTTP API in regular call --
>   with stakeholders moving that forward.
> Juan Caballero:  Was just saying that, since we were talking
>   about API at next CCG, and at IIW, send out email next week...
>   Traceability call -- that group can talk about things it wants to
>   propose to VC HTTP API group, just as proposals, still need to go
>   to calls Manu is going to set up.
> <heathervescent> Lets do the CCG VC HTTP API call next week and
>   see where that goes.
> <orie> ^ yep
> <orie> traceability isn't just vc http api.... its got its own
>   issues.
> Juan Caballero:  Traceability vocab group will meet as often as
>   other Vocab groups meet, not as Task Force... maybe talk as
>   things in API -- usurp API authority to have its own timeline.
> Heather Vescent: Question: who is the lead for running/managing
>   *this* meeting (the Supply Chain tracibility and security call)
> Juan Caballero:  ...And IIW sessions.
> <heathervescent> And it is at this call regularily?
> <heathervescent> Can you do the intro next week? or you need more
>   time?
> <orie> we need this to eventually be more EU friendly
> Juan Caballero:  Procedurally - "Traceability Vocabulary Work
>   Item" -- that's it's primary focus, if it wants to talk about use
>   cases... that should feel secondary -- group that has been
>   discussing vocabulary - this has been it's regular time, Mike
>   started it, he is leading this group... Mike, Orie, Mahmoud are
>   Editors... keep call time, keep meeting, eventually, we have
>   folks in EU time zone, would like it earlier.
> Orie Steele:  We can cross that bridge when we come to it.
> Heather Vescent:  Orie, Mike, Mahmoud are in charge -- Orie...
> Orie Steele:  I'm the Editor of the spec both for VC HTTP API and
>   Traceability Vocab -- ping me on CCG list, will respond publicly
> <juan_(spherity_gmbh)> great
> Heather Vescent:  When you guys are ready, for intro for new
>   audience of people -- tell me, send me content, I will forward it
>   out as intro to the list. Show broader interest -- support, give
>   broader context, not clear w/ email that came through.
> <juan_(spherity_gmbh)> apologies for the crap email
> <juan_(spherity_gmbh)> that was all me
> Orie Steele:  I hear you, I will set this up w/ other Editors of
>   call...
> <juan_(spherity_gmbh)> awesome
> Heather Vescent:  Great, at your service to support, but do have
>   requirements.
> <juan_(spherity_gmbh)> great meeting
> <juan_(spherity_gmbh)> sorry gotta drop
> Heather Vescent:  Thanks all... Manu?
> <mahmoud> Thanks everyone
> Manu Sporny:  Yep, I feel better about this.
> <heathervescent> happy to run you through the process ofr
>   minutesm as well.
>
>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>