Apologies for not turning this around sooner.  Structure wise, the model is
fairly sound.  Most of the comments below are either nits/wording, slight
adjustments and questions/clarifications.

1 module in this draft:
- ietf-mud-transparency@2021-07-06.yang

No YANG compiler errors or warnings (pyang 2.5.0, yanglint 2.0.88, confdc 7.2.3.4)
- L#364: CODE BEGINS : filename must be defined on same line for tools such as
  rfcstrip to correctly parse the module contents

Module ietf-mud-transparency@2021-07-06.yang:
- import `ietf-inet-types` should reference RFC 6991 per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
- import `ietf-mud` should reference RFC 8520 per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
- L#016 - Minor nit: looks like L#17 should be moved up here
- L#018-020 - Minor nit: adjust email address formatting per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
- The type and enum members are identically defined for
  `sbom-local-well-known` and `vuln-local-well-known`.  Is this something you
  can leverage by using a typedef or a grouping or is there intention to keep
  these separately defined?
- When retrieving say an 'sbom' from the device, is it assumed that it be via
  `sbom-local-well-known`?  What if it is necessary to host this on an
  alternate port for one of the communication protocols chosen?  Would this
  scenario then best use `sbom-url` to define a static URI? (Same question
  applies to vuln as well)
- Independent of the answer to the above question, is `cloud` the best choice
  or wording for the other case statement under the retrieval method choices?

  It seems to be that we have 3 cases for sbom/vuln retrieval methods which
  correspond to the draft wording at L#176-180 which seems to not pair
  identically.

  * on devices themselves: Could be /.well-known/ or a static URI could it
    not?
  * on a website: Static URI only
  * out-of-band: Static URI only - should this leaf be named something closer
    to that vs. 'contact'?

General comments on the draft/modules:
- L#0021: s/provide access this/provide access to this/
- L#0117: s/bills of material/bill of materials/
- L#0627: JSON example needs correct prefix for the augment
  `ietf-mud-transparency:transparency`
- L#0941: s/not be/not been/
- L#0961: s/authoration/authorization/
- Since `ietf-mud-transparency` imports `ietf-inet-types`, a normative
  reference must be added per
  https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-3.9