Paul, thank you for your review. I have entered a Discuss ballot for this document, to make sure your review gets responded to and then discussed by the IESG.
Lars > On 2021-10-13, at 20:04, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for the > IETF Chair. Please wait for direction from your document shepherd or AD > before posting a new version of the draft. For more information, please see > the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-bess-evpn-bum-procedure-updates-11 > Reviewer: Paul Kyzivat > Review Date: 2021-10-13 > IETF LC End Date: 2021-09-07 > IESG Telechat date: 2021-10-21 > > Summary: > > This draft has serious issues, described in the review, and needs to be > rethought. > > General: > > This review is substantially the same as my Last Call review. The authors > disagreed with my primary concern, but neither did they dissuade me from my > opinion. I understand that this largely a matter of philosophy and style. I'm > repeating my concern here for consideration by the IESG. What follows is > verbatim from my LC review. > > My review of this document is limited because I have no knowledge of the > subject domain. Nevertheless I think I was able to grasp the gist of what > this document intends to achieve and identify a concern. However it is > possible that I have misunderstood and so my comments may be off base. > > While I have no reason to doubt the mechanisms specified, I think the manner > in which they are specified is likely to lead to confusion and > misunderstanding by developers. > > IIUC, RFC7117 improved the handling of BUM traffic for VPLS, but did not > address BUM traffic for EVPN. Then RFC7432 specified how to handle BUM > traffic for EVPN while referencing RFC7117 for some of its procedures, even > though RFC7117 had no provision for support of EVPN. > > It appears to me that someone who had an implementation of RFC7117 for VPLS > might have had to modify it to support RFC7432, yet RFC7432 did not indicate > that it updated RFC7117. The developer would have had to infer what changes > were required. But at least the changes seem to be small and unlikely to be > misunderstood. > > The current document specifies in its heading and abstract that it updates > RFC7432, while not mentioning RFC7117. Yet section 2 says: > > ... For brevity, only changes/additions to relevant > [RFC7117] and [RFC7524] procedures are specified, instead of > repeating the entire procedures. > > From these it is ambiguous whether RFC7117 is or is not being updated. It > then goes on to state: > > Note that these are to be applied > to EVPN only, and not updates to [RFC7117] or [RFC7524]. > > This further clouds things. How could it be known how future updates to those > documents might interact with the changes in this document? > > In the remainder of the document I find no explicit text that appears to > normatively updates RFC7432. I find this mystifying. > > However there are numerous places that normatively change RFC7117. Several of > these are of the form: > > The following bullet in Section N.N.N.N of [RFC7117]: > ... > is changed to the following when applied to EVPN: > ... > > even though RFC7117 didn't contemplate supporting EVPN at all. This seems to > assume that an entirely different implementation of RFC7117 will be made for > EVPN and these modifications made to that, while not impacting > implementations of RFC7117 being used for other types of VPNs. Is this a > reasonable assumption? > > Overall it seems that it will be very difficult for a developer to read this > document and determine exactly what must be implemented, or after the fact to > determine whether an implementation conforms to this document. > > IMO a different style of specification is called for. Probably an RFC7117bis > and perhaps a RFC7432bis. > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
