ietf-scitt / charter

Documentation of initial IETF Supply Chain Integrity Transparency and Trust (SCITT) WG Charter
6 stars 13 forks source link

out-of-scope polish #4

Closed henkbirkholz closed 2 years ago

henkbirkholz commented 2 years ago

From @OR13:

https://github.com/ietf-scitt/charter/pull/3#discussion_r908645633

interop on query retrieval remain a concern... can we refine this / split these apart?

OR13 commented 2 years ago

@kaywilliams any thoughts on this part? How can I help refine this issue?

kaywilliams commented 2 years ago

Thanks for flagging this, @OR13. I missed it when I reviewed the merged charter earlier today. @henkbirkholz, I would like to discuss removing or refining item #4. In the last BoF, several parties noted that protocols for storage, query and retrieval of supply chain content/claims/endorsements were important to provide an end-to-end solution for supply chain compliance. My impression is that these parties will be proposing such protocols, at any rate, and it would be helpful for these to be included in the SCITT effort as they relate to the end-to-end problem space.

knight-brian commented 2 years ago

Removal of Non-Goals #4 seems acceptable. And, we should specify that interoperable transparency service protocols are in scope. Perhaps as part of the Program of Work consolidation effort?

henkbirkholz commented 2 years ago

This would be some chunk of work, right? Maybe that is a BoF discussion? There are also related topics, like standardizing "things" somewhere in the space from the "inner shell" that is the issuer signature envelope and the "outer shell" that is the transparent claim. These "things" would be in support of such "query and retrieval procedures". Again, that does not sound like a small detail, at least w.r.t. initial scope. Not objecting, just highlighting.

knight-brian commented 2 years ago

I agree with the possible hazard of scope expansion, so perhaps we craft the charter like the draft: TS API for messages (registration and retrieval)? The WG can consider additional appetites.

OR13 commented 2 years ago

Simplest improvement is to simply remove the "query / retrieval" bit and leave the "storage" bit.

henkbirkholz commented 2 years ago

Having pondered this a bit and taking into account that we have an IANA registry for "storage types" now on the roadmap and that we might pull in a content format hint, I'd like to propose changes to 4. and 5.:

Does that read okay?

kaywilliams commented 2 years ago

Agree with removal of 4. For 5, can we make a generic statement instead such as 'define data formats for payload content, such as Bills of Materials data formats'?

henkbirkholz commented 2 years ago

[edit: my previous reply made no sense] using Kay's suggestion as as in PR #18