And, FWIW, when the AD suggests specific text changes, it's often enough the desire of that AD rather than based on feedback from some other WG.
I don't see anything wrong with that. It's the ADs' job to push back on documents with technical flaws. They're supposed to use their judgments as technical experts, not just be conduits of information supplied by others.
That's fine when that is what they do. What you're hearing here is that it is not uniformly so.
Yes, I understand that, and many of us can cite specific cases where the power was inappropriately used. But from a _process_ point-of-view, I don't see how to avoid the potential for misuse and still get the review that seems essential to keeping the quality level up. We try to arrange that there are alternatives to having good proposals killed or stalled by capricious ADs - like appeals, the process that IESG now has to bypass a single member's DISCUSS, the independent submission process via the RFC Editor, etc. And maybe we need more alternatives. But I don't see how to get rid of the review.
The issue here is that ADs are human, with all the flaws the rest of us have. Yes, they try pretty hard to make the documents that come out of working groups "right", and they have to work pretty hard to make that happen. They also have their hobby-horses, and make comments during IESG review that should have been made "AD hat off" on the mailing list.
yes, yes, and yes.
Keith
p.s. FWIW & IMnsHO, ULAs, while useful, are at best only a small part of a satisfactory solution for keeping addresses stable across renumbering, even for applications that entirely run on local networks. Even to explain why this is the case is not simple, but briefly: a) There are multiple reasons for a site to use ULAs (some more defensible than others) and it's not reasonable for an application to assume that a ULA is more appropriate for any particular purpose than any other prefix. Different applications will have different requirements for addressing (some need stable addresses, others need privacy, others need maximum efficiency/throughput or minimum delay, others need addresses that are reachable by all participating hosts) and these requirements can even change depending on the set of hosts participating in an application. A default set of address selection rules (as we are already seeing) will not work well. It appears possible to design a protocol that allows the network to tell hosts when ULA prefixes are equivalent to, but more stable than, other prefixes advertised on the network (and I wrote an I-D describing such a protocol), and it's possible to design an API extension which allows apps to say "please use stable addresses on this connection when available". This would allow ULA-aware apps to make use of ULAs when they are available and when the network operator believes ULAs are more stable than PA or other prefixes. But that requires a lot more than just the existence of ULAs to be workable, and even then, they only solve the stability problem for what is arguably a corner case.
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf