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

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

FWIW,

On Thu, Jun 7, 2018 at 5:33 AM Gorry Fairhurst <[e-mail]> wrote:

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

Thanks, Michael and Gorry, for clarifying this.

I think everyone who lived through 4460 and 4960 knew this, and no one one
who didn't live through that knew it, so that's very helpful.

Spencer


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