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
[email protected] 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 -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to