Hi, >>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. >We did use a github report using issues which working on this document. > >Replacing this document with an github issue tracker doesn't seem >attraktive to me. Github can go away at any time or gets replaced >by other tools and than the information would not be accessible >anymore. Please note that we document the changes and the reasoning >not for us, but for developers which are interested in it in the >future.
Sure, but my understanding is that the future, i.e., the bis document, is coming soon, and I guess the bis document will anyway describe the changes (and the reasons) compared to RFC 4960. Anyway, since I haven’t been involved in the work, I don’t want to argue about the way the WG is working. It was just a question/suggestion :) Regards, Christer >>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
