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

[Christer Holmberg <[e-mail]>]

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
>
>