Paul, thanks for your review. I have entered an ABSTAIN ballot on the basis of your major issue highlighted below.
Alissa > On Jun 3, 2018, at 2:59 PM, Paul Kyzivat <[email protected]> wrote: > > [[INCOMPLETE, NOT READY TO SEND. PLEASE IGNORE]] > > 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 treat these comments just like any other last call > comments. For more information, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Document: draft-ietf-tsvwg-rfc4960-errata-06 > Reviewer: Paul Kyzivat > Review Date: 2018-06-03 > IETF LC End Date: 2018-06-04 > IESG Telechat date: ? > > Summary: > > This draft is on the right track but has open issues, described in the review. > > Issues: > > Major: 1 > Minor: 2 > Nits: 1 > > 1) MAJOR: > > The format of this document disturbs me. According to the abstract: > > ... This > document provides deltas to RFC4960 and is organized in a time > ordered way. The issues are listed in the order they were brought > up. Because some text is changed several times the last delta in the > text is the one which should be applied. > > This format makes the document hard to deal with. A developer who wants to > implement sctp with some or all of the errata fixes will want to work from a > variant of 4960 that incorporates all of those fixes - a bis. But it isn't > clear how this document helps with that. I don't think you can start with > 4960 and simply apply all the deltas sequentially, because overlapping > changes won't work right. > > A developer won't be interested in the order in which errata were reported. > An actual bis document would be more useful to a developer than this format. > Is that not being done because doing so would be more difficult? Or because > it isn't yet certain that these are the correct fixes? > > I think you should give some serious consideration of the most suitable form > for this document, in the context of how it is intended to be used. > > 2) MINOR (maybe MAJOR): > > Discovering where one change is impacted by another change is hard. > > I dug into the details of the document to understand how many places there > are actually overlaps between the changes in multiple sections. (It took a > lot of work to do this.) I found five of these: > > - 3.1 / 3.23 > - 3.3 / 3.43 > - 3.5 / 3.10 > - 3.6 / 3.23 > - 3.24 / 3.32 > > (I don't guarantee that this list is exhaustive.) > > Of these, I think only one (3.1/3.23) explicitly indicates the conflict, and > it only indicates it within 3.23. > > Most of the changes don't have any conflicts. And some of the conflicts could > be removed by being more precise in indicating the change being made. In > cases where this isn't possible, the presence of the conflict should be > indicated in each section that has a conflict, with cross references. IOW, > shift the burden of detecting conflicts from the reader to the document. > > 3) MINOR: > > Errata Tracking: Apparently each subsection of section 3 covers one erratum. > But the errata numbers are not mentioned. Each section ought to reference the > errata number it responds to. > > 4) NIT: > > In section 3.35 (DSCP Changes) the change to section 10.1 isn't properly > indicated. It shows 'Old text' twice rather than 'Old text' and 'New text'. > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
