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

[Christer Holmberg <[e-mail]>]

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.

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