Please find below some comments on this document inline in the idnits output of
v08. Lookout for the <EoRv08> tag at the end to ensure you are seeing the full
review.


89	   and [RFC7605], Section 5).  With Any-Source Multicast (ASM; see
90	   [RFC1112] and [RFC4607]), the use of a port number to multiplex
91	   applications is unnecessary because the destination multicast address
92	   already provides a unique identifier for the application.  The same
93	   applies to Source-Specific Multicast (SSM; see [RFC4607]) because of
94	   uniqueness when both source unicast address and destination multicast
95	   address are taken together.

<major> This is the premise the document rests on, and I agree with it as
stated. What the document never states is which multicast address ranges and
scopes the Multicast Application Port is intended for. I am raising the
following as scoping considerations for the authors and the WG rather than as a
defect with a prescribed fix.

Should the document say anything about the IPv4 Local Network Control Block,
224.0.0.0/24, and the equivalent IPv6 interface-local and link-local scopes?
Traffic to those addresses is processed by router control planes rather than
forwarded, so a general purpose application port used in that range has a
different cost profile from one used in scoped or global space.

More generally, was the WG polled on whether use of the port should be
scoped to particular ranges, or is leaving it unscoped deliberate?

116	   An application sending multicast messages using the Multicast
117	   Application Port as the destination port MAY also send unicast
118	   messages using a different destination port.  One possible benefit of

<major-editorial> A BCP 14 keyword in the Introduction, where nothing is in
fact being specified - the sentence is descriptive. Perhaps s/MAY/may, or move
the statement into Section 2 if it is intended to be normative. My preference
is the former.

152	   Hosts SHALL require applications using this port to use it non-
153	   exclusively.  In practice, this means hosts using POSIX-like socket
154	   APIs would require applications to set the SO_REUSEADDR and/or
155	   SO_REUSEPORT socket options before binding the socket [POSIX].  This
156	   ensures that applications developed on a conformant host will also
157	   work on a non-conformant host.

<minor> "conformant host" and "non-conformant host" are first used here and are
never defined, and there is no Terminology section. The two terms then carry
the entire normative structure of Section 4 and part of Section 7, so a reader
has to infer that "conformant" means "meets the requirements of Section 3".

Please define both explicitly. A one-line definition at the head of this
section or of Section 4 would do, or a short Terminology subsection alongside
Section 1.1 - and if you add one, "wildcard address" belongs there too, per my
next comment.

159	   Hosts SHALL prevent use of the port with the wildcard address (see
160	   [RFC3493], Section 3.8) by having the socket bind operation return an
161	   error code.

163	   Hosts SHALL prevent applications from sending non-multicast packets
164	   using the Multicast Application Port as either a source or
165	   destination port by having the send operation return an error code.

<major> Two problems with the wildcard requirement in the first of these
paragraphs.

First, Section 3.8 of RFC 3493 is titled "IPv6 Wildcard Address" and defines
in6addr_any and IN6ADDR_ANY_INIT. It mentions the IPv4 constant INADDR_ANY only
in passing and does not define it. Since Section 1 states at line 109 that the
port can be used with both IPv6 and IPv4, this normative requirement is scoped
to both address families while the cited text covers only one.

Second, and more substantively, I believe the apposite text is Section 5.2 of
RFC 3493 rather than Section 3.8. Section 5.2 notes that to receive multicast
datagrams a process must join the group and bind the UDP port, and that some
processes also bind the group address to the socket in order to prevent other
datagrams sent to that port from being delivered. That is precisely the
mechanism this section is mandating, and RFC 3493 characterises it as an
optional practice rather than as the norm. Making the wildcard bind fail
therefore converts an optional convention into mandatory host behaviour, and it
is a behavioural change for existing applications that the document should
state.

Suggestions: cite Section 5.2 of RFC 3493 as the mechanism; cover both address
families by naming INADDR_ANY and in6addr_any, or by defining "wildcard
address" in terminology per my previous comment; and add a sentence
acknowledging that applications will need to bind the group address rather than
the wildcard, which is not today's common practice.

<minor> Both of these paragraphs require a host to signal refusal by returning
"an error code" without stating which one. Two conformant hosts could return
different errors, and an application then cannot distinguish "this host
enforces the port rules" from an unrelated failure.

Either name the expected values - for example EADDRNOTAVAIL for the bind case
and EACCES or EINVAL for the send case - or state explicitly that the specific
error is implementation-defined. The latter is acceptable, is this possible to
address?

181	   Applications running on a non-conformant host SHALL discard all
182	   datagrams received on the Multicast Application Port that do not have
183	   the multicast address used by the application.

<minor> Section 2 establishes that applications are identified
"by the destination multicast address (ASM) or by the combination of source
unicast address and destination multicast address (SSM)". This normative filter
drops the source address, so for SSM it is incomplete against the document's
own identification model. The firewall guidance in Section 7 has the same gap -
see my comment there.

Suggestion: extend the filter to read to the effect of "that do not have the
multicast address used by the application, and, for SSM, that are not from the
source address used by the application".

267	   Firewall rules referencing ports are typically intended to match
268	   specific applications for filtering and QoS.  Because applications
269	   using the Multicast Application Port are identified by both port and
270	   destination multicast address, rules referencing the Multicast
271	   Application Port SHOULD also consider the destination multicast
272	   address.  A firewall rule that references the Multicast Application
273	   Port without also considering the destination multicast address would
274	   match all applications using the Multicast Application Port, which is
275	   too broadly-scoped.

<major> Same as my comment on Section 4: this guidance drops the source
address, so for SSM it is incomplete against the identification model in
Section 2. Please add the source address for the SSM case here as well.

<minor> "for filtering and QoS" is the only trace in this document of the
impact on network devices that classify or police traffic by port, and it sits
inside Security Considerations. The Transport area review team made a broader
point on -07: rules that classify flows and assign treatments will need
criteria other than the destination port in order to separate application flows
that share this port.

From an operator standpoint the affected set is wider than QoS. Port-based ACLs
on PE and aggregation devices, DSCP classification and policing, IGMP and MLD
snooping policy, and flow accounting and monitoring all lose their only Layer 4
discriminator for multicast traffic and have to move to group-address-based
policy. Section 5 of RFC 7605 makes the general point that the document can
lean on here, observing that intermediate devices on a path use port numbers to
monitor available services, to monitor traffic, and to intercept it.

Suggestion, which also takes care of a placement point: add an Operational
Considerations section that consolidates the firewall material currently in
Section 5 together with traffic classification, policy and monitoring impact,
and move this QoS clause there out of Security Considerations. As things stand,
operational material is split between a standalone Section 5 sitting ahead of
Security Considerations and this clause inside it; consolidating it after the
requirements sections would read better and would give the Section 5 material a
proper home.

333	10.1.  Normative References

<major> RFC 6335 is referenced nowhere in this document - not in Section 10.1
and not in Section 10.2 - while RFC 7605, the other half of the same BCP, is
cited three times. The subject of this document is port assignment practice,
and Section 8 asks IANA to change the port application process. RFC 6335
defines that registry and its procedures. Section 1 of RFC 7605 is explicit
that the two together are known as BCP 165, and that RFC 7605 does not change
the assignment procedures described in RFC 6335.

The request in Section 8 is a change to the application process for the registry, 
which is RFC 6335's territory. The question for the authors and the port experts is
whether this document needs formally to Update RFC 6335, or whether the
contents of the application form are outside the scope of the RFC such that a
reference plus the IANA request suffices. I expect the latter is the answer,
but the document should reference RFC 6335 either way, and should say which it
intends.

This is the other half of my DISCUSS above - please read the two together.

One closing note: please take this as someone that has not been involved in or
aware of the past discussions in the WG, and more importantly has not been
following intarea and transport work. I am reasonably confident on the
multicast addressing and operational points; on the rest, feel free to just
tell me that I am wrong and/or oversimplifying :-)

<EoRv08>