Dear Éric,

Many thanks - to you, as well as all the people you mention!

Regarding the “I would appreciate a reply by the authors, esp on issue 1” to 
Tatuya Jinmei’s review: working on it  :-)

Regarding your other comments (really *all* comments, including all others from 
Tatuya Jinmei): I hope it’s ok that, instead of following up via email, we 
discuss and address them via our github, where we deal with them swiftly as 
they come in:
https://github.com/ietf-tapswg/api-drafts/issues 
<https://github.com/ietf-tapswg/api-drafts/issues>
As you can see, I have already filed issues there for your comments below.

Cheers,
Michael


> On 5 Sep 2023, at 15:05, Éric Vyncke via Datatracker <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> É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/ 
> <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/ 
> <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/
> ?
> 
> 
> 

_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps

Reply via email to