Please view the supplement for the review comments.

The Common Community Physics Package (CCPP) Framework v6 

The paper describes interesting concept on generalization of atmospheric physics to be accessible from various numerical models. It tries to introduce some flexibility to the physics-dynamics interface to the Common Community Physics Package (CCPP) through imposing standardized rules and uniform structure. Paper gives an adequate overview about this activity with two examples of its potential use.  The text is well written and relatively easy to be followed. The manuscript is certainly logically structured. 

General comment:

Rather than providing detailed scientific and/or technical discussions justifying the driving motivation for this effort the manuscript feels like code documentation or summary of rules to be followed when intending to use or develop the CCPP. The text is on the other hand not sufficiently detailed to serve as a crash course, neither to be regarded as a manual. As a reviewer I struggle to grab the purpose of this paper: It feels like a message to the community perhaps an advertisement of the completed work but certainly not a scientific paper. With this regard it is difficult to argue about anything presented. Reader can simply learn about it but no justification of the decision along the line is given. We all know the devil is in details, but the paper is far from such complexity and to discuss the adopted paths. Like that the paper can serve as a decent overview. If this is the intent and the text suites the editorial concept of the Journal the presented paper can be easily accepted for publication. Still, it may be worth authors consider giving bit more arguments supporting the presented choices. The questions bellow grouped into three areas reflect my personal take for the sort of information missing in the manuscript.

Specific comments:

On a more scientific aspects one would like to learn about the level of flexibility this presented interface can offer. For example, can the proposed interface accommodate both sequential and parallel attitude to various physics processes? Can one easily change order of schemes within the package (like for example to swap convection and vertical diffusion or to call saturation adjustment multiple times after several processes)? Does the interface support inter-timestep history to average physical processes over certain time range? And if so, would it follow the Lagrangian path to maintain the best spatial and temporal consistency? Or does it support some flexibility for partial call of physics during split dynamics or predictor-corrector type of model. Can the package (or part of it) be used in an implicit way? Would the interface easily digest when some processes are replaced by super-parameterizations with its own specific computational stencils? How the conservation (and of what quantities) is being ensured within this flexible framework? I understand those are questions beyond the scope addressed by this paper. Still, a reader might be given some overview about the assumed scientific flexibility for the presented interface.

When regarding the CCPP from more technical side, the presented text also leaves some unanswered questions. The assumed organization of fields requires the first index (ensuring the most optimal memory access for the inner loops) to be the number of 1D columns in a chunk. The recent evidence favours to prioritize data storage along vertical levels (i.e. to have vertical levels as the first index) for GPU processing in order to be most benefiting there. Naturally, one may assume the choice adopted for CCPP is not the most optimal with this regard. Or does the CCPP possess any tool to easily swap array ordering to suite this eventual requirement? Listing 1 (page 7) implies all the data are copied both ways between the host model space and the CCPP. Although this may allow some flexibility and potential to fully control precision during the CCPP computation this step would certainly significantly affect the code efficiency. Have authors considered to use some better alternatives (like pointers) to avoid this massive and repetitive data move? It should be fair to present some estimates about pros and cons of this controversial step to convince reader about the adopted strategy.

Finally, the presented very ambitions and huge work implies increased level of discipline for the code maintenance and development. (The CCPP code may be evaluated for use in a model not available to the evaluation team.) From this reason it is perhaps worth to mention any specific policy mechanism ensuring the rules are being maintained and followed by all contributors. Is there some reviewing committee with the right to accept the new code? And what is the policy to adopt the presented rules in the case their modification is required in a future (to accommodate a new scheme)?