Last Call Review of draft-ietf-opsawg-vpn-common-09
review-ietf-opsawg-vpn-common-09-genart-lc-halpern-2021-07-30-00

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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.