Re: [Gen-art] Gen-ART Last Call review of draft-ietf-tsvwg-rfc4960-errata-06

[Christer Holmberg <[e-mail]>]

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"
<[e-mail] on behalf of [e-mail]>
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"
>>>> <[e-mail] on behalf of [e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/gen-art
>>>> _______________________________________________
>>>> Gen-art mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/gen-art
>>
>>
>
>_______________________________________________
>Gen-art mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/gen-art