This concludes the WGLC comment period. Here is my assessment: Supports advancing the document for publication: Zafar Ali, Cisco Jeff Tantsura, Nvidia (as coauthor) Krishnaswamy Ananthamurthy, Cisco Mankamana Mishra, Cisco Jishnu Roy, HPE Kaliraj Vairavakkali, HPE - specifically as with INFORMATIONAL status. Julian Lucek, HPE
Does not support advancing the document for publication: None. Issues raised: Kaliraj notes: > 4.2. for consistency reason, all BGP paths of a prefix MUST use a > contributing bandwidth based on the same source (e.g.: all paths are using > contributing bandwidth from the same function). I see that Reshma has taken this up and is responding the raised point from Stephane. Implementation Reports: No implementation reports were sent as part of last call. That said, I'm personally aware of at least one implementation and will prod that party to publicly respond. It would be good if more than one implementation report were submitted, but this isn't required by BESS practices. Assessment: My assessment as shepherd is that we have light support for advancing the document and no requests to not publish at this time. My recommendation would be that once the point flagged by Kaliraj has been addressed that the chairs request publication. Once the BESS chairs have made their assessment, I'll update the shepherd report for this document. As a comment on the related WGLC for RFC 4360-bis in IDR, support has been very light and no objections have been filed. There are two minor comments flagged during that last call to be assessed by the shepherd, Keyur. -- Jeff (acting as shepherd) > On Mar 23, 2026, at 11:24, Jeffrey Haas <[email protected]> wrote: > > While we have received a few positive replies about advancing this draft to > publication, response is very light and difficult to use to gauge consensus. > > Similar to the RFC 4360 draft, we're extending the last call to 30 March. > > Please respond to this thread as to whether this document SHOULD or SHOULD > NOT proceed to publication. > > -- Jeff > > >> On Mar 3, 2026, at 12:07, Jeffrey Haas <[email protected]> wrote: >> >> https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/ >> >> As the shepherd for the DMZ draft, this starts a working group last call for >> draft-ietf-bess-ebgp-dmz.. This last call ends on 16 March. >> >> Please indicate to the mailing list whether you think this document is ready >> to advance to publication or not. >> >> The shepherd writeup for this document is located here: >> https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/shepherdwriteup/ >> >> Note that we are still waiting for an IPR attestation from Arie Vayner. >> Other working group members that are aware of undisclosed IPR are requested >> to attest to it as part of IETF BCP 78/79. >> >> As per BESS practices, this last call is also polling for the existence of >> implementations of this draft. See this prior note on the practice: >> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw/ >> >> Please also note that there is a related last call happening in IDR relating >> to RFC 4360-bis. As BESS WG members are aware, the DMZ work was motivated >> to address the transitivity aspects of the BGP link-bandwidth extended >> community as part of the DMZ aggregation procedures. The link bandwidth >> draft has completed IDR last call and has been sent to the IESG for >> publication. The related work to address originating non-transitive BGP >> extended communities was moved into the RFC 4360-bis work. >> >> Thus, if you believe DMZ should progress, please respond to the IDR last >> call on 4360-bis to help both works advance together. >> >> https://mailarchive.ietf.org/arch/msg/idr/fftaCU5jpiYynWFfgex0dkjXB4E/ >> >> -- Jeff >> > _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
