Re: [rfc-i] RSOC name

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Tue, Jul 30, 2019 at 12:29 PM Christian Huitema <huitema@xxxxxxxxxxx> wrote:


On 7/30/2019 4:11 AM, Eliot Lear wrote:
...

Lest there be any doubt about who had the last word as to what went into an RFC back then, it was Jon and no one else.

That was true then, in 1991. But that power did not last, and after 1992 it was effectively withdrawn.

  Jon made this point very clearly at the 1991 Atlanta meeting, in which a shouting match took place during the plenary between him and Frank Kastenholz, chair of the Ethernet-MIB working group after Jon changed some variables before releasing the final copy.  Jon’s position at the time, after shouting expletives from the back of the room was, “I am not going to publish a faulty specification as an RFC.”  It was notably the “I” word that stood out then as it does now.(*). You can find the more politely minuted version of this debate on Page 29 of the Proceedings. 

This was also a hot topic during the next meeting, in 1991 in Santa Fe. And indeed, one of the debate in the meeting was whether "we should get rid of the IAB".


The IAB backed Jon up, probably because he was right about the technical error, even if the process wasn’t well defined.  And so that did lead to a discussion about the IAB’s role in the process, well prior to the Kobe Cabal and Boston Massacre; but in my memory, neither Jon nor Bob wavered from their positions that they were final arbiters over the series, though neither actively sought confrontation with the IETF or the IAB, but instead sought to facilitate the organization’s goals.  The limits of the RFC Editor’s authority has never really tested.

That is not my understanding. In fact, the post Kobe reaction was pretty much informed by the Ethernet event. A lot of the debate was about the checks and balance of the IETF, and specifically whether and how the consensus of a working group could be overwritten. In the pre-Kobe organization, the IAB was on top, and the IETF was defined very much as an activity organized and supervised by the IAB. The RFC Editor was part of that organization, definitely on top of the working group.

Post Kobe, that changed. The IAB's powers were pretty much vacated. The power to review and approve standard track RFC was moved to the IESG, which itself was constrained by process. The community did not want to have some external authority exert arbitrary power, whatever the curriculum and historical achievements of this authority. So there is a reason why none of RFC editors ever tried to block the publication of an IESG-approved RFC. They simply do not have that power. It was removed in the post 1992 organization.

The RFC editor, and now the stream editor, do on the other have the power to publish RFC that the IESG does not approve. I personally think it is an important parts of the process, to balance the power of working groups and the IESG and ensure that a diversity of opinions can be expressed. That's pretty much the point that was reaffirmed in RFC 1796.


This trip through memory lane explains the past, but doesn’t dictate the future.

Absolutely. The main focus of the IETF ought to be the future, not the past. The past provides us with guiding principle, open standards for an open Internet. But the present story is one of gradual shrinkage. The IETF gave up standardizing the web, the mobile networks, or the access networks. We have a hard time bringing in new work that instead develops in open source projects. In general, we have a hard time attracting young people. If the trend continues, the IETF will continue shrinking and concentrate on core protocols like IP, TCP, DNS, BGP, TLS and HTTP, until some enterprising groups start chipping at that too. As the IETF influence diminishes, so will the importance of the RFC series. I don't think we are going to solve that by having our eyes fixated on the past glories of the 80's.


The IETF could stop treating newcomers as subordinate and thus inferior and instead consider work that's been outside of current participants purview more openly to cultivate it and they may try harder to then bring that work in.  I've seen several recent cases where work was not encouraged despite interest, where it should be cultivated instead of turned away.  This is getting onto a separate topic, but goes back to treatment of participants across the board.  In terms of protocols, we have quite a bit in the routing overlay space and in security, there is plenty of new work on endpoints (TEEP, SUIT, and RATS are all fairly new).  

Do we really need to talk about "power" and people being "subordinate"?  If subordinate were talked about as "in support of", I could buy into that but not as "inferior" in which actions can easily be taken on their role/position.  In all the presented options, there are ways to end contracts or positions and there are ways to assume a high level of respect for peers and instill that into our culture.

Best regards,
Kathleen

-- Christian Huitema

_______________________________________________
rfc-interest mailing list
rfc-interest@xxxxxxxxxxxxxx
https://www.rfc-editor.org/mailman/listinfo/rfc-interest


--

Best regards,
Kathleen

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux