Hi Christer, thank you very much for the review. Sorry about the late response, I'm currently traveling.
See my replies in-line. Best regards Michael > On 4. Jun 2018, at 05:17, Christer Holmberg <[email protected]> > wrote: > > > Re-sent due to wrong e-mail address. > >> >> Hi, >> >> I have also looked at this document, and there are things that I have >> think are unclear: >> >> Q1: It is Informational, and it does not update RFC 4960. Instead, it just >> seems to list the erratas (but without even referencing them, as noted by >> Paul). I think that it should be made very clear that this document is >> only for guidance, and that implementers shall use the actual erratas for >> the actual updates. Please note that the documents covers the following processed erratas and also mentions this: * https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.1 covers Errata ID 1440. * https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.2 covers Errata ID 1574. * https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.3 covers Errata ID 2592. * https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.4 covers Errata ID 3291 and Errata ID 3804. * https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.5 covers Errata ID 3423. * https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.6 covers Errata ID 3788. * https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.7 covers Errata ID 4071. * https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.8 covers Errata ID 4400. * https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.9 covers Errata ID 5003. Other sections deal with problems not necessarily reported as erratas using the IETF errata tool. >> >> Q2: Unless I’ve missed it, there is no indication whether the draft only >> includes the Verified erratas, or also others - in which case the modified >> text in one or more erratas may still be changed (erratas may even be >> rejected). See above. >> >> Q3: While the draft name contains “-errata-“, it is unclear whether the >> draft only covers issues for which erratas has been filed, or whether >> other issues (e.g., issues that have been discussed on the list) are also >> included. See above. >> >> Q4: When looking at the changes, at least in one case I can’t find an >> associated errata. For example, section 3.34 is associated with Section >> 10.1. I only find one errata (#5003) associated with Section 10.1, but the >> changes in that errata does not match what is in the draft. A reference to >> the actual errata would help. See above. >> >> Q5: The text says that the draft includes issues found since publication. >> Now, there may be more issues after this draft has been published, so it >> should say something like “at the time of publishing this document”. We can add such wording. >> >> 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. As indicated by Gorry, the plan is to build a 4960bis once this document is done. Then a developer has only a single RFC to implement. If he wants to know which changes have been done and why it an consult this informative document. >>> >>> 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. In the past it was not that critical. Especially, once RFC 4960bis is out. >>> >>> 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. Please note that every subsection of section 3 covers an issue, but not one errata listed in https://www.rfc-editor.org/errata_search.php?rfc=4960 >>> >>> 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'. Fixed in the repository: https://github.com/sctplab/rfc4960bis/commit/650416a74049578aeea6c0e6098815f746ecc778 >>> >>> _______________________________________________ >>> 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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
