Not a comment on the document, but a question/suggestion: If you want to have a place holder for changes to be done in the bis (which seems to be the main purpose of the errata document), why not create a GitHub repo for the bis, and then document everything as GitHub issues? Then, when you start working on the bis, you can map each issue to a pull request etc.
Regards, Christer On 04/06/18 13:13, "Gen-art on behalf of Christer Holmberg" <[email protected] on behalf of [email protected]> wrote: > >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" >>>> <[email protected] on behalf of [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 >> >> > >_______________________________________________ >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
