Hi Linda! As I understand the scenario below, it would align to the work in this document only to the degree that the SD-WAN network would be an underlay to the DTN Bundle Protocol (via some as of yet undefined convergence layer) and the Virtual Network IDs would have an easy mapping to the DTN-specific addressing mechanism (Endpoint IDs per Section 4.2.5 of RFC9171). I'll let the DTN experts correct me or provide more insight on the alignment. As an aside, there is a critical IANA issue with this document and it is being pulled from the planned telechat docket. Roman > -----Original Message----- > From: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx> > Sent: Friday, October 21, 2022 12:46 PM > To: Roman Danyliw <rdd@xxxxxxxx>; ops-dir@xxxxxxxx > Cc: acme@xxxxxxxx; draft-ietf-acme-dtnnodeid.all@xxxxxxxx; last-call@xxxxxxxx > Subject: Re: Opsdir telechat review of draft-ietf-acme-dtnnodeid-10 > > Roman, > > Can the mechanism specified in the draft be used to validate the Virtual > Network IDs of SD-WAN edge devices? > For example, an SDWAN edge deployed in a remote site, say a shopping mall, > might advertise the routes and client VPN IDs to the BGP Route-Reflector (RR). > The RR needs to validate the Client's IDs are legitimate. Can the mechanism > specified in the draft do the job? > > Thanks, Linda > > > On 10/20/22, 10:36 PM, "Linda Dunbar" <linda.dunbar@xxxxxxxxxxxxx> > wrote: > > Roman, > > With you bringing back the explanation, all makes sense to me now. Wish > your explanation is incorporated into the document. > Thanks, Linda > > On 10/20/22, 6:53 PM, "Roman Danyliw" <rdd@xxxxxxxx> wrote: > > Thanks for the re-review Linda. > > ACME WG: here is the thread from the IETF LC where proposed changes > were discussed: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarc > hive.ietf.org%2Farch%2Fmsg%2Flast- > call%2FnujBgHd6ZKHY6fG58ZWBKzFGVWs%2F&data=05%7C01%7Clinda. > dunbar%40futurewei.com%7C3d47157879904a302e3008dab2f65009%7C0fee > 8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638019068235813966%7CUn > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik > 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=t83ICajIF%2FEIKz > ibHtGs0T9FFSQpSFmBxKdxxgGHkPY%3D&reserved=0 > > > -----Original Message----- > > From: Linda Dunbar via Datatracker <noreply@xxxxxxxx> > > Sent: Thursday, October 20, 2022 6:55 PM > > To: ops-dir@xxxxxxxx > > Cc: acme@xxxxxxxx; draft-ietf-acme-dtnnodeid.all@xxxxxxxx; last- > call@xxxxxxxx > > Subject: Opsdir telechat review of draft-ietf-acme-dtnnodeid-10 > > > > Reviewer: Linda Dunbar > > Review result: Has Issues > > > > I have reviewed this document as part of the Ops area directorate's > ongoing > > effort to review all IETF documents being processed by the IESG. These > > comments were written primarily for the benefit of the Ops area > directors. > > Document editors and WG chairs should treat these comments just like > any > > other last call comments. > > > > This document specifies an extension to ACME protocol which allows an > ACME > > server to validate the Delay-Tolerant Networking Node ID for an ACME > client. > > > > I had the following comments for the -07 version. I don't think the latest > > version (-10) resolved my comments. > > > > Issues: > > > > The document didn't describe how the Node ID described in this > document is > > related to the Delay Tolerant Network. I see the mechanism can be > equally > > used in any network. What are the specifics related to the "Delay > Tolerant > > Network"? > > It would be helpful if the document adds a paragraph explaining the > specific > > characteristics of the Delay-Tolerant Network that require the additional > > parameters/types used for validating the Node-ID for an ACME client. > > > > Thank you, > > > > Linda Dunbar > > > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
