> On 5. Nov 2018, at 11:48, G Fairhurst <gorry@xxxxxxxxxxxxxx> wrote: > > Thanks. As document shepherd, I'm sorry I didn't notice that. > > I think this is indeed good, and I'm confident RFC Ed would ask about this - I would suggest we retain the RFC number as well in the title in this case - because this DOES relate only to this particular RFC, and it will not apply to the next version of the specification when this comes to be published. My suggestion would therefore be: > > "Stream Control Transmission Protocol (RFC 4960) Errata and Issues" I would be fine with that change. Best regards Michael > > Gorry > > On 05/11/2018, 17:34, John C Klensin wrote: >> IESG, >> >> I hope this can be corrected quietly in editing (because >> otherwise we waste time on any appeal), but, for most of the >> last 50 years, we've avoided the use of RFC numbers as the main >> information-carrying element of document titles. While it was >> probably a fine working title within a working group devoted to >> the specific subject matter, unless one is either very familiar >> with the subject matter or really, really, good at remembering >> document numbers (presumably all nearly 8500 of them) "RFC 4960 >> Errate and Issues" conveys no information at all. Even there >> are no square brackets, it violates the RFC Editor's >> long-standing guideline against citations in Abstracts as well >> as the spirit of prohibitions of non-obvious abbreviations >> without spelling things out on first use. >> >> "Stream Control Transmission Protocol Errate and Issues" follows >> the title of RFC 4960 and would seem obvioss. Or, if the WG and >> the IESG want to get the number in, "Stream Control Transmission >> Protocol (RFC 4960) Errate and Issues" would seem plausible from >> an information content standpoint. >> >> Sorry I didn't catch this on Last Call, but I don't have time to >> follow efforts outside my area of technical expertise these >> days. I observe that this getting past WG review, IETF Last >> Call, and IESG review may reflect badly on the quality of our >> final reviews these days, but let's treat that as another issue. >> >> best, >> john >> >> >> --On Sunday, November 4, 2018 23:10 -0800 The IESG >> <iesg-secretary@xxxxxxxx> wrote: >> >>> The IESG has approved the following document: >>> - 'RFC 4960 Errata and Issues' >>> (draft-ietf-tsvwg-rfc4960-errata-08.txt) as Informational RFC >>> >>> This document is the product of the Transport Area Working >>> Group. >>> >>> The IESG contact persons are Mirja Kühlewind and Spencer >>> Dawkins. >>> >>> A URL of this Internet Draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc4960-erra >>> ta/ >>> >>> >>> >>> >>> >>> Technical Summary >>> >>> This document is a compilation of issues found since the >>> publication of the SCTP protocol specification as RFC 4960 >>> in September 2007 based on experience with implementing, >>> testing, and using SCTP along with the suggested fixes. It >>> 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 that should be applied. In addition >>> to the delta, a description of the problem and the details >>> of the solution are also provided. >>> >>> Working Group Summary >>> >>> This document was adopted 22nd August 2016, as an >>> Informational document to document the intended >>> changes to the base spec. This follows the same process >>> used to update RFC 2960 to RFC 4960 (where RFC 4460 >>> documents the changes between the two spec). >>> Publication of RFC 4460 had the advantage that base spec >>> implementers updating RFC 2960, did not then have to >>> derive the changes between the two RFCs. This process >>> also only required editorial work to complete publication >>> of RFC 4960. Since this plan had worked well, the >>> implementers of SCTP requested the WG to proceed in >>> the same way for the present work. The resulting document >>> progressed with input from the WG and SCTP implementers >>> was subject of a WGLC comments in Dec 2017. A revised ID >>> was presented to TSVWG, and received support for >>> publication. >>> >>> Document Quality >>> >>> There are existing implementations of the protocol. People >>> from the implementer community commented on and reviewed >>> this ID. The document represents consensus of the TSVWG. >>> >>> Personnel >>> >>> Gorry Fairhurst is the Document Shepherd for this document. >>> Spencer Dawkins is the Responsible Area Director. >>> >> >> >
<<attachment: smime.p7s>>
