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

[Spencer Dawkins at IETF <[e-mail]>]

Just chiming in as AD ...

On Mon, Jun 4, 2018 at 7:18 AM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> >>> 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.
> >And it wouldn't say those exact words of course!
> >
> >If I carefully composed actual text, it would be IETF-compliant;-)
>
> Great! :)
>

Your AD agrees with adding words like the ones you're discussing here, once
you figure out exactly what words should be added.

Spencer


>
> All I want is to avoid a situation where someone laters suggests some
> modified text for the bis, and the reply is that the text in the errata
> draft has already been agreed upon by the WG to be included in the bis.
>
> 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
> >>>
> >
>
>