+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).
Gorry
On 07/06/2018, 11:19, Michael Tuexen wrote:
On 7. Jun 2018, at 02:43, Christer Holmberg<[email protected]>
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"
<[email protected] on behalf of [email protected]>
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"
<[email protected] on behalf of [email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
