Hi, Sorry this reply is coming so late. More:
On Sun, Jul 19, 2026 at 9:18 AM Karstens, Nate <[email protected]> wrote: > Mallory, > > > > Thanks for the feedback! We uploaded a new version of the document that > addresses the nits. > > > > For the minor issue, I’m having trouble coming up with something that will > address the minor issues you noted below. In particular: > > > > 1. It’s hard to say what types of messages would be appropriate for a > given application. > 2. It doesn’t seem like using different ports really serves as a > security protection. > > > I'm not necessarily asking for these to be resolved if they are choices that implementers can make. But the confusion about whether and how should be resolved on both. In other words, no need to explain to me in this email various tradeoffs, but the reader should ideally have more information about these points so that they can better make choices for themselves. If the answer is, "it's complicated," then it's okay to say that, and then explain why. Thanks a lot, -Mallory > If you have suggested text or can elaborate more that will be helpful 😊 > > > > Cheers, > > > > Nate > > > > *From:* Mallory Knodel via Datatracker <[email protected]> > *Sent:* Monday, June 22, 2026 12:45 PM > *To:* [email protected] > *Cc:* [email protected]; > [email protected]; [email protected] > *Subject:* [Int-area] draft-ietf-intarea-multicast-application-port-07 > ietf last call Genart review > > > > Document: draft-ietf-intarea-multicast-application-port Title: The > Multicast Application Port Reviewer: Mallory Knodel Review result: Ready > with Nits I am the assigned Gen-ART reviewer for this draft. The General > Area Review Team (Gen-ART) reviews > > Document: draft-ietf-intarea-multicast-application-port > > Title: The Multicast Application Port > > Reviewer: Mallory Knodel > > Review result: Ready with Nits > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > > > > For more information, please see the FAQ at > > > > <https://urldefense.com/v3/__https://wiki.ietf.org/en/group/gen/GenArtFAQ__;!!EJc4YC3iFmQ!Xi1CDyEKskCvMKmjd1VIQcANthw6v0Wr9u3-uVsZylnxvLYKzz1MrzU-1_ZM1VItqPO9BgPnUKT9p0P16g$ > > <https://urldefense.com/v3/__https:/wiki.ietf.org/en/group/gen/GenArtFAQ__;!!EJc4YC3iFmQ!Xi1CDyEKskCvMKmjd1VIQcANthw6v0Wr9u3-uVsZylnxvLYKzz1MrzU-1_ZM1VItqPO9BgPnUKT9p0P16g$>>. > > > > Document: draft-ietf-intarea-multicast-application-port-?? > > Reviewer: Mallory Knodel > > Review Date: 2026-06-22 > > IETF LC End Date: 2026-06-29 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: The document is well written and easy to understand. Where there > > exists some ambiguity in the narrative text, I've attempted rewrites in the > > nits section below. I've included questions to be considered "minor issues". > > > > Major issues: None. > > > > Minor issue: It seems to me there might be a more general statement needed in > > the Intro, last paragraph: [MAY/SHOULD] NOT an application sending > > [multi/uni]cast messages also send [multi/uni]cast messages using a different > > destination port? (And what does using the Multicast Application Port as the > > destination port have to do with it, architecturally speaking?) You could also > > preview for the reader why a common port doesn't introduce privacy/security > > issues as that seems a curiosity worth an intro mention. > > > > Nits/editorial comments: > > > > The following are rephrasings that, if correct, might improve readability: > > > > * Intro, second para: The same applies to Source-Specific Multicast (SSM; see > > [RFC4607]) because of uniqueness when both source unicast address and > > destination multicast address are taken together. > > > > * Firewall considerations section, first para: just remove parentheticals in > > favour of sentence clauses, eg commas. > > > > > > > > _______________________________________________ > > Int-area mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > > ------------------------------ > > 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. >
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
