A YANG Data Model for Network Tester Management
draft-ietf-bmwg-network-tester-cfg-17

Yes

Mohamed Boucadair

No Objection

Andy Newton
Christopher Inacio
Deb Cooley
Gorry Fairhurst
Gunter Van de Velde
Jim Guichard
Mahesh Jethanandani
Roman Danyliw
Tommy Jensen

Abstain

Éric Vyncke

Note: This ballot was opened for revision 13 and is now closed.

Mohamed Boucadair
Yes
Andy Newton
No Objection
Christopher Inacio
No Objection
Deb Cooley
No Objection
Comment (2026-06-24 for -14) Sent 
Section 7:  Consider asking the RFC Editor to swap out RFC 8446 with RFC 9846 (in Auth48) which deprecates it.
Gorry Fairhurst
No Objection
Comment (2026-06-27 for -15) Sent 
Thank you for the work that has been put into this document.

I support Eric's DISCUSS and had similar questions.

Please also find below an additional non-blocking COMMENT point (replies would be appreciated even if only for my own education).

I think this document could be clearer on the acceptable use. The figures show directly attached devices, which is what I expected, but I would have real concerns with making an open configurable traffic generator available on the general Internet, although the Security Considerations do not seem to currently note this concern. Could this be updated?

Gorry
Gunter Van de Velde
(was Discuss) No Objection
Comment (2026-07-01 for -16) Sent for earlier 
Thank you for resolving the DISCUSS observations and for processing the non-blocking comments
(ballot response https://mailarchive.ietf.org/arch/msg/bmwg/otnzw1J-YWTzf6AoZJJIg4Lv1RU/ )
Jim Guichard
No Objection
Mahesh Jethanandani
(was Discuss) No Objection
Comment (2026-07-01 for -16) Sent 
Section 4, ietf-traffic-analyzer module, capture-statistics-data grouping:

957 >       leaf octets {
958 >         type yang:counter64;
959 >         description
960 >           "This counter is identical with the in-octets/out-octets
961 >            counters defined in RFC8343 except that it counts the
962 >            octets captured since the analyzer was created.";

BTW, one comment, and I will let you decide how you want to address it,
if you want to.

You say the following when describing the container for statistics:

    container statistics {
      description
        "A collection of interface-related statistics objects.
         The counters in this container must be initialized
         to zero when the traffic-analyzer container is created";

You do know that there is a type for that. It is called zero-based-counter64.
Roman Danyliw
No Objection
Tommy Jensen
No Objection
Éric Vyncke
(was Discuss) Abstain
Comment (2026-06-29 for -15) Sent 
Changing my ballot position to a non-blocking ABSTAIN as it appears that the discussion has staled per https://mailarchive.ietf.org/arch/msg/iesg/zbhF7KSnEBFiBrJX2_oZJ3g9F5E/

Original DISCUSS & COMMENTS repeated below for archival purposes.

## Original DISCUSS (for archive)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

### Only for Ethernet ?

The text mainly mentions Ethernet and I think that this is ambiguous (hence the
blocking DISCUSS), if the model is restricted to Ethernet than let's be clear
in the title, abstract, and in the text body (including YANG modules), else
update the text body to avoid being too specific to Ethernet.

It also seems that the model is restricted to framed-based octet-aligned
network, if so then be specific in the title/abstract/introduction.

### BMWG charter fit ?

I fail to see how a (useful) YANG model fits the BMWG WG charter, which
mentions mainly methodologies.

Happy to be corrected by pointing me to the relevant chartered work item.

### Section 2.4

I fear that "testframe-statistics.latency" container misses a lot of relevant
metrics: variance is important (also median albeit less important).

## COMMENTS (non-blocking)

### Section 1.2

While English is not my primary language, I do not think that `This section
specifies the design objectives` is correct, i.e., the section can "list
objectives" or "specify requirements" but not "specify objectives".

### Section 8.1

RFC 2544 is probably informative and not normative.

### Section 8.2

AFAIK, there is a IEEE 802.3 standard dated 2022, so, please use the latest
reference rather than 2014.

### Section A.1

Marking the 'code' as XML2RFC <CODE BEGINS> ... <CODE ENDS> would be useful.

Please also indicate (with a reference) which program/application is used in
this example.

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate
SVG graphics. It is worth a try especially if the I-D uses the Kramdown file
format ;-)