On Dec 26, 2014, at 5:23 PM, John C Klensin <john-ietf@xxxxxxx> wrote: > 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. I find your arguments unconvincing as they relate to the reorg that's being discussed, because there are _always_ blind spots. Expecting Area Directors to be omniscient doesn't scale--there just aren't enough of us that are. That said, I think that your observation here is correct, and ought to be addressed. I just don't agree that it leads to the conclusion you drew. What you are describing here is the classic cross-area review problem. If ADs workloads allowed for it, perhaps we would do a better job at this. I can certainly imagine a change in structure where each working group has a responsible AD, but also a second AD who tries to pay attention to what the working group is doing, from a different area. What I just said isn't the actual solution, because ADs don't currently have that much bandwidth, but perhaps there's a pony in there somewhere.