[rfc-i] Some questions on the model and the motivations
olaf at NLnetLabs.nl
Tue Jan 4 12:43:29 PST 2011
On Jan 4, 2011, at 12:57 AM, Dave CROCKER wrote:
> On 1/3/2011 7:16 AM, Russ Housley wrote:
>>>> 1.b) Suppose we would redesign the model to get rid of the RSE, what responsibilities would need to be assigned ownership, where would you assign those responsibilities in the current 'greater IETF'?
>>> I do not believe this would be wise and do not have a recommendation for doing so. If I had been
>>> able to find a way to do this without an RSE I would have recommended. Since this is contrary to
>>> the way the Editor has operated for the last 40 years, we are entering unknown, and potentially risky,
>> This comes across as a flip answer. I really think it deserves a more.
> Or much less...
> "We are responsible for doing x. Please help us by doing y".
> After some months... "OK. Here is y."
> "You didn't do z."
> After some weeks... "OK. Here is z."
> "What if we didn't do x?"
> "I think that would be a mistake."
> "That's a flip answer."
> By my own reading of Glenn's note, it was extensive, thoughtful and consistent with the documents he has previously issued. His response to this one question was brief because there was so much context providing foundation leading up to that note and in it.
> If his response to that one questions seems insufficient, perhaps the real requirement is to read and think about the surrounding material more carefully.
> Frankly Glenn should simply have declined to respond to a set of questions from the IAB Chair that were far out of scope from his existing assignments and served only to provide one more opportunity for us to start over with yet-another line of questions to consider.
FWIW I asked the question as 'Olaf (No Hats)'. I realize that the hat is never really off, but it was to signal a more personal question.
More importantly, after reading the thread (I only respond here for context) I feel like I should explain my motivation for asking the questions.
On question 1a)
The first time the community has been exposed to a plan and a motivation was during the Beijing IETF. My impression was that the presentation layer at that time was not found sufficient for a content full, substantive, and fact based exchange of thoughts.
Shortly before the X-mass holidays the motivation was posted and only then the community got a serious opportunity for discussion of the drafts. I believe that the IAB will need to make a decision based on having seen the community discussion, and after the community understanding the trade-offs. In my role as chair I am trying to get towards a process that allows the community to chime in and be informed.
I have suggested many times to post early and often, that has not happened and we are now at a point where we, according to the initial milestones should have somewhere in the middle of the hiring process. In other words, we are delayed.
My question about timing was targeted to getting an answer on whether we could do without a RSE or TRSE while we are completing this reorganization. My own feeling is that is in the order of a few months as long as there is a (volunteer) point person for escalation purposes, and that is what I read in Glen's answer although I had hoped to get a direct answer.
> The handling of the RSE topic has been marked by constantly changed goals, disconnected suggestions and criticisms dropped into the mix without context or followup, debates about terminology rather than content, and criticism of the consultant as if he has the responsibility for resolving this topic. He had responsibility to formulate recommendations. The IAB has the responsibility for doing the work of evaluating, adapting, and implementing them. The discussion on this list is, at best, an adjunct to that process; it is not a replacement.
But as argued above, it is a necessity, as it should inform the IAB on whether the decision they are about to take will be supported by the community. As with any reorganization project one needs a critical mass of support in order for the reorganization to be successful.
> If someone wants to argue that we should go down a radically different path, such as not having an RSE, it is their responsibility to do the work of making that case.
> Tasks for the RSE have been documented. If someone believes they do not need doing, explain why. If someone believes the tasks will be performed by someone else, then say who and say why it is plausible to believe the tasks will get done.
> Constructive debate requires focus and incremental refinement. It requires engaging with what has already been presented, by offering comments that support it, criticisms that find specific flaws with it, and suggestions for improvements.
> We need to see postings that develop incremental, connected threads of thought about the substance of the work to be done and the skills needed to do them.
On question 1b): I have tried to ask _open_ questions that allowed Glenn to motivate the choices and the trade-offs that he made. I would hope that as a management consultant Glenn did think about what the tasks are of the RSE and if they could have been re-distributed in different ways. His assignment was open enough to allow such and I think he has implicitly done so. And frankly I believe that 'we've done so for 40 years' is not the best motivation for sticking to the model of an RSE as an independent leg in the model that we introduced in 5620.
Maybe I should have asked the question slightly different:
Have you considered to redistributing the responsibilities that you identified are needed for Series Continuity in different ways? What were the trade-offs that made you choose for staying close to the model of 4 legs from RFC5620?
That question is not asked because I believe other models work better, but to make explicit whether or not they have been considered by Glenn. And also, to expose strengths and weaknesses of those alternatives and the direction that Glenn recommends.
Olaf M. Kolkman NLnet Labs
Science Park 140,
http://www.nlnetlabs.nl/ 1098 XG Amsterdam
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2210 bytes
Desc: not available
More information about the rfc-interest