[OPSAWG] Tsvart last call review of draft-ietf-opsawg-tsvwg-udp-ipfix-07

[Tommy Pauly via Datatracker]

Reviewer: Tommy Pauly
Review result: Ready

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.

Thanks to the authors for their work on the clear and concise draft. I don't
see any issues from a transport perspective in the latest version. I appreciate
the updates since the -05 version to clarify the type of the "udpOptions" IE
(which is now a concrete unsigned256 type, still very long!), and to add more
illustrative examples.


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

[OPSAWG] Tsvart early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

[Tommy Pauly via Datatracker]

Reviewer: Tommy Pauly
Review result: Almost Ready

Thanks for writing a clear and succinct draft. I only found one issue of note,
around the registration of the new udpOptions Information Element.

Section 4.1:
The data type used for the “udpOptions” entry is just listed as “unsigned”, and
is described as being either an unsigned32 or an unsigned64. However, when I
look at the registry at https://www.iana.org/assignments/ipfix/ipfix.xhtml, I
don’t see any entries that use this abstract “unsigned” type, and it is not
listed as an option in the element data types. Is there a reason this shouldn’t
just be registered as an unsigned64? My understanding from
https://www.rfc-editor.org/rfc/rfc7011#section-6.2 is that an unsigned64 can be
automatically encoded as an unsigned32 if the value is small enough, so the
definition can just use unsigned64.


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

[OPSAWG] Intdir telechat review of draft-ietf-opsawg-service-assurance-yang-11

[Tommy Pauly via Datatracker]

Reviewer: Tommy Pauly
Review result: Ready

(Apologies for the late review!)

This latest version of the document is clearly written and in good shape. From
the perspective of INTAREA, I see no concerns with the document.


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

[OPSAWG] Tsvart last call review of draft-ietf-opsawg-model-automation-framework-06

[Tommy Pauly via Datatracker]

Reviewer: Tommy Pauly
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 describes an architecture for using YANG models in with automated
networks and services. The details of delivery (such as over L2 or L3 VPNs) is
not discussed in detail, and transport-specific details of that delivery seem
out of scope for this document. The primary intersection of this work with the
Transport Area is the integration with IPPM specifications and YANG modules.

Section 3.1 references several IPPM specifications (One-Way Delay/Loss metrics,
and Link Capacity). It may be good to reference the new IPPM registries for
metrics, which are currently in AUTH48
(https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml,
draft-ietf-ippm-metric-registry, draft-ietf-ippm-initial-registry). Also as a
nit, the link for “I-D.ietf-ippm-capacity-metric-method” doesn’t seem to be a
live hyperlink.

I am also a bit unclear about the way that these metrics are referenced. The
relevant text is:

For example, the service level
   can be used to characterise the network service(s) to be ensured
   between service nodes (ingress/egress) such as:
…
   o  the traffic performance guarantees (One-Way Delay (OWD) [RFC7679],
  One-Way Loss [RFC7680], ...),
   o  link capacity [RFC5136][I-D.ietf-ippm-capacity-metric-method],

This is the first place that “service level” is used as a term. Should this be
“Service Model” as is used earlier in the paragraph? It also seems a bit
problematic to reference these link metrics as “guarantees”; these metrics are
used to represent empirical measurements, but cannot guarantee behavior of a
link. Could we replace “guarantees” and “ensures” with other words, such as
“expected”/“expectations”?

I also agree with Christian’s secdir review comments, particularly with the
number of referenced documents and dependencies.


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