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

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.

Received on Tuesday, 13 April 2021 20:13:31 UTC