Re: [Rfced-future] RFC Principles - long delayed

[Brian E Carpenter <[e-mail]>]

On 15-Nov-21 00:13, Adrian Farrel wrote:
> Thanks Martin, that's clear (to me).
> 
> I'm trying to imagine myself applying for the job of RSCE (for the avoidance of doubt, I will NOT be applying for that job). I would want to know the parameters of the job, and one of those would be "What is the RFC Series?"


I found myself wondering what we said when looking for the first external 
RSE in 2011. Not much, it turns out:

https://web.archive.org/web/20111006180950/https://www.rfc-editor.org/rse/RSE-Position-Description.html

Perhaps the candidates were given more details later in the process.

    Brian

> 
> While it s possible to give high-level definitions such as those currently in draft-iab-rfcefdp-rfced-model-05, those descriptions are superficial. I don't mean that in any derogatory sense, but they are general scoping statements of which the most detailed is:
> 
>     The Request for Comments (RFC) Series is the archival series
>     dedicated to documenting Internet technical specifications, including
>     general contributions from the Internet research and engineering
>     community as well as standards documents.
> 
> So, a cautious candidate would ask, perhaps at interview, "What are the 
guiding principles for the series, and where are these written down?" I'm 
not sure that we could provide and answer at the moment, and I would be very nervous about taking the job under those circumstances.
> 
> Yet, as I understand it, one of the roles of this program is to enable us to move on with recruiting an RSCE. I think it was Tommy who said that 
we should not presume on the time and energy of the iRSE, so surely we should get on with the tasks necessary to smooth the way.
> 
> And to pick up on what Nevil said, there should be no fear that writing 
this down makes it permanent. It is simply a statement of where we are today with the understanding that any changes can be effected by the RSWG. But if we don't write it down, we will fall immediately into arguments about whether any changes are, in fact, changes. If you want to see the RSWG fall at its first attempt to do anything, then I think not writing down 
the foundational principles would be a good way to go about it.
> 
> Cheers,
> Adrian
> 
> -----Original Message-----
> From: Rfced-future <[e-mail]> On Behalf Of Martin J. Dürst
> Sent: 14 November 2021 08:49
> To: Brian Rosen <[e-mail]>; Michael StJohns <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Rfced-future] RFC Principles - long delayed
> 
> On 2021-11-12 02:40, Brian Rosen wrote:
>> Mike
>>
>> Thanks for this.
>>
>> Prior to working on specific wording, I would like to understand how many of us think we need something a lot like this in our document.
>>
>> Alternatives to working on this proposed text might include:
>> 1. Nothing, we agree mostly, but don’t think we should be so proscriptive in this document
>> 2. Something a whole lot smaller that gets at the idea but without the 
detail
> 
> Having read everything in the thread up to now, my strong preference
> would be to have something like this, but a lot less verbose. The
> reasons have been pointed out in most detail by Carsten and John Klensin.
> 
> Without some kind of such principles, we essentially design process
> without a clear purpose. For some of the principles, such as English or
> Accessibility, I don't think there should be wide disagreement, and if
> ever the case comes that e.g. the language should be changed, I can't
> imagine that the okay needed from IAB and IESG (and LLC, but that should
> be restricted to funds issues) would actually create a higher barrier.
> 
> In my view, the situation is similar for the other principles. If we
> want to change the Diversity principle, then that would probably mean
> throwing out the IRE, IRTF, and possibly also the IAB stream(s). That
> won't happen very easily, because that would already mean we need IAB
> and IESG approval anyway.
> 
> Also, for speed vs. quality issues, if a change is desired, then quite
> surely if the IESG and the IETF isn't part of the deal, that won't
> happen, but if there's a consensus in the IESG and the IETF that that's
> needed, it will happen (at least for the IETF stream).
> 
> So either way (i.e. even without these principles), we should probably
> be able to keep things together.
> 
> But I'm quite definitely against the idea of the RSWG's first job being
> to write down such principles. If we can't manage to write them down
> now, we shouldn't think it would be easy for the RSWG. And it wouldn't
> be very easy to invite people to the RSWG by telling them their first
> job is to try to figure out why they are here.
> 
> Regards,   Martin.
> 
>> What do you think?
>>
>> Brian
>>
>>> On Nov 11, 2021, at 12:20 PM, Michael StJohns <[e-mail]> wrote:
>>>
>>> I apologize for the delay in providing the following.  This is the aftermath of Stephen's question/comment about heritage and it morphed into a document that attempts to describe current RFC series principles.  I've 
passed this by 1/2dz or so folk and this incorporates their comments.
>>>
>>>
>>>
>>>
>>> # Principles for the RFC Editor Series
>>>
>>> The following principles provide some guidance as to the scope of
>>> documents that the RSWG may propose and the RSAB may approve.
>>> Documents or proposals which suggest modifications of any of the
>>> principles shall require additional approvals past that of the
>>> RSWG/RSAB, specifically consent from the IAB, IESG and the LLC and
>>> such approvals shall be granted only after gaining strong community
>>> consensus for such a change.
>>>
>>>
>>> ## Availability
>>>
>>> The RFC series documents have been freely available digitally for more
>>> than 35 years.  No change shall be made to the model which would
>>> introduce fees for access to any or all of the RFC series documents.
>>> Distribution of RFCs shall continue to be subject to the Trust
>>> license<<REF:
>>> https://trustee.ietf.org/documents/trust-legal-provisions/>>.
>>>
>>> ## Accessibility
>>>
>>> There is a general goal to make the RFC series documents as accessible
>>> as possible to communities that have special needs - e.g. seeing
>>> impaired. Proposals that might negatively impact accessibility shall
>>> require the approvals of the IESG, IAB and LLC in addition to that of
>>> the RSAB.
>>>
>>> ## Publication Language
>>>
>>> The publication language of the series is, and shall remain, English.
>>> No action shall be taken which will prohibit the publication of
>>> translations of the RFC series in other languages, but the normative
>>> content language of an RFC shall remain English.
>>>
>>>
>>> ## Commonality of Purpose
>>>
>>> The RFC series is the general publication system for information
>>> related to the Internet, networking technology, and community
>>> discussions on those topics.  Neither an expansion nor contraction of
>>> that scope is desired.
>>>
>>>
>>> ## Diversity of Interests
>>>
>>> The RFC series has published thought experiments, speculative ideas,
>>> research papers, histories, humor [RFC1149, RFC2549], and even
>>> eulogies [RFC2468].  And, more recently, Internet standards.  Each of
>>> these RFCs and their communities have contributed to the rich history
>>> of the RFC series, and to its somewhat human-centric take on networking.
>>> If we did not acknowledge this and attempt to conserve the means of
>>> such expression we would probably be poorer for it.
>>>
>>> As the Independent Stream and IRTF Stream are the primary places that
>>> non-standards related conversations take place, and with a desire to
>>> maintain diversity of interests in the system, neither of these
>>> streams may be disestablished except by the approval of the IESG, IAB,
>>> LLC Board, and with strong community consensus.
>>>
>>> The RFC brand shall not be reserved at any time now or in the future
>>> solely to apply to a single community of interest i.e., IETF
>>> publications.
>>>
>>>
>>> ## Breadth of Expression
>>>
>>> While the RFC series has its own brand and style, the series is
>>> expected to account for individual expression where possible.
>>>
>>> ## Archival Quality
>>>
>>> Paraphrasing from the introduction to [RFC8153]:
>>>
>>> The RFC Editor System provides both publication and archival services
>>> for the RFC Series, although there is nothing prohibiting those roles
>>> being split apart. In the archival role the main goal is to preserve
>>> both the information described and the documents themselves for the
>>> indefinite future.  To meet both publication and archival needs, the
>>> RFC Editor System must find the necessary balance between the
>>> publication needs of today and the archival needs of tomorrow, while
>>> acknowledging a finite set of resources to complete both aspects of
>>> the RFC Editor System functions.
>>>
>>> As there may be legal implications related to changes in archive
>>> policy, changes in the applicability of RFC8153 to the RFC Series, and/or
>>> changes to RFC8153 shall require the approvals of the IAB, IESG and
>>> LLC in addition to RSAB approval.
>>>
>>>
>>> ## World-class Publication
>>>
>>> As a world-class publication, quality, readability and accuracy are
>>> key to the success of the RFC Series. The publication process is
>>> designed in part to enhance those characteristics.  Unfortunately,
>>> those ideals are sometimes at odds with a desire for an increase in
>>> speed of publication.  Any RSWG proposals that promote speed at the
>>> expense of quality, readability or accuracy shall require the
>>> approvals of the IESG, IAB and LLC in addition to that of the RSAB.
>>>
>>> -- 
>>> Rfced-future mailing list
>>> [e-mail]
>>> https://www.iab.org/mailman/listinfo/rfced-future
>>
>