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

[Gorry Fairhurst <[e-mail]>]

+1, as Chair. I see we have caused a little confusion here - The WG will 
not repeat this list of changes again as a part of the new .bis document.

There could always be potentially be further changes as the .bis 
document passes through the WG - of course - but we'd rather expect this 
spec is mature -- indeed there was suggestion the final Spec could 
progress to Full Standard (to be confirmed of course).

Gorry

On 07/06/2018, 11:19, Michael Tuexen wrote:
>> On 7. Jun 2018, at 02:43, Christer Holmberg<[e-mail]>  wrote:
>>
>>
>> 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.
> Hi Christer,
>
> no it doesn't. It will be basically RFC 4960 + the diff from the errata
> document applied.
>
> We did this in the past. See
> RFC 2960 as the initial specification of SCTP.
> RFC 4460 as an errata document
> RFC 4960 as the updated specification of SCTP.
>
> As you see, RFC 4960, does not tell you what has changed or why.
> If a developer is not interested in that and just wants to
> implement SCTP, only the reading on RFC 4960 is needed. If
> someone wants to understand the changes, he can read RFC 4460.
>
> Best regards
> Michael
>> 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"
>>>> <[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