Linda: You have resolved all of my concerns.
Russ > On Jul 6, 2026, at 2:41 PM, Linda Dunbar > <[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>. > > 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]
