Hi Gorry, That's a good catch - thanks. Added RFC768 in revision 31.
Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmm-tn-aware-mobility-31 Best Regards, John > -----Original Message----- > From: Gorry Fairhurst <[email protected]> > Sent: Sunday, August 2, 2026 2:10 PM > To: Kaippallimalil John <[email protected]>; The IESG > <[email protected]> > Cc: [email protected]; [email protected]; draft-ietf-dmm-tn-aware- > [email protected]; [email protected] > Subject: Re: Gorry Fairhurst's No Objection on draft-ietf-dmm-tn-aware- > mobility-29: (with COMMENT) > > On 31/07/2026 20:08, Kaippallimalil John wrote: > > Hi Gorry, > > > > Thank you for reviewing and providing these comments. > > > > A few short notes on changes: > > - re: comment on source port randomization - now stated explicitly to note > this as a security consideration and ref to RFC8085,section 5.1.1. > > - revised UDP source port space to standard ephemeral source port space > assigned by IANA. > > - 3GPP TS28.541 (NRM spec) should probably be left as Normative. > > Attachment circuits in 28.541 are mapped via ConnectionPointInfo > (6.3.41) and EP_Transport (6.3.18). This links it to IETF ACaaS (UDP source > port). > > Moved RFC9543 to 9.2 (Informative References) as it is an informative > document. > > - RE: GTP-U /using the IPv6 flow label for mapping - it's probably beyond > > the > considerations in this document. > > (the approach seems like a good idea and can be looked into for > > another draft perhaps) > > > > Link: > > > https://ww/ > w. > > ietf.org%2Farchive%2Fid%2Fdraft-ietf-dmm-tn-aware-mobility-30.txt&data > > > =05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C5699b11233984aaa > 7c8d0 > > > 8def0c9a0bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6392 > 129459671 > > > 90953%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi > IwLjAuMDAw > > > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C% > 7C&sdat > > > a=TzVhWgcuuOceaimuHOqoWdw6F88Z7qUUcNMgqPAVISY%3D&reserved=0 > > > > Diff: > > > https://auth/ > > or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-dmm-tn-aware-mobility-3 > > > 0&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C5699b11233 > 984aa > > > a7c8d08def0c9a0bc%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0% > 7C6392129 > > > 45967260041%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW > UsIlYiOiIwLj > > > AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0% > 7C%7C%7 > > > C&sdata=xMpkkCQi4b4JsEPoO2KViMxyxhqxNfRuXH%2B7n7Iu520%3D&rese > rved=0 > > > > Best Regards, > > John > > > Thanks John, > > This sounds like you have addressed my comments. > > Shouldn't > https://data/ > tracker.ietf.org%2Fdoc%2Fhtml%2Frfc768&data=05%7C02%7Cjohn.kaippalli > malil%40futurewei.com%7C5699b11233984aaa7c8d08def0c9a0bc%7C0fee > 8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639212945967326184%7 > CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM > DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C% > 7C%7C&sdata=10%2FGwg6GML%2BdQSh8iqsoWs%2FRF7hwvHSDacldWtYZ > 3W8%3D&reserved=0 also be referenced? > > Best wishes, > > Gorry > > >> -----Original Message----- > >> From: Gorry Fairhurst via Datatracker <[email protected]> > >> Sent: Thursday, July 30, 2026 1:41 AM > >> To: The IESG <[email protected]> > >> Cc: [email protected]; [email protected]; draft-ietf-dmm-tn-aware- > >> [email protected]; [email protected] > >> Subject: Gorry Fairhurst's No Objection on > >> draft-ietf-dmm-tn-aware-mobility- > >> 29: (with COMMENT) > >> > >> Gorry Fairhurst has entered the following ballot position for > >> draft-ietf-dmm-tn-aware-mobility-29: No Objection > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut > >> this introductory paragraph, however.) > >> > >> > >> Please refer to > >> https://ww/ > >> w.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot- > >> > positions%2F&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C > >> > ddf28f069e884577a06408deee0579a0%7C0fee8ff2a3b240189c753a1d559 > >> > 1fedc%7C1%7C0%7C639209904454959592%7CUnknown%7CTWFpbGZsb3 > >> > d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > >> > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=LwGdafY4nZ4E > >> mNDdBWpoSH2J9MSPQSLLu79edcBpmTA%3D&reserved=0 > >> for more information about how to handle DISCUSS and COMMENT > positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> https://data/ > >> tracker.ietf.org%2Fdoc%2Fdraft-ietf-dmm-tn-aware- > >> > mobility%2F&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7Cd > >> > df28f069e884577a06408deee0579a0%7C0fee8ff2a3b240189c753a1d5591 > >> > fedc%7C1%7C0%7C639209904455021581%7CUnknown%7CTWFpbGZsb3d > >> > 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > >> > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Wr8VGO64ckf > >> GLLOYiLnecfEDQf5BFP7ppe4k3JiGBks%3D&reserved=0 > >> > >> > >> > >> --------------------------------------------------------------------- > >> - > >> COMMENT: > >> --------------------------------------------------------------------- > >> - > >> > >> Thank you for writing this document. I note that "IP transport" in > >> this context means transport of IP over UDP over IP, although I see > >> only one transport-related concern;-): > >> > >> ## The way in which the UDP source port number is used appears to > >> prevent the use of source port randomisation, as recommended in > >> [RFC8085]: a useful technique to mitigate vulnerability to off-path > >> attack. This is expected to be acceptable use. The concern maybe was > >> intended to be included within "To avoid spoofing..", although I'd > >> encourage this to be explicitly stated to note this as a security > >> consideration (perhaps cross-referencing Sect 5.1.1. of 5.1.1) and to > >> link this to mitigations to such attack, where I see IPsec and ACLs > >> suggested as viable possible approaches. > >> > >> ### Should GTP-U packets set and use the IPv6 flow label as an > >> entropy field for load balancing? > >> > >> ## "The source port space (~2^16) for mapping slices is more than > >> sufficient for any realistic deployment scenario." - Just to be sure: > >> Is the entire port range (2^16) really available, rather than just the > ephemeral port range? > >> > >> ## I found it puzzling that this document speaks of IETF protocols > >> such as UDP and a range of other terms and has no normative > >> references! - What is the dependency upon TS.28.541-3GPP? - Is the > >> reference to UDP normative - if not, why? - I am surprised there are > >> not normative references for the terminology used. Is all this > >> defined here? > >> > >> ### I do wonder if RFC 9543 is normative background (f not, what > >> provides the normative basis for the technologies?). > >> > >> Gorry Fairhurst > >> (updated comments) > >> > >> _______________________________________________ dmm mailing list -- [email protected] To unsubscribe send an email to [email protected]
