This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

This document basically looks good to me, though I have a small number of comments:

(1) I think this comment impacts only the narrative and not the YANG model itself.  The list of possible underlay-transport values seems to be a mixture of expected types of encapsulations, but then a couple of things at the end that are signaling and not encapsulations per-se.  The last 2 entries in the list on page 6 are what seem out of place to me - RSVP and BGP.  I don't think it's quite correct to refer to these two as the underlay-transport.

(2) This is a YANG model question, that I'm unsure of.  I want to make sure that in the match-type when match-flow is used that a combination of L3 and L4 attributes can be used.  It appears like either L3 or L4 can be indicated, mutually exclusive, but I don't quite understand how it would then be possible to properly represent the combination of IP, transport protocol, and ports that identify a flow.  It seems like a list of criteria from both L3 and L4 components is what's needed to express a flow, rather than a choice of L3 or L4.