Hi Gorry, ...
>The information in this document does not update RFC4640 or the Errata >to that specification. The document is instead provided as input to >preparation of a new document that is expected to be a standards-track >replacement for RFC4960. If approved, the replacement document will >incorporate the updates described here and any other changes needed to >allow this to progress this specification along the standards track. I am ok with the two first sentences. But, I don’t think you can make the last sentence. This document cannot normatively define text for the replacement document, or assume that everything will be incorporated: the WG will have to agree on what goes into the replacement document once it has been added to the charter etc, using normal IETF procedures. Regards, Christer >>> >>> On 03/06/18 21:59, "Gen-art on behalf of Paul Kyzivat" >>> <gen-art-boun...@ietf.org on behalf of pkyzi...@alum.mit.edu> 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 >>>> Gen-art@ietf.org >>>> https://www.ietf.org/mailman/listinfo/gen-art >>> _______________________________________________ >>> Gen-art mailing list >>> Gen-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
