FWIW, On Thu, Jun 7, 2018 at 5:33 AM Gorry Fairhurst <go...@erg.abdn.ac.uk> 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< > christer.holmb...@ericsson.com> 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" > >>>> <gen-art-boun...@ietf.org on behalf of christer.holmb...@ericsson.com > > > >>>> 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" > >>>>>>>> <gen-art-boun...@ietf.org on behalf of pkyzi...@alum.mit.edu> > 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 > >>>>>>>>> Gen-art@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/gen-art > >>>>>>>> _______________________________________________ > >>>>>>>> Gen-art mailing list > >>>>>>>> Gen-art@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/gen-art > >>>>>> > >>>>> _______________________________________________ > >>>>> Gen-art mailing list > >>>>> Gen-art@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/gen-art > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
