Tiger, Some of these questions are impacting progression of the DMZ draft. Would you please respond:
On Wed, May 06, 2026 at 10:02:01AM -0400, Jeffrey Haas wrote: > [Speaking as an IDR chair and the shepherd for the DMZ document in this > response] > > > Fourth, the new use cases and associated technical approaches introduced in > > draft-ietf-bess-ebgp-dmz -07 (published 20 July 2025) were already fully > > and explicitly documented in draft-xu-idr-fare -00 (released 1 July 2024). > > There are certainly overlaps in the problem space between the DMZ and FARE > documents. draft-xu-idr-fare-00 was issued on January 2025. The DMZ draft > had been getting work done on it over several years with refining use cases. > Is there a specific use case you are referring to here? If so, please > clarify what section in the document you're discussing. > > Also, is there a concern that there is work covered in that overlapping > portion of the documents that have undisclosed IPR considerations? Or, is > this more a matter that the DMZ document appropriated a use case without > attribution to its contributors? The above impacts both attribution and IPR. > > Further detailed analysis is presented below. IMHO, the IETF, as a leading > > global standards-setting body, ought not to endorse or tolerate such > > non-compliant community practices. Allowing such precedent would undermine > > the IETF’s reputation for impartiality and erode its ecosystem of original > > technical innovation. > > I'll address the technical points below, but what "non-compliant community > practices" are you referring to? Please be explicit. Would you clarify what non-compliant practices you're discussing? > > 2. Issues and solutions introduced in version -08 > > Version -08 adds: > > “In addition, as illustrated in the previous sections, BGP may have to > > consider a combination of the local link and remote bandwidth when > > computing the weights for weighted load‑balancing. Any function of the two > > may be used like for instance a ‘minimum’ function … The weight of each > > path may then be based on either: only the remote bandwidth, only the local > > link bandwidth, or a function of both.” > > This introduces the minimum function (choosing the smaller value between > > the link bandwidth and the path bandwidth of the received route). The draft > > also acknowledges for the first time the necessity of path bandwidth: > > “In our example, the value 30Gbps advertised by R3 represents an aggregated > > path bandwidth.” > > Again, both the minimum function and the concept of path bandwidth were > > already described in draft-xu-idr-fare version -00. > > For this point, I'll ask that the DMZ authors respond to the provenance of > the use case. I'd also suggest to the BESS chairs and AD to halt progression > of the document until that point is settled. Minimally, if there's an issue > of attribution, that should be addressed. > > Further, I ask again on this point where there is undisclosed IPR that you > consider an issue for this use case? Would you clarify if there's undisclosed IPR considerations? -- Jeff _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
