--On Saturday, December 27, 2014 08:25 +1300 Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
...
However, the merge with Transport is technically strange.
Agreed, there are four or five WGs in Transport that could
equally well be in Apps, and there are some in RAI that could
equally well be in Transport. But beyond that, I just don't
see the synergy. (Where we need synergy, we know how to create
it, e.g. the DART WG.) Wouldn't it be better to rebalance by
moving a few groups from RAI to Transport, and the solve the
RAI/Apps problem on its own? (Since I assume that everything
is on the table, there are 2 or 3 Apps WGs that could move to
Security, for example.)
Brian,
I agreed with everything you said up to the last sentence or two
but, given them, am going to violate my promise to myself to
stay out of this.
Speaking as an participant in ARPANET/Internet applications work
since long before the IETF existed, an observer of the
applications area during its entire duration, and a former Apps
AD, areas and area boundaries really do make a difference.
Certainly there are work items (and hence WGs) that overlap
between Apps and Security. There are, or have been, overlaps
between Apps tasks and almost everything one can think of -- the
two-way split of RFC 1122/1123 was merely the best division Bob
and the other participants in that effort could come up with at
the time, not a really bright and clear line.
But the differences area assignments make can have effects on
the Internet that go far beyond the management/steering of the
IETF. As an example, at and before the time of RRC 1123, the
DNS was considered an application. At some point, it was
reassigned into the Internet area (I don't remember the reasons
but recall them being a little bit arbitrary). A lot of the
focus since then has been on DNS features and operations as ends
in themselves. Questions like "how will this be used", "how will
it affect users", and "what will be the implications on the
Internet's applications architecture" have sometimes (or often)
gotten lost in the process. It is also the case that there has
never been a lot of deep database expertise in the IETF, but
there has almost always been more of it among active Apps area
participants than in the Internet area and that, too, has design
consequences, especially when discussions break out about, e.g.,
how far DNS-style aliases can reasonably be extended or what the
implications are of flattening a hierarchical database
architecture. Sometimes those discussions don't even happen, at
least until it is too late -- I think that is another
consequence of area choices.
The problem runs in both directions, of course. We've had a
lot of complete nonsense about what the DNS can be expected to
do in the Apps area. That nonsense has gotten caught and cut
off because ultimately implementability and physics still
usually triumph around here, but maybe better ideas would have
emerged had there been more informed discussion earlier.
The same issues end up at the Security / Applications boundary.
We've had things at that boundary done in Security that has
ended up with symptoms of too little involvement from those who
build and deploy things that face the user. And we've had
things done in Apps that have had security issues that have been
fixed too late in the process to do things really well.
Of course, that is another risk of a five-AD superarea. If
there is only one job description, and parts of it are easier to
fill than others, there is some risk of ending up with five
people with the same specializations and serious gaps in deep
understanding of the other topics covered by the area. We've
seen that before: while I think we've mostly been lucky,
combining Ops and Management did not nothing to guarantee that
the IESG would always have someone skilled and experienced in
Ops and someone skilled and experienced in Network Management.
I don't suggest there is an answer to how these choices should
be made. There are always tradeoffs. But I think we put
ourselves in jeopardy when we assume that a particular piece of
work can be placed in one area or another, even when it overlaps
somewhat, as a purely management decision with no protocol
design consequences.
One additional observation on Jari's note. I'm all in favor of
the YANG work, at least as far as I understand it. But, wishing
that Mike Padlipsky were here to say this in his much more
eloquent way, when a standards body starts concentrating major
energy on (in our case) network models and modeling rather than
on protocols and "what works" / "doing it right", it is in big,
perhaps fatal, trouble because the next step is for applied
network engineering and protocol design to start giving way to
models and rules that go beyond "works and interoperates" for
evaluating what is acceptable -- both the refuge of
theoreticians with too little connection to reality and
professional standardizers who need rules and models to replace
thinking. Signs of organizing the IESG around the YANG work
scare me in that regard. Again, nothing wrong with the work
itself and I admire some of the bits I've read. But, when a
modeling language starts becoming an area-like focus, I think we
need to ask deep questions about where we are headed.
best,
john