Ballot for charter-ietf-apn
Block
Yes
No Objection
Abstain
Note: This ballot was opened for revision 00-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
Thanks for addressing my previous concerns. I think we have progress but I am keeping this as a Block for now because I continue to be worried that the scope of the group is not all that clear from reading the charter, and that using more words in the charter isn't helping with that. My own simple-minded understanding from the charter, plus from reading draft-li-apn-framework and draft-peng-apn-scope-gap-analysis, is that APN is: - A (presumably fixed-format) header field with more bits than DSCP gives us, - Definition of how to use those bits in the forwarding plane, and - Signaling extensions for programming the forwarding plane to use those bits. I guess maybe the current charter is tasking the WG to build a framework that elaborates on those bullet points. Is that right? If so, perhaps we can iterate towards tightening up the text, into something that will be more likely to hold up to external review.
As a first step I recommend removing this paragraph: ``` In modern networks, where things such as deterministic networking and networking slicing are required, there is a requirement for more functionality than QoS can provide. APN aims to address these requirements and further unleash these technologies. The goal is to provide network operators with the ability to perform fine-granularity network service provisioning, as opposed to course-grained traffic operations. ``` It appears to be redundant with the one that follows it, furthermore it raises concerns by naming technologies that already have other working groups that develop them, without being specific about what their connection is to the proposed APN WG. So, better to remove the paragraph.
How does "Application-aware Networking" turn into the (APN) acronym ? How is this different from existing labeling or encapsulation methods, dead or alive ?
Thank you for addressing most of my previous concerns. Unfortunately, this additional text raises more questions for me. I share similar BLOCKING concerns outlined by my fellow ADs around scope: -- (Similar to Rob Wilton on 00-00 and John Scudder on 00-01) The current text of the charter doesn’t constrain the solution space and seems like it could cover extending just about any protocol or defining a new one up and down the OSI stack. As inspiration, consider the specificity of how DETNET bounded their solution space. -- The definition of an “APN domain being a Network Operator or set of cooperating Network Operators, in which MPLS, VXLAN, SR/SRv6, and other tunnel technologies are adopted to provide network services” doesn’t seem very limited and could be read an any co-tenants in an IXP (so good parts of the Internet). Per the discussion of security properties ("Within any developed framework, security and privacy must be carefully considered"), this seems like a restatement of the procedural requirement "that all documents will security considerations." Agreed. What would be clearer would be to describe in a very broad sense privacy or security "guarantees/targets" this WG would design for relative to the equities of the operator and the user.
I also share concerns outlined by fellow ADs around prior art (Paul Wouters on 00-00, Rob Wilton on 00-00, Eric Kline on 00-00) that aren’t resolved with the new text.
Reading the latest version of the charter, I agree with my fellow AD colleagues that it needs more clarification and the scope seems like really broad. So, I agree and support with other AD's block points. I would like to add some more issues that I think need to be taken care off before going for external review : - It is not clear to me why active measurements defined in IPPM would not be sufficient for the performance measurement. The https://datatracker.ietf.org/doc/draft-peng-apn-scope-gap-analysis/ talks about IOAM flow ID only without explaining why this is not good enough for the APN domain or describing what "more various purposes" are. It does not take into account the active measurement methods. - It talks about modern networks and relates to deterministic networking, but don't we have detnet working group to take care of the deterministic network? what are the requirement that detnet working group can't handle? what would be the relation between this working group and detnet working group? - I also don't understand the network slicing related requirements, it should be somehow described in shot to make sense of this claimed requirements. - Recently I commented on the draft about elaborating the use of "modern" in case of DNSSEC. This applies here too, it would be helpful to actually describe the characteristics of this "modern network" rather calling it modern. May be here the working group would be working with their own definition and particular characteristics of a modern network. Describing them in short might help understand the scope and relevant requirements. - All the examples given for "the various application being carried by a modern network" are about end to end experience. Say a portion of the network is APN domain on that end to end path. If things are bad outside that APN domain the end user experience would be anyway have bad QoE not matter how hard the APN domain (by the way this APN domain seems also not a very clear concept) tries to full fill the SLA. So, what would be goal here to have the limited APN domains? To that point In TSV ares we are publishing concepts like L4s which is are very general approach to treat the low latency required traffic in the network queues to ensure better end user QoE. - I also agree with my IESG colleagues that if the goal of this working group is to describe problem statement and usecase leading to define (an) APN framework, meaning we are not sure about the problem itself, then this charter tells us that there is already a solution in mind. Almost feels like a we have a solution and we trying to find problem that could be solved by that solution, which may not be the intention here.
[updated for -00-01] I concur with the points in the various BLOCK positions. There's no need for me to add my own; I support those. The first paragraph appears now to include two sentences that both take a run at defining "APN domain". Which is right?
# Internet AD comments for {charter-ietf-apn-00-01} CC @ekline ## Comments I'll Abstain on this round, as many others have made many fine points. I did think there was some improved text here, so thank you for that. As I read this version, I mostly noticed the paragraph order and explanation flow: * The third paragraph seems like a much better explanation of goals, thank you. * It seems like the 2nd and 4th paragraphs share quite a lot similarities. * The 1st and 5th paragraphs seems somewhat related. As such, I played around a bit with the structure (locally), and perhaps these suggestions might be helpful for structure (or perhaps not). I'd suggest trying to the following exercise: [1] reordering the current paragraphs in the following order: 3, 4, 2, 1, 5, 6, 7 (then Milestones...) [2] go through the paragraphs in this new order and join, trim, de-dup, and reflow text so that it progresses logically (i.e. doesn't jump around in the introduction and definition of terms and concepts) [3] consider ditching the "application-aware" name. If you'd like to keep the APN initialism then perhaps something that still captures the goals of -01 paragraph 3 might be: "Augmented Performance Networking" ...or something. ## Nits * "fine-granularity" might be changed to "fine-grained"
I would like to thank the proponents for adding additional detail to charter. However, several of my original concerns still remain (and I've added a couple more, that may have already been flagged by other ADs). My overriding concern is that I don't think that we should charter a WG to work on a problem statement and framework, when there will be a default assumption that the WG can subsequently be rechartered to work on a solution without a further BOF. For me, this concern is amplified because I don't really understand exactly what problem is being solved, nor what the shape of the solution will be. The current path effectively seems to bypass the standard BOF process, and I'm far from convinced that there would currently be community consensus behind chartering this WG as it stands. I have a few suggestions for alternative ways forward rather than chartering an APN WG: (1) Progress the Problem Definition and Framework documents as Informational documents within the RTG WG, perhaps making use of a design team. Then the proponents of the work could hold a BOF once it is understood exactly what problem they are solving and the shape and constraints of the solution that they propose. (2) Create a different WG, where the name and acronym are very clear (e.g., APNPDF = APN Problem Definition and Framework WG) that is specifically only chartered on defining an APN problem definition and solution framework and that *must* shutdown after the two documents are completed. A new separate WG (e.g., APN), most likely requiring a separate BOF, would be required for the IETF to work on any solutions, if needed. (3) Hold a WG forming BOF on APN covering working on a solution to the APN problem. However, for this to be successful, I think that it would need a much more concrete description of what the actual problem is being solved and the constraints on that solution. (4) Work on this problem space within the IRTF, at least until there is a better understanding about what the problem being solved it, and what the solution looks like. Specifically, on the charter, these are the other problems that I still have with the current charter text: 1. I find this charter to be overly broad, e.g., I suspect that it would be possible to standardize an entirely new version of IP within the current charter, which is presumably not the intent. From the supporting comments in the RTGWG poll, many of those interested in working on this indicated that the problem being solved is very well understood, so I think that it would be helpful for a more concrete description to be put into the WG charter text, and also to put more shape on the outline of the solution. 2. I'm concerned about the security/privacy aspects of this work. Rightly or wrongly, TLS WG is trying to standardize ECH to remove user identifying metadata from the flow, whereas this looks like a tool that could reduce privacy (and perhaps by implication, end-user security). Note, I'm not opposed to having some information shared between a client-application on behalf of an end-user and the network that they are connected to, but I think that there needs to be more work to investigate what data can/should be shared and balance the constraints between user and network. 3. I struggle to see the APN header as strictly being a limited domain when an APN domain is allowed to span a set of cooperating network operators. E.g., does this mean that the entire UK could be setup and regarded as a single APN domain. 4. The charter states that the information is derived from existing information in the packet headers at the edge of the APN domain. How would it enforce that the information cannot also be based on other meta-data (e.g., the ingress port and VLAN that the packet was received on). Basically, it feels like the packet could end up carrying more information in the APN header than what is already in the packet. Regards, Rob
Some of these comments may overlap with ones made by others. I am not balloting BLOCK because others can hold those positions -- I support the point that the charter needs clarity. Comments: > Application-aware Networking (APN) Working Group will develop a framework to > provide fine-granularity services within the APN domain. [nit] s/Application-aware Networking (APN) Working Group/The ... > Applications have different requirements of the network in terms of > bandwidth, latency, jitter, packet loss etc., and a desirable network should > be able to provide fine-granularity services to guarantee different SLA > requirements. APN WG is targeting to fulfill such requirements. The framework > needs to define these services and the expected outcomes. [nit] s/requirements of the network/network requirements [] "APN WG is targeting to fulfill such requirements. The framework needs to define these services and the expected outcomes." The target of this WG is not to fulfill the requirements but just to develop a framework. IOW, the outcome should not be "how" but just "what is expected". Given that people have argued that multiple (mainly existing) solutions could address the problem, we should ensure we're all on the same page -- and there is consensus about it. I like how the framework is characterized here ("define these services and the expected outcomes") vs. how it is described in the first paragraph ("provide fine-granularity services"). Defining what is expected is different from how it should be done (which is how I interpret "provide fine-granularity services within the APN domain"). What is the difference between a framework and an architecture? I think of architecture as the document that tells us how without the protocol specifics. In this case, it might say that each packet will carry an ID, etc. OTOH, the framework is just a description of what is expected. We don't need to argue about whether my description of framework vs. architecture is ok or not -- the point is that the expectations are unclear. Will the WG describe a class of solutions or just expectations (so that solutions can be proposed later)? > APN info carried in packets is applicable only within a limited trusted > domain, such as a network operator controlled domain. The purpose of APN info > is to achieve fast and reliable services, and the approach to determine APN > info MUST NOT rely on the knowledge of specific applications. APN info MUST > be removed when the packets leave the APN domain. Both security and privacy > MUST be carefully considered in this framework. [] Given the APN discussions so far, the intent is to put an APN ID in the packet -- this paragraph assumes that solution. However, there can be other ways... The point is that the framework (describing the expected outcomes) should be used to (later) specify solutions -- the charter shouldn't pre-assume what those solutions may look like. [] I don't remember a charter using rfc2119 keywords. The same effect may be achieved by describing: ...is required to not rely on... [] Besides specific applications, specific users (or user ids) should also be called out explicitly as not being required. > The APN working group is being chartered as a limited working group to create > the APN framework. Following the creation of the APN framework, the working > group MUST be re-chartered before further work if required commences. [] I don't think this last paragraph is needed.
# GEN AD review of charter-ietf-apn-00 CC @larseggert ## Comments ### Paragraph 0 ``` Application-aware Networking (APN) Working Group will develop a framework to provide fine-granularity services within the APN domain. ``` What's an "APN domain"? Or do you mean "related to APN", which is kinda to be assumed? Also, what are "fine-granularity services"? Do you mean "service classes with finely-tuned performance characteristics?" (Also below.) ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Paragraph 0 ``` - Application-aware Networking (APN) Working Group will develop a framework to + The Application-aware Networking (APN) Working Group will develop a framework to + ++++ ``` ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool