[OPSAWG] Genart last call review of draft-ietf-opsawg-vpn-common-09

[Joel Halpern via Datatracker]

Reviewer: Joel Halpern
Review result: Ready with Issues

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.



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Tsvart last call review of draft-ietf-opsawg-vpn-common-09

[Wesley Eddy via Datatracker]

Reviewer: Wesley Eddy
Review result: Ready with Issues

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-...@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.


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg