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

[Gorry Fairhurst <[e-mail]>]

Hi Christer,

As document shepherd for this SCTP process, I'll have a first go at 
responding. I think that for RFC4960 the Errata as filed still apply.

See below. The document authors can of course also propose answers to 
these questions....

Gorry

On 04/06/2018 10:17, Christer Holmberg 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.
The document write-up describes the process that has been used with SCTP 
updates, and this document follows this plan - this is information to 
help the WG prepare a bis document, that we plan to populate with these 
edits to the spec and adopt as a WG item in Montreal.

I'm OK with adding text to say this - and see later.
>> 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).
>>
>> 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.
There are other issues discussed on the list, and the text proposed here 
is what the WG has discussed and finally agreed upon to appear in the 
.bis document. It would be OK to add something about that.
>> 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.
I think it would be good to check that Errata refs are included where 
applicable, if we added the text you suggest in Q3.
>> 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”.
I agree, and I really should have spotted that- Sorry and thanks for 
noting this. I suggest as this ID now approaches publication to be 
clearer about the intended plans, by adding a para of text (to be 
discussed and finalised with my AD and Co-Chairs) to say something like:

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.

- and to add a corresponding note in the abstract.

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