On 10/1/23 04:26, S Moonesamy wrote:
Hi Keith,
At 07:18 AM 30-09-2023, Keith Moore wrote:
Having been on IESG myself, I would never tell ADs that their
workload is not a problem. And I certainly did not intend to imply
that.
I read your previous email as being about trade-offs.
It wasn't really about trade-offs so much as about overall direction and
goals of IETF. (If any organization is headed in the wrong direction,
doing so more efficiently can actually be counterproductive. So it's
important to get the direction right, or at least close to right, above
all else.)
But it's certainly worthwhile to think about trade-offs. And I do think
that the proposed reorganization will help a bit with that, even if I
also think that the proposed reorganization doesn't really address the
larger problems.
I took a quick look at the Apps and Real Time Area last week. That
Area has, if I remember correctly, 37 working groups. There are 10
working groups in the Transport Area. In my opinion, there is an
imbalance. I also looked at the 2021 job descriptions. It stated
that an ART AD should spend 50-75% of their time on IESG-related
activities. The average workload of a TSV AD was estimated at about
15 to 20 hours a week. A volunteer position which takes over 50% of
work time can end up being an unpractical commitment.
When I was an Applications AD it was a 100% time commitment, which is to
say, I generally spent about 60 hours per week on it. And yes, it was
impractical in multiple ways, and I had trouble keeping up with all the
WGs and the documents they produced. After four years of doing that I
was certainly burned out. But those years (1996-2000) were kind of an
exceptional time as the Internet was seeing a tremendous amount of new
interest, and I believe the period of greatest in-person participation
in IETF.
To me the huge workload in Applications said that the Applications area
needed to focus on the applications protocols that were most needed by
the Internet community, rather than merely balance workload between ADs.
(And I think IESG was better balanced then than it is now.) I
recognized then that IETF could not practically expand to cover all of
the Applications-related topics that needed standardization. And
unfortunately (at least IMO) a lot of applications became
vendor-specific web applications rather than applications based on
standard protocols. (Not saying that HTTP wasn't a standard, but rather
that HTTP framing wasn't a good fit for many kinds of applications, and
also that HTTP alone wasn't sufficient to encourage interoperability
between different implementations of the same application. Of course,
many vendors prefer walled gardens, but IMO walled gardens do not serve
the Internet user community well.).
Another angle to look into is the organizational aspect. The
Applications Area used to be a mix of several subjects, most likely
due to historical reasons. The Area went through two or three
reorganizations over the years. That's not a good sign, in general.
Applications is inherently a broad topic, so I don't think the mix of
several subjects was due to historical reasons. We used to talk about
"the hourglass" which was wide at the bottom (lots of different kinds of
transmission media), narrow at the waist (TCP,UDP,IP), and wide at the
top (wide variety of applications). We couldn't have adequately
covered the entire Applications Area with 5 APPS ADs, and trying to do
that would have strained IETF's ability to scale in many other ways.
You mentioned metrics in your previous email. I could not find
metrics by area on the web site. I also could not find the statistics
mentioned in the last paragraph of Section 3.1 of RFC 7760.
I don't know where they're kept, but it's pretty common to cite metrics
like number of RFCs published in a certain period, or average number of
days of delay between certain milestones in documents' development.
And those statistics are useful. But it's even more useful to have a
sense of whether IETF is producing what the Internet community needs,
it's just not as easy to measure that.
Keith
