[Tsv-art] Re: [Int-area] draft-ietf-intarea-multicast-application-port-07 ietf last call Tsvart review

["Karstens, Nate" <[e-mail]>]

Thanks for your feedback, Wesley!

We have addressed everything you noted in v8 of the document.

Cheers,

Nate

From: Wesley Eddy via Datatracker <[e-mail]>
Sent: Tuesday, June 23, 2026 3:45 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [Int-area] draft-ietf-intarea-multicast-application-port-07 ietf last call Tsvart review

Document: draft-ietf-intarea-multicast-application-port Title: The Multicast Application Port Reviewer: Wesley Eddy Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to


Document: draft-ietf-intarea-multicast-application-port

Title: The Multicast Application Port

Reviewer: Wesley Eddy

Review result: Ready with Nits



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

[e-mail]<mailto:[e-mail]> if you reply to or forward this review.



This is a well-written and clear document.  A couple small nits came to mind

while I was reviewing it, which I don't think are serious blockers to

publication, but just some aspects that the editors or ADs might want to

consider clarifying.



1. The document mentions compatibility with existing protocol stacks, but it's

not quite clear to me what is meant by that.  Does it mean protocol stacks from

the IP + UDP within OS kernels all the way up through existing multicast

application code (for some specific applications?), or does it refer to just

the kernel portion, or just the userspace portions?  The statement is made

without an example.  It could be that everything literally just works, but it's

not clear.



2. The shepherd writeup says that there hasn't been implementation, which

confuses me on how the editors are so sure that this is compatible with

existing stacks.  I assume there were some proof-of-concept tests on

Linux/Windows/Apple/etc. platforms, but nothing seems to be mentioned.  If

those tests were done and there really are simply no caveats an app developer

should know about other than just the common socket options mentioned, then

that would be good to mention.



3. The document has good analysis about complications with firewalls.  Another

common use of port numbers is in classifying traffic for different QoS

treatment.  Implications for that here seem relevant to mention.  Rules for

classifying flows and assigning treatments will need to use criteria other than

just the destination port in order to separate different application flows

sharing this port, if they're to be given different treatments.





_______________________________________________

Int-area mailing list -- [e-mail]<mailto:[e-mail]>

To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

________________________________

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.