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

Hi All,

   (as an individual) I've reviewed the updated cache control draft.
Additional comments below.

thanx!

--  Kevin J. Ma

- section 3: is "internal" mandatory-to-specify if "force-internal" is
specified?  similarly, is "external" mandatory-to-specify if
"force-external" is specified?  or, is the intent to support forced
clearing of the cache control policy?

- section 3, "internal" description: "to be used" -> "that MUST be used" ?

- section 3, "external" description: "to be used by" -> "that MUST be
returned to" ?

- section 3, example 3: the link to SVTA2032 gives me a 404 not found?
 assuming that is resolved, and SVTA2032 adequately describes
MI.OriginResponseState, i'm not sure this example is necessary.  it doesn't
enhance my understanding of how to parse the MI.CachePolicy.

- section 4: "useful when there a" -> "useful when a"

- section 4, "error-codes" description: "or one of the special" -> "or any
of the special"?  "one" implies to me that i can only pick "4xx" or "5xx"
but not both?  also, ignoring the obvious redundancy inefficiencies, is
there any concern with specifying duplicate (e.g., ["404, "404"]) or
overlapping (e.g., ["404", "4xx"]) values?

- section 4, "error-codes" MtS: "MAY function" -> "functions" or "MAY be
used".  though the use of this functionality is optional, the actual
override functionality is not optional.

- section 4, example: perhaps add an "xx" to the example?

- section 4, example: "origin.." -> "origin."

- section 5: "to use by a dCDN" -> "the dCDN MUST use"?

- section 5: "content be served" -> "content MUST be served" or "content
MUST only be served"?

- section 5: what is the relationship between "stale-while-revalidating"
and "failed-refresh-ttl"?  the latter is how long to wait until
revalidating, and the former is what to do before revalidating?  I found it
confusing, specifically because the "failed-refresh-ttl" MtS sections
states: "The default is zero, in which no stale content is served.", but if
true, example 1 doesn't make sense?  perhaps the "failed-refresh-ttl" MtS
section needs a further qualification?  does "failed-refresh-ttl" only have
meaning if "stale-if-error" is specified?  it is also not clear to me what
the difference is between "revalidating" and "refreshing" (they seem to be
used interchangeably in example 3, if so, should we make it consistent)?

- section 5, "stale-if-error" description: "or one of the special" -> "or
any of the special"?  "one" implies to me that i can only pick "4xx" or
"5xx" but not both?  also, ignoring the obvious redundancy inefficiencies,
is there any concern with specifying duplicate (e.g., ["404, "404"]) or
overlapping (e.g., ["404", "4xx"]) values?

- section 5, "stale-if-error" MtS: "may function" -> "functions" or "MAY be
used".  though the use of this functionality is optional, the actual
override functionality is not optional.

- section 5, example 3: the indentation is off (two extra spaces) for
"stale-if-error" and "failed-refresh-ttl".

- section 6, are the "ProcessingStages" necessary for this draft?  could we
just describe the "MI.CacheBypassPolicy" without the "ProcessingStages".
SVTA2032 is not a normative reference, but the encoding examples seem to
make it normative.  i think it would be simpler to leave the processing
stages out of this draft?

- section 7, example 3: the link to SVTA2031 gives me a 404 not found?
 assuming that is resolved, is SVTA2031 normative, i.e., do i need to
understand SVTA2031 to parse "expression"?  "expression" is defined as a
String, so technically i can parse it and store it as a string, but the
type description says "An expression using the Metadata Expression Language
(MEL) [SVTA2031]".  perhaps we could soften this language to allow for
other strings and make it more generic?  should it support different
expression languages?  would we want it to be extensible (e.g., have an
additional type field)?

- section 8: i don't think a conclusions section is necessary

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

On Thu, Apr 27, 2023 at 1:16 PM Goldstein, Glenn <Glenn.Goldstein=
40lumen.com@dmarc.ietf.org> 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/),
> 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://datatracker.ietf.org/doc/draft-siloniz-cdni-edge-control-metadata/
>
>
>
> 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
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni
>