Re: [CDNi] Request for feedback on the 3 SVTA drafts presented at IETF116

["Goldstein, Glenn" <[e-mail]>]

Thanks for the detailed feedback Kevin. The 404’s on the SVTA document references will be fixed within the next week or so, as we are building out http://svta.org/documents/.


From: CDNi <[e-mail]> on behalf of Kevin Ma <[e-mail]>
Date: Monday, September 4, 2023 at 10:27 PM
To: Goldstein, Glenn <Glenn.Goldstein=[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [CDNi] Request for feedback on the 3 SVTA drafts presented at IETF116

CAUTION: This email originated outside of Lumen Technologies. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi All,

  (as an individual) I read through the protected secrets draft and have included some comments below.

thanx!

--  Kevin J. Ma

- abstract: "for ... that may be embedded" -> "to embed ..."

- section 1: "in both the FCI and MI" -> "in both the CDNI FCI and MI"

- section 1: "(support defined in this draft is specifically for HashiCorp Vault), which are accessed via a specified path and a key ID. Refer to HashiCorp Vault documentation for details." -> "(e.g., HashCorp Vault [reference])."  -- i'm not sure if we should really make a reference to a specific implementation here; could we describe it more generically as "and external key management system"?  counter argument: if we're going to create a registry and register HashCorp Vault, then it's probably fine.

- section 1: remove duplicate "uCDN issues a GET to receive an advertisement with FCI.SecretStore and FCI.SecretCertificate. As the uCDN has not yet provided a certificate, any embedded secret values in the advertisement are omitted."

- section 1: "uCDN issues a GET to receive an advertisement" -> "The uCDN receives an advertisement" - CDNI FCI (currently) is a push interface via ALTO.

- section 1: "any embedded secret values in the advertisement are omitted" - i think this could use a little bit more explicit explanation, e.g., the dCDN is not yet able to encrypt the secrets, so no secrets are provided.

- section 1: "uCDN issues a PUT to publish a configuration" -> "The uCDN publishes a configuration" - CDNI MI (currently) is a pull interface; alternately, this could be an invalidation/prepositioning trigger?

- section 1: remove " The configuration also contains MI.SecretStore and MI.SecretCertificate." ?

- section 1: "uCDN issues a GET to receive" -> "The uCDN receives"

- section 1: "the advertisement SHOULD now contain populated MI.SecretValue objects where necessary" - again, i think some addition context would help here, bothas to why secrets "SHOULD" now be populated, and why the qualifier "where necessary" is necessary

- section 1: a sequence diagram might help here.

- section 1: is "MI.LoggingTransportS3API" in a separate, yet to be adopted draft?  we may want to remove this to remove the forward reference.

- section 3.1, "secret-store-type" type: should probably quote "MI.SecretStoreTypeEmbedded" and "MI.SecretStoreTypeVault"

- section 3.1: should there be a registry for secret-store-types?

- section 3.1: why is "secret-certificate-id" in the MI.SecretStore object and not in the MI.SecretStoreTypeEmbedded object if it is MI.SecretStoreTypeEmbedded-specific?

- section 3.1: the example is duplicated in 3.2; can probably remove this one

- section 3.2: should there be a registry for formats?

- section 3.2: there is probably going to need to be must stronger wording around the usage (or prohibition thereof) of "cleartext"

- section 3.3: is "MI.SecretStoreTypeVault" HashiCorp Vault specific?  is there a way to make it generic to support AWS KMS, GCP KMS, and/or Azure Key Vault?  alternately, should the object name be made HashiCorp-specific?

- section 3.3: is there a reference for the definition of "namespace" and "version"?

- section 3.4, "secret-store-id" description: "The linked" -> "The ID of the"

- section 3.4: should we have separate objects for embedded secrets and HashiCorp Vault?  it seems odd to mix "secret-value" and "secret-path" in the same object.

- section 3.4, does one of either "secret-value" or "secret-path" have to be specified?  the MtSs both say no, but it doesn't make sense to let them both be blank?

- section 3.4, "timeout" description: "the specified duration" -> "this timeout"

- section 3.4, "timeout" description: "should be discarded" -> "MUST be discarded" or "SHOULD be discarded" ?

- section 3.5: "(CA)and" -> "(CA) and"

- section 4: I don't think we need to register separate types for FCI.  If the "FCI.*" object is identical to the corresponding "MI.*" object, this is just registry bloat?  there's nothing that says a "capability-type" must start with "FCI."; you can just use the MI payload types, as long as it is clear how to deserialize it.

- section 5: the SVTA2038 reference gives a 404.  again, i'm wondering if there is a way to make the proposed metadata objects extensible to other methods/services.

- section 5: remove duplicate "When the recipient of a secret provides an updated configuration that no longer contains an MI.SecretCertificate with an ID referenced in MI.SecretStore used by MI.SecretValue objects, those MI.SecretValue objects SHOULD be reduced to an object with no contained secret-value property as they would be in the initial state before any certificate had been provided."

- section 5: "in MI.SecretStore" -> "in an MI.SecretStore"

- section 5: a sequence diagram might help

- section 5.1: remove duplicate "The uCDN advertises FCI.SecretStore with a store-type of MI.SecretStoreTypeEmbedded; other FCI objects may contain MI.SecretValue objects that reference the store-id. MI.SecretValue objects that do not presently contain a secret-value property."

- section 5.1: "MI.SecretValue objects that do not presently contain a secret-value property" - this is an incomplete sentence?

- section 5.1: a sequence diagram might help

- section 5.2: remove duplicate "The uCDN advertises an FCI.SecretCertificate."

- section 5.2: a sequence diagram might help

- section 5.3: remove duplicate "An MI.SecretStoreTypeEmbedded has a defined format of "cleartext"."

- section 5.3: a sequence diagram might help

- section 5.4: the uCDN should use MI to provide config to a dCDN?

- section 5.4: the dCDN should use FCI to advertise to a uCDN?

- section 7.1: this obviously needs to be filled out.


On Thu, Apr 27, 2023 at 1:16 PM Goldstein, Glenn <Glenn.Goldstein=[e-mail]<mailto:[e-mail]>> wrote:
We received a good chunk of comments from Kevin on the Cache Control Metadata draft (https://datatracker.ietf.org/doc/draft-power-cdni-cache-control-metadata/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-power-cdni-cache-control-metadata/__;!!CdLFVIQ!VnUjuud-3stkqx-wuV4oQiwY6r15dUNiUlWt8WQa2cKcyoPHBVIIoUr_36DqbfyJ27xYhXATyw3oc3dm15eEpB5IpBY_oQ$>), and have addressed all the issues for the update that we will submit prior to IETF117.

It would be very helpful if we could also get some feedback from the CDNI WG on the other 2 drafts:
https://datatracker.ietf.org/doc/draft-rosenblum-cdni-protected-secrets-metadata/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-rosenblum-cdni-protected-secrets-metadata/__;!!CdLFVIQ!VnUjuud-3stkqx-wuV4oQiwY6r15dUNiUlWt8WQa2cKcyoPHBVIIoUr_36DqbfyJ27xYhXATyw3oc3dm15eEpB4fp3W71w$>
https://datatracker.ietf.org/doc/draft-siloniz-cdni-edge-control-metadata/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-siloniz-cdni-edge-control-metadata/__;!!CdLFVIQ!VnUjuud-3stkqx-wuV4oQiwY6r15dUNiUlWt8WQa2cKcyoPHBVIIoUr_36DqbfyJ27xYhXATyw3oc3dm15eEpB6x82hQfQ$>

thanks,
Glenn

This communication is the property of Lumen Technologies and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
_______________________________________________
CDNi mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cdni<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/cdni__;!!CdLFVIQ!VnUjuud-3stkqx-wuV4oQiwY6r15dUNiUlWt8WQa2cKcyoPHBVIIoUr_36DqbfyJ27xYhXATyw3oc3dm15eEpB6Yp9BL3g$>
This communication is the property of Lumen Technologies and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.