Thank you, Russ. The revision that addressed your comments have been uploaded: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-multisegment-sdwan/
Linda From: Russ Housley <[email protected]> Sent: Monday, July 6, 2026 12:53 PM To: Linda Dunbar <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: [Gen-art] Re: [Last-Call] draft-ietf-rtgwg-multisegment-sdwan-13 ietf last call Genart review Linda: You have resolved all of my concerns. Russ On Jul 6, 2026, at 2:41 PM, Linda Dunbar <[email protected]<mailto:[email protected]>> wrote: Russ, Thank you very much for the detailed comments. Please see the resolutions below marked by [Linda]. Let us know if they can address your concerns. Linda -----Original Message----- From: Russ Housley via Datatracker <[email protected]<mailto:[email protected]>> Sent: Friday, July 3, 2026 1:16 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: draft-ietf-rtgwg-multisegment-sdwan-13 ietf last call Genart review Document: draft-ietf-rtgwg-multisegment-sdwan Title: Multi-segment SD-WAN via Cloud DCs Reviewer: Russ Housley Review result: Almost Ready 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C1774cc6d16344c25094e08ded9406c57%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639187067889579127%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9ZTIfvE5UGtRSIaV8wQCO48SUfQV82U48r%2Bgd%2FgtKTQ%3D&reserved=0<https://wiki.ietf.org/en/group/gen/GenArtFAQ>>. Document: draft-ietf-rtgwg-multisegment-sdwan-13 Reviewer: Russ Housley Review Date: 2026-07-03 IETF LC End Date: 2026-07-08 IESG Telechat date: unknown Summary: Almost Ready Major Concerns: None Minor Concerns: Section 3.1: This solution is for customers that have already chosen SD-WAN, and this offers GENEVE as well. Please avoid the comparison to other inter-connection services. [Linda] How about the following wording change to emphasize that it is for customers that have already chosen SD-WAN: Old: Stitching SD-WAN segments through a Cloud Gateway provides a way to extend policy enforcement and traffic control across branches, particularly when direct branch-to-branch paths over the public internet are insufficient New: For customers that have already chosen SD-WAN, stitching SD-WAN segments through a Cloud Gateway provides a way to extend policy enforcement and traffic control across branches using their existing SD-WAN-to-cloud connectivity, while avoiding the need to establish separate direct branch-to-branch SD-WAN paths. The first bullet is changed: Old: The public internet between branches may suffer from limited bandwidth, unpredictable performance, and security risks New: The public Internet path from a branch to its nearby Cloud GW is typically shorter and more controlled than an end-to-end public Internet path between branches, which can reduce exposure to unpredictable performance, limited bandwidth, and security risks. Section 9.2: What hash function will be used with HMAC? [Linda] How about the following wording change: Old: The specific hash algorithm is outside the scope of this document and is pre-configured and distributed by the controller together with the associated keying parameters New: HMAC-SHA-256 [RFC4868] is the default algorithm used for computing the HMAC value. Other HMAC hash algorithms MAY be used when explicitly configured and distributed by the controller together with the associated keying parameters Section 9.3: How are the keys set up? IKEv2? [Linda] How about adding a paragraph at the end of Section 9.2? When AH or ESP-NULL is used, the required IPsec SAs and associated keying material SHOULD be established using IKEv2 [RFC7296]. Deployments MAY use manual or controller-based key provisioning when supported by the operational environment, but such provisioning MUST provide equivalent authentication, authorization, replay protection, key freshness, and key rollover properties. Nits: Throughout: s/public internet/public Internet/ [Linda] changed. Section 1: Please expand "Cloud DCs" on first use. [Linda] added. IDnits offers a suggestion: -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? [Linda] Inserted the following in the “Conventions” Section: The IP addresses used in this document are for illustrative purposes only. IPv4 examples use addresses from the documentation blocks defined in [RFC5737] (192.0.2.0/24 and 198.51.100.0/24). All mechanisms described apply equally to IPv6, where equivalent examples would use addresses from the documentation prefix defined in [RFC3849] (2001:db8::/32). Thank you very much, Linda -- last-call mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
