Hi Gunter, It was actually discussed with Ketan during his IESG review, and we decided to remove it from the header. I still think it was the right decision.
Excerpt from the email: -------------------------------------------------- Hi Ketan, Revision 17 addresses your latest comments. I’m sending the text and the diff (enclosed) since I can’t post it due to the cut-off at the moment. Please see in-line for those that needed follow up. Thank you very much, your review was very thorough and to the point! Jorge From: Ketan Talaulikar <[email protected]<mailto:[email protected]>> Date: Monday, March 2, 2026 at 10:20 AM To: Jorge Rabadan (Nokia) <[email protected]<mailto:[email protected]>> Cc: The IESG <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: Ketan Talaulikar's Discuss on draft-ietf-bess-evpn-ipvpn-interworking-15: (with DISCUSS and COMMENT) CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Jorge, Thanks for sharing the significant update and your responses. Please check inline below for follow-on and clarifications/suggestions. For the ones without responses, please consider them closed. I see that this version claims to "update" RFC4271. This is just not right. This document clearly does not apply to SAFI 1 which is what RFC4271 specifies. Please remove this tag. The last thing that we want is that every spec that tweaks/adds something for a specific AFI/SAFI/feature to claim "updates" on RFC4271. One might say that this "updates" tag applies to RFC4364 or RFC7432 but even that is not really true since DPATH is an optional feature and not an update to these base specifications for IPVPN and EVPN. Hence, I do not understand the case for this "updates" tag. It looks like this confusion came about because of the following text in the abstract, which probably can be deleted: As a result, this specification updates the BGP best path selection procedure, but only in the context of IPVPN and EVPN route families. And further in the introduction, I would suggest the following: CURRENT: Accordingly, this document updates the BGP best path selection procedures specified in [RFC4271<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ipvpn-interworking-16.html#RFC4271>], but only in the context of IPVPN and EVPN families. SUGGEST: Accordingly, this document updates the BGP best path selection procedures specified in [RFC4271<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ipvpn-interworking-16.html#RFC4271>], but only in the context of IPVPN and EVPN families when interconnecting domains using the D-PATH attribute. [jorge] The “updates” was added in rev 16 based on one of the reviews. It is gone in rev 17. I removed the sentence you suggested too. In the intro I took your suggestion, slightly modified (hope it’s ok): CURRENT: Accordingly, this document updates the BGP best path selection procedures specified in [RFC4271<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ipvpn-interworking-16.html#RFC4271>], but only in the context of IPVPN and EVPN families. NEW: Accordingly, this document updates the BGP best path selection procedures specified in [RFC4271<https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ipvpn-interworking-16.html#RFC4271>], but only for the IPVPN and EVPN families when the D-PATH attribute is used for inter-domain connectivity. -------------------------------------------------- Thanks. Jorge From: Gunter Van De Velde <[email protected]> Date: Tuesday, November 10, 2026 at 6:50 AM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>; gunter <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Gunter van de Velde (Nokia) <[email protected]>; Adam 1. Simpson (Nokia) <[email protected]>; Jorge Rabadan (Nokia) <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [Technical Errata Reported] RFC10039 (9290) [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi All, For this errata it seems that the header lacks “Updates: 4271”. Section 1 nevertheless explicitly says it updates RFC 4271’s best-path procedures. Is that correct? Or was this omission intentional? G/ Sent from my iPad > On 5 Nov 2026, at 17:54, [email protected] wrote: > > The following errata report has been submitted for RFC10039, > "Interconnecting EVPN and IPVPN Domains" > > -------------------------------------- > You may review the report below and at: > https://errata.rfc-editor.org/eid9290/ > > -------------------------------------- > Type: Technical > Reported by: Paul Aitken <[email protected]> > > Section 1 says: > > Original Text > ------------- > Accordingly, this document updates the BGP best-path selection procedures > specified in [RFC4271] > > Corrected Text > -------------- > . > > Notes > ----- > The document header does not carry an "Updates: 4271" clause, and the > Abstract does not mention the update. Either the header and Abstract should > reflect the update relationship, or the normative-sounding "updates ... > [RFC4271]" text should be softened to describe the extension without > asserting a formal "Updates" relationship. > > Instructions: > ------------- > This erratum is currently posted as "Reported". Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC10039 (draft-ietf-bess-evpn-ipvpn-interworking) > -------------------------------------- > Title : Interconnecting EVPN and IPVPN Domains > Publication Date : September 2026 > Author(s) : J. Rabadan, Ed., A. Sajassi, Ed., J. Drake, W. Lin, J. > Uttaro, A. Simpson > Category : Proposed Standard > Source : bess (rtg) > Stream : IETF > Verifying Party : IESG
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
