I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-opsawg-vpn-common-09 Reviewer: Joel Halpern Review Date: 2021-07-30 IETF LC End Date: 2021-08-06 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard RFC Major issues: N/A Minor issues: I just want to confirm that one form of reference is normal for YANG models? There are a few identities whose meaning is defined by I-Ds that are under way. The references section of the identity gives the I-D name. Which is fine. The references at the bottom of the document makes those informative references. That seems a little odd since those references are necessary to understand the meaning of those identities. Is this a normal practice for YANG models? I am a little confused as to why the srv6 identity includes in its references clause RFC 8663 (MPLS SR). Is this a copy-and-paste error? I hope I am misreading the qos-classification-policy definition. It appears to have an id, a match rule, and a match action. The match rule can be a match-flow or a match-application. So far, so good. (putting aside the nit below on customer-application.) But the match rule is a choice between an L3 and an L4 rule. As I understand it, there are many cases where the actual classification is based on a combination of l3 and l4 information. How is that to be represented? Nits/editorial comments: The "customer-application" identity seems to be asking for problems in two regards. It seems that it is a shorthand way of expressing some combination of protocols and ports. The larger concern I have is that there is no reference that explains what classification rules should be used for any of the derived identities. Which means that for an interoperable implementation, there seems to be some difficulty in ensuring that the client and server mean the same thing when using them. (For example, just what filer corresponds to "voice"?) As a lesser issue, the current IAB work on path signals and the care that should be taken with them would seem to suggest that this is a less than desirable approach to the problem.