[Taps] Éric Vyncke's Yes on draft-ietf-taps-interface-22: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-taps-interface-22: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-taps-interface/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-taps-interface-22

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Anna Brunstrom for the shepherd's detailed write-up including
the WG consensus, and the justification of the intended status and of the large
number of authors. I can only support having all those authors cited
(especially from current/past academia).

Other thanks to Tatuya Jinmei, the Internet directorate reviewer (at my
request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-taps-interface-22-intdir-telechat-jinmei-2023-09-01/
(while a positive review, I would appreciate a reply by authors, esp on issue 1)

Other thanks to Matt Brown, the DNS directorate reviewer (at my request),
please consider this dns  -dir review:
https://datatracker.ietf.org/doc/review-ietf-taps-interface-22-dnsdir-telechat-brown-2023-08-27/

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS

## Abstract and Section 1

It is not only about "multiple interfaces" but also about "multiple
provisioning domains" (usually linked to interfaces), e.g., an interface can
have several IPv6 addresses and several next-hops. RFC 7556 is only mentioned
in Section 2.

## Section 1

`Action(param0, param1?, ...) / Event<param0, param1, ...>` the use of `\` is
unclear... suggest using two lines ? Should param1 in Event() also be suffixed
by a '?' ?

Is `IP Address` scoped ? E.g., fe80::1%eth0 Can it be unicast, anycast,
multicast ? Even if section 6.1 is about this issue, it may be worth already
telling the readers.

## Section 3

`from a Remote Endpoint` does the use of 'a' preclude a multicast group
endpoint ?

## Section 3.1

Useful section. Thanks.

## Section 4.1

It is a little underspecified whether the '.' is also removed when the
Namespace component is omitted (I guess yes, but let's be specific).

Should 'tcp' be in uppercase in `tcp Connection could support ` ?

`IETF document published in the RFC Series` in which stream ? Are ISE or IAB or
IRTF streams also OK ?

## Section 5

If not mistaken, then there are only 3 occurrences of a normative SHOULD and
several other non-normative "should". Is it the intent ?

## Section 6.1

I am not sure whether I like the split between .WithIPAddress() and
.WithInterface()... E.g., using "fe80::1%eth0" as an endpoint would be nicer ?

Should there be a .WithPvD() to handle multiple PvDs on the same interface ?
Even after reading section 6.2.12, it is unclear.

## Section 6.1.1

TTL is so legacy... Why not using RFC 8200 hop limit ?

# NITS

## Section 6.1 and other places

2001:db8:4920:e29d:a420:7461:7073:0a is not a valid RFC 5952 address ;-)

## Section 8.1.11.13

s/It specified as the number of bytes/It *is* specified as *a* number of bytes/
?