[Gen-art] Re: [Last-Call] draft-ietf-rtgwg-multisegment-sdwan-13 ietf last call Genart review

[Russ Housley <[e-mail]>]

Linda:

You have resolved all of my concerns.

Russ


> On Jul 6, 2026, at 2:41 PM, Linda Dunbar <linda.dunbar=[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> 
> Sent: Friday, July 3, 2026 1:16 PM
> To: [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> 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 -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>