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

[Christer Holmberg <[e-mail]>]

Hi,

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

In my opinion a bis should always describe (at least on a high level) what
changes have been done since the previous version. If for no other reason,
to help companies decide upon, and plan, updates to their products.

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

I guess that is my main question: if you already know how the bis is going
to look like, why not simply make the bis with the changes? :)

As you said above, once the bis work start, things may change in the WG
(or in the later reviews), so you cannot assume that the errata document
will be an 100% accurate description of what will go into the bis.

Anyway, I respect the decisions made by the WG, so as long as the
clarifications I originally requested are implemented I’m happy :)

Regards,

Christer




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