Linda, I'm now very confused. The original topic was comments on a DTN acme draft. How did we get to discussing Virtual Network IDs of SD-WAN edge devices?
Do you want to get X.509 certificates for these devices? Or do you have something else in mind to validate these devices? Deb Cooley On Fri, Oct 21, 2022 at 2:02 PM Linda Dunbar <linda.dun...@futurewei.com> wrote: > Roman, > > Thanks. > I don't see how DTN wg is relevant, as the SD-WAN is NOT Delay Tolerant > Network. More relevance is on the "certificate issuance mechanism" to > validate if the IDs advertised by a remote node are legitime. > > Does ACME Wg work on "Certificate issuance mechanism" for remote node > IDs? > > Linda > On 10/21/22, 12:53 PM, "Roman Danyliw" <r...@cert.org> wrote: > > IMO, the simplest thing would be to pose this question on the DTN WG > mailing list. This very specific work is being done in the ACME WG because > it has the expertise on the certificate issuance mechanism, but I see you > applicability to SD-WAN as more general. > > Roman > > > -----Original Message----- > > From: Linda Dunbar <linda.dun...@futurewei.com> > > Sent: Friday, October 21, 2022 1:48 PM > > To: Roman Danyliw <r...@cert.org>; ops-...@ietf.org > > Cc: acme@ietf.org; draft-ietf-acme-dtnnodeid....@ietf.org; > last-c...@ietf.org > > Subject: Re: Opsdir telechat review of draft-ietf-acme-dtnnodeid-10 > > > > Roman, > > > > Can you give me a few names with who I can chat to find out more? > > > > Thank you > > > > Linda > > > > On 10/21/22, 12:38 PM, "Roman Danyliw" <r...@cert.org> wrote: > > > > 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.dun...@futurewei.com> > > > Sent: Friday, October 21, 2022 12:46 PM > > > To: Roman Danyliw <r...@cert.org>; ops-...@ietf.org > > > Cc: acme@ietf.org; draft-ietf-acme-dtnnodeid....@ietf.org; > last- > > c...@ietf.org > > > 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.dun...@futurewei.com> > > > 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" <r...@cert.org> > 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 <nore...@ietf.org > > > > > > Sent: Thursday, October 20, 2022 6:55 PM > > > > To: ops-...@ietf.org > > > > Cc: acme@ietf.org; > draft-ietf-acme-dtnnodeid....@ietf.org; last- > > > c...@ietf.org > > > > 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 > > > > > > > > > > > > > > >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
