remove bikeshedding about re-using npm-ls

Signed-off-by: Brian DeHamer <[email protected]>

Author: bdehamer

accepted/0000-sbom-command.md

@@ -156,12 +156,6 @@ As it relates to the CycloneDX SBOM format, much of the capability described as
 
 ## Unresolved Questions and Bikeshedding
 
-* There’s a case to be made that SBOM generation should just be a flag on the existing `npm-ls` command – an SBOM is really just a different format of the output already generated by `npm-ls` (in fact, the CycloneDX tool described above parses the output from `npm-ls` in order to generate its SBOM). However, many of the arguments supported by `npm-ls` don’t really make sense in the context of SBOM generation (package spec filtering, depth, etc…) so it feels like a bit of an awkward fit. \
- \
-Making it a distinct command allows us to add SBOM-specific features in the future like a `--sign` flag which could be used to generate a signed SBOM. \
- \
-_Recommendation: Add a distinct command for generating an SBOM._
-
 * Does `npm-sbom` command have a notion of a “default” SBOM format? Do we give preference to one of CycloneDX/SPDX or do we remain totally neutral (possibly at the expense of DX)? \
  \
 _Recommendation: Remain neutral with regard to SPDX vs CycloneDX. Make the `--sbom-format` flag mandatory.