Code change:
SCITT architecture.  Its goal is to enhance auditability and accountability across supply chains. <del> In supply chains, artifacts travel down the chain until they are eventually consumed by someone.  Consumers like to have information about the artifacts that they consume.  There are many parties who publish information about artifacts: For example, the original manufacturer may provide information about the state of the artifact when it left the factory.  The shipping company may add information about the transport environment of the artifact.  Compliance auditors may provide information about their compliance assessment of the </del> <ins> In supply chains, downstream artifacts are built upon upstream artifacts.  The complexity of traceability and quality control for these supply chains increases with the number of artifacts and parties contributing to them.  There are many parties who publish information about artifacts: For example, the original manufacturer may provide information about the state of the artifact when it left the factory.  The shipping company may add information about the transport environment of the artifact.  Compliance auditors may provide information about their compliance assessment of the </ins> artifact.  Security companies may publish vulnerability information <del> about an artifact.  Consumers may even publish the fact that they consume an artifact. </del> <ins> about an artifact.  Some of these parties may publish information about their analysis or use of an artifact. </ins> <del> SCITT provides a way for consumers to obtain this information in a way that is "transparent", that is, parties cannot lie about the </del> <ins> SCITT provides a way for Relying Parties to obtain this information in a way that is "transparent", that is, parties cannot lie about the </ins> information that they publish without it being detected.  SCITT achieves this by having producers publish information in a <del> Transparency Service, where consumers (also called Verifiers) can check the information. </del> <ins> Transparency Service, where Relying Parties can check the information. </ins> 1.1.

Related discussion:
text: Related mailing list thread: URL
these changes make sense to me
As part of , I would like to consider the removal of Consumer and consumer from this specification if we are not going to define it. It is a generalized term and I would rather expend work group time on trying to tailor an appropriate custom definition of it. I will likely post this issue to the mailing list and cross-reference that thread here and leave this issue for review for a week to solicit feedback. Related mailing list thread: URL
I do think Producer and Consumer is a good generic concept, with more clearly defined roles as Relying Party, Verifier, and Auditor, however, I'd support replacing Consumer with Relying Party or Verifier.
But we do not define them nor cite references that do. From a formality and procedures perspective in IETF, is that OK? Thanks for the feedback.
LGTM with some comments to accept/reject Hello, I have been reviewing the specification and there are usages of Consumer(s) as a specific term to be defined in the draft and consume/consumer(s) generically. The use of the term consumer is ill-defined and I would support not consuming time ahead of 119 defining it. Therefore, I am proposing that we remove the capitalized term and some generic usage of it for clarity. I welcome feedback on the pull request to alter or critique specific, individual changes (207), the issue to track the work for more general discussion (206), or in the form of replies in this thread on the mailing list. URL URL If I do not hear back in one week and there is no objection in the pull request, the issue, or mailing list, I will follow up and ask the authors to merge (if it has not been merged already). Thanks in advance for your review and any feedback you provide. Thanks, A.J.