# IETF 121 CDNI WG Meeting * Notetaker: Jay Robertson * Sanjay: CDNI Metadata for Delegated Credentials * Published RFC9677, split into two parts, one of which is RFC9538 * Congrats to Christoph, Emile, Guillaume, Frederic * Kevin's reviews have helped * Francesca helped * Sanjay: Capacity Insights Extensions * Ben published v10 on Oct 23 * Addresses open comments * Waiting for IESG Telechat review on Thu Nov 21 * Guillaume and Andy Ryan had concerns to be addressed, best course would be to work on a draft and submit to the working group * IANA registration - Can add additional items in this draft * CDNI Protected Secrets & CDNI Logging I-D * Dilemma: How to deal with 3rd party dependencies that are not open standards? * Categorize dependencies * IETF Internet Drafts (unencumbered) * Area in-between--things that are well-documented and adopted thru industry by many companies or in OSS, not a standard by well used * Things encumbered by patents (completely unusable) * How we use them * Dependent on specific features or documented language to that outside dependency, impossible to specify what it is in the draft * Others are mere references * Logging Extensions: * S3 transport in logging draft--not reliant on anything in S3 interface * Including a reference to it so know what we're linking to * Provide objects (key-value pairs) * Use of that interface is outside of that logging draft * Kafka is another example * Protected Secrets: * Hashicorp Vault (now open source) * AWSv4 auth * Talking about this thing, it is over there, here is a link to it, and here are some key-value pairs, not utilizing any of the details * Prometheus exposition format--example of documentation, but anything we're doing with it is not reliant on format itself * Chris: Feels very weird to have normative dependency on private 3rd party interfaces * Doesn't think that he agrees that it isn't a normative dependency * Hashicorp: URI and basic auth info * Anyone implementing URI has to know the details of that protocol * Reference to those API documents not version controlled * Controlled by third party * Anyone using integration protocol must comply with what documents say * Does not feel right for IETF standard * Document as it stands doesn't break any specific rules--can do it if we want to if think we can convince IESG * Hashicorp: Only transit we have * If we are implementing this, that's the only thing that there is * 3P depdencies should be published, but this probably not the right place to publish them * Would prefer them to be registered with IANA or an appopriate standards body like SVTA * Ben: Definitely hear you * Pointed out no version control but Vault references specific version of Vault KV interface * For these documents to be useful, need to support the software and services that people are actually using in production * Without direct support for that, question utility of drafts at all * Mentioned SVTA, but no one is going to implement CDNI version of this with SVTA * Just going to use SVTA version instead which defeats purpose of publishing in CDNI * Vault is only reference in secrets, only one who worked on that and not familiar with other services * Invites others to participate * IANA registry not guarantee of that versus rigorous review in WG * Chris: Not effectively being reviewed in this body * Reviewing the form of the specification, the URI that is there * Would feel better if not the only one * Okay moving forward and seeing if IESG feels this way if he is the only one who feels this way * Sanjay: What if we had participation by this 3rd party? * Different aspect to the conversation? * Would something like that help IESG make an informed decision? * Chris: Don't think that they care, and we don't care what they think * Ben: Also don't think that applies to things we're currently referencing * Hashicorp has a license for use of their trademarks which cover our use case * Same is true for Amazon, fair use * Chris: If had a specification that required Microsoft Word, why would you do that? * Poll: Should this working group include 3rd party dependencies like Hashicorp Vault in documents that we publish (yes or no)? * 7 yes, 1 no, 3 no opinion, results in room are unanimous with exception of Chris * Will publish to the mailing list * Francesca: Shepherd write-up is place to put consensus decisions * Sanjay: Applies to both the drafts * Ben: Drafts could use review in general, but especially secrets draft since hasn't gotten much activity, anything with security has serious review * Sanjay: All participants here, please review every document because they are WG drafts, need rigorous reviews * Guillaume: Just wanted to add fact that references to 3P specifications are accepted for any CDNI draft * Doesn't preclude the fact that need to point out a spec * S3 doesn't mean anything if don't point out a spec to explain S3 * Chris: CDNI recharter * Chris: 2 documents before us, carefully read through * Does not fall within current Charter * Significant interest in group toward advancing documents * Would like to recharter group * Can't do: * Processing Stages draft: Defines new content for error messages, splash pages, etc. * General-purpose way of creating new content * Does more that mutating content * Metadata Extension Language: Useful for a number of other documents * Put it all in one document, get better review, charter needs to be expanded for this work * What oughtn't we attempt? * Define interfaces for things beyond CDN interop * Define general-purpose templating language * Proposed Language: * Adding 2 elements to bottom of existing list (read aloud) * WG will not define general-purpose templating language * No interfaces for communicating general-purpose computational workloads * The above will require rechartering if necessary * Suggesting that these exact words should be added to the charter as is * Sanjay: Should focus just on what charter is? Many things that WG will not do * Chris: No cheese-making for example, want to specifically state that we're not trying to do, setting an upper bound * Sanjay: Sentiment in the right place, language as general-purpose templating language, is this too broad or wide? * Chris: Would be appropriate for group to define general-purpose templating language? * Sanjay: Depends, for CDN it is, but not for making cheese * Guillaume: Happy with what we have right now * Specification for CDNI Metadata interface, language must be created for that * Language is used, fits with the items in the charter, don't think it is necessary to expand the charter * Finely defined list of topics that groups can address * Guillaume has conversation about APIs, would require a new charter? * Not a strong opinion * Chris: Developed language after feedback that going beyond bounds of charter, good feedback * Ben: Thanks Guillaume for putting that out, agree with Guillaume * Covered by existing language, powers that be disagree with that, so have to add these new items * Also agree with Sanjay of why we have to define negative, we're already not doing that, and it is already not in the charter * Francesca: Make sure what we're doing is in the charter * Refining this language to make sure no doubt that this work is in charter * Possible that could move document forward * If there is a doubt that in charter, then worth doing this work to cover all bases * Why proposal was brought up, additional work, review, etc., but makes sure we're all on the same page, so worth doing * Defining what we don't do sets very clear boundaries, might be clear to participants of WG, but clearly scoping what we're trying to do * Rest of IESG might wonder, why it is helpful, like having that text, doesn't hurt to have text there * Chris: Risks for being out of charter * For processing stages, current charter defines interfaces for delivery of content, but not mutation or creation of content * Mutation arguably in scope, but not creation * For MEL, if this were the only thing, this would be in charter, need MEL to define how interfaces work * If MEL were just one section of a document, not sure anyone would blink at it * If we're going to go through rechartering, should make it crystal clear so we don't have to have this conversation * Creation of content to return to clients is clearly out of charter * Alan: Creating of content, have been very precise about it, generation of error and error codes, where do we stop * Proposed language around MEL being more broadly used, don't want to become generic template language * Too narrow for purposes, want to limit to CDNI framework, but would not narrow to one particular interface * Want to use MEL as broadly as possible * About what we're doing/not doing, if we feel need to say what it is not, may not be properly defining what it is, what are we saying that we're not doing? * Part of processing stages, value to refer to external interfaces, should be in scope, need to define more succinctly what we are doing and not doing * Chris: Hearing an argument in favor of defining exactly on the list? (Head nods) * Sanjay: Language as written is too wide, take it to the mailing list and determine what proposed language should be * Chris: Summarize--perhaps too overzealous with defining what won't do * Want to define more precisely what we will do * Bring it to the list and have a discussion there * Concensus call there * Francesca and Sanjay agree * Don't need Chris's last slide, got clear answers * Jay/Alan: CDNI Control Interface and Triggers * Jay: Introduced progress on v15, outlined what changed, clean-up in progress under v16 * Alan: Presented changes in v15 * Trigger Object: Moved to architecture where parties exchange presentation of one object * uCDN takes object, changes, returns it back * Still allowing support of v1, introduced MIME type, client may use both or either and doesn't have to differentiate the payload by using MIME type * Trigger status being replaced by state so now we talk about this * Simplification of the language, danced around previously, probably the main change in the draft * Trigger Collection: Merged trigger objects and filtered collections into trigger collections * Can now get all triggers in 1 API call, also by state and by label, separation of namespaces * Streamlined Document Structure: multiple chapters merged, flows better * Depth of ToC at 4 letters instead of 3, trying to figure this out, would appreciate XML guidance * JSON fixes: More minor changes, snippets and examples * All has been cleaned up and passed validation * Common format * Minor fix for content-objectlist * Purge/invalidation of acquisition in progress: Document was lax in timing, no saying when and how dCDN will process, * If trigger purge requests arrives while dCDN is acquiring, this creates a problem * Request started, before purge, so should be purged * Would be unintentionally added to the cache if we're being too liberal with timing * Now dCDN should not place this content into the cache * Presented planned changes for v16, boldface items still need to be completed * Jay: Need to complete v16, emphasized need for more reviewers, goal to ask for WGLC at IETF 122 * Sanjay: No comments, v15 is looking better in terms of cleanup, v16 is looking really good * Alan: Named Footprints * Alan: Presented Objective, promoting to an object that can be ussed more broadly * FCI Problem: FCI itself defined in RFC8008, defines attributes but not interface * RFC9241 defines interface using ALTO (RFC7285) * Draft defines metadata object, but no ALTO-less method * Missing RESTful FCI interface definition that can expose named footprints without ALTO * Proposed Solution: Bring forward separate draft, 4 different interfaces, bootstrapping, footprint & capabilities, configuration, and cache management * Would expose footprint URIs, metadata objects can be used in FCI as well as in other interfaces * Proceed with named footprints draft as alternative to ALTO * v121 Next steps: * Previous IETF was support for very large footprint advertisements * Draft for interfaces and named footprint itself * Provide more language around FCI and Alto in draft * Some comments to be incorporated * Now that MEL is on agenda for chartering, use of MEL for definition of footprints * Use of MEL to be extended, so can be used as footprint definition language * Chris: Agrees with approach, need to be clear with approach and charter, make sure httpdir review before we go to last call for RESTful interfaces draft * Alan: Work done on triggers would be a good basis for this draft as well * Alfonso: Edge Control Metadata * Alfonso: Presented Abstract: defines metadata objects for controlling edge adge access to resources, CORS, compression rules, connection Timeouts * v02 Recap: after comment from Kevin Ma, won't go through this again * Comment from Kevin Ma on separate examples in different section, would it better to have a section for example? * Chris: Likes seeing a separate section, but no hats on, completely aesthetic * v03 will be uploaded for MI.PatternMatch from RFC8006, reference instead of literal specification in draft, from IETF-120 * Next steps: Uploading v03 with these 2 things * Is good for WGLC? * Sanjay: Good plan, please submit v3, chairs will review it, additional reviews will help, will be discussed in mailing list * Guillaume: Control Interface, HTTP REST API * Guillaume: Presented Overview: new CDNI internat draft for HTTP API * Have control trigger interface, but that is it * New REST API for different interfaces * Complements CI/T interface * CI/T based on pull model * Forces uCDN to implement and expose HTTP endpoint * Complexity * No API for FCI and bootstrapping * Proposal: New set of REST APIs * Two modes of operation: synchronous and asynchronous * Complements CI/T interface * Covers entire Control interface * Briefly presented examples: * Footprint and capabilities example * Configuration example * Configuration on a host basis or path pattern basis * Operate ci-trigger-status, rely on as part of REST API * Notification service * Bootstrap API--subject of new draft, showed data model * Cache Management, new API for cache buckets, as well as CI/Tv2 * Showed simple workflow example * Sanjay: When plan to submit draft? * Guillaume: Working on it for APIs in same document, translate into IETF draft document, not before end of year but beginning of next year for sure * Guillaume: Request Routing Redirection Interface (RI) extension * Guillaume: Presented Overview: Expand capabilities in RFC7975 * Support of manifest rewrite * Simple HTTP proxy request mode * Do not extend DNS Redirection * Problem: * dCDN can only provide URI for redirection, no support for manifest rewrite * Request router has no possibility to access content source * Proposal: * Propose way to forward request, submit response to dCDN over request routing interface * Request-driven mode: uCDN acts as a HTTP proxy forwarding the request to the dCDN * Response-driven mode: Want to extend request routing interface to add more capabilities, possibilities, recursive mode in CDNI * Alan: Cache Management Interface * Alan: Have published SVTA Cache Mgmt Interface v1.0 (SVTA2046) * Covered scope * Interface relies on and extends CI/T v2 * Added metadata objects for priority, tagging, storage placement * Cache buckets, new RESTful interface * Extended CI/T v2: prepositioning, purge, scheduling * Plans: * CI/T v2 draft in progress * Named footprints metadata in progress * Planned; RESTful interfaces * Planned; Cache management metadata * Planned; CI/T v2 extensions * Goal: Introduce before next IETF * Chris: No hats, cache groups work in httpbis? Review draft, should be useful for defining cache bucket * https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache-groups/