Last Call Review of draft-ietf-tsvwg-rfc4960-errata-06
review-ietf-tsvwg-rfc4960-errata-06-genart-lc-kyzivat-2018-06-03-00

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'.