1) Contradiction in node requirements
Abstract says:
> This method does not require
> modification to existing protocol stacks, though recommended updates
> to make the port easier to use are included.
The above language ("recommended", "does not require") implies a SHOULD.
However, section 3 contradicts that and instead says:
> Hosts SHALL require applications using this port to use it non-
> exclusively.
(plus various other SHALL statements about hosts).
This especially matters if BCP 220 is updated to reference this document.
2) Assumption that implementers can configure host firewalls
Section 3.1 says:
> Implementers should be
> aware of this possibility and configure the host firewall
> appropriately.
In reality, there are various host firewall vendors (McAfee, Kaspersky, Norton,
etc.) One cannot simply assume that the implementer of an arbitrary application
can write code to configure all host firewalls that might be installed on the
machine
that an end-user or admin will install the application on.
Section 1 does have an out:
> Use of this port is optional because there may be circumstances where
> assigning a port is preferred, such as when participants cannot meet
> the requirements in Section 3 and Section 4.
I think section 3.1 should instead say that in general, applications that
need a pattern like the one in 3.1 should continue to request their own
port and not use the Multicast Application Port. That's already consistent
with section 1, and avoids implying something that ignores reality.
3) Reference to RFC 7288
I'll also repeat my earlier recommendation to add an informative reference
to RFC 7288 in the text on host firewall considerations. For example...
OLD: Certain host firewalls are designed to accept incoming messages as
OLD: long as there was first an outgoing message using the same set of
OLD: ports. Consider the following sequence of messages:
NEW: Certain host firewalls are designed to accept incoming messages as
NEW: long as there was first an outgoing message using the same set of
NEW: ports. (See [RFC7288] for more discussion.) Consider the following
sequence of messages:
4) Application Requirements
Section 4 says:
> Applications running on a non-conformant host SHALL discard all
> datagrams that do not have the multicast address used by the
> application.
Above is too broadly stated. In think you specifically mean datagrams
received on the Multicast Application Port. As worded, it says that the
application cannot have other sockets listening on other ports and accept
packets on them.
5) Security Considerations
There's another security consideration missing. Applications that don't
use the Multicast Application Port can often rely on host firewall behavior
(which may be the default on host platforms the application is installable on)
to prevent unsolicited inbound traffic and hence help mitigate some classes
of attack.
By using the Multicast Application Port, that external protection no longer
exists,
so the application must be prepared to deal with any resulting security
concerns itself. That includes address/port scans, and attacks against
the application itself. (Again see RFC 7288.)
The above needs to be called out in the Security Considerations section.
Dave
> -----Original Message-----
> From: Wassim Haddad via Datatracker <[email protected]>
> Sent: Monday, January 26, 2026 9:15 AM
> To: [email protected];
> [email protected]; intarea-
> [email protected]
> Subject: [Int-area] WG Last Call:
> draft-ietf-intarea-multicast-application-port-03
> (Ends 2026-02-09)
>
> Dear colleagues,
>
> This message starts a WG Last Call for:
> draft-ietf-intarea-multicast-application-port-03
>
> This Working Group Last Call ends on 2026-02-09
>
> Please note we need at least 5 reviews to progress the draft to next step.
>
> Abstract:
> This document discusses the drawbacks of the current practice of
> assigning a UDP port to each multicast application. Such assignments
> are redundant because the multicast address already uniquely
> identifies the data. The document proposes assigning a UDP port
> specifically for use with multicast applications and lists
> requirements for using this port. This method does not require
> modification to existing protocol stacks, though recommended updates
> to make the port easier to use are included.
>
> File can be retrieved from:
>
> Please review and indicate your support or objection to proceed with the
> publication of this document by replying to this email keeping
> [email protected] in
> copy. Objections should be explained and suggestions to resolve them are
> highly
> appreciated.
>
> Authors, and WG participants in general, are reminded of the Intellectual
> Property
> Rights (IPR) disclosure obligations described in BCP 79 [1].
> Appropriate IPR disclosures required for full conformance with the provisions
> of
> BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
> Sanctions available for application to violators of IETF IPR Policy can be
> found at
> [3].
>
> Thank you.
>
> [1] https://datatracker.ietf.org/doc/bcp78/
> [2] https://datatracker.ietf.org/doc/bcp79/
> [3] https://datatracker.ietf.org/doc/rfc6701/
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-intarea-multicast-application-port/
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-intarea-multicast-application-port-03
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-intarea-multicast-application-port-
> 03
>
> _______________________________________________
> Int-area mailing list -- [email protected] To unsubscribe send an email to
> int-area-
> [email protected]
_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]
