Hello Joel,
Indeed, if a serious violation of an architectural principal survives
past working group Last Call, it is the IESG's responsibility to
get the working group to fix the problem.
But their prior responsibility was to make it well known to the
working group that an architectural violation was in progress,
and I am suggesting that the IAB must take some responsibility
for clearly formulating the principles so that the working groups
can avoid the violations.
I am not saying this is a black and white issue.
Regards,
Charlie P.
"Joel M. Halpern" wrote:
I must disagree.
If a working group is chartered, starts down a path, and then later the
IESG or IAB determine that the working group has overlooked a serious
architectural problem, then the IAB or IESG needs to raise the issue when
they find it. Declaring that "it is too late" in response to a real
problem seem to be the wrong response.
Yours,
Joel M. Halpern
At 07:19 AM 11/21/2002 -0800, Charlie Perkins wrote:
Hello folks,
I realzed that my proposal probably wasn't clearly enough stated,
so here goes again.
It is my belief that the IESG has formulated some architectural
principles and applied them at inappropriate times in the process
of standardizing a working group protocol specification. Right now,
there is nothing preventing such a thing from happening even after
working group Last Call, and nothing that assures that one AD's
architecture principal is shared by the rest of the IESG or the IAB.
This leads to what could be perceived as arbitrary restriction based
on somebody's pet peeve -- whether or not the perception is true.
I think that such architectural principles (e.g., suitability of
vendor-specific extensions, but there are a number of others)
should be formulated by the IAB.
I think the IESG should try to understand early in the process
whether a working group is violating an architectural principle, and
when some candidate proposal seems to be in violation, that the
IESG should get the IAB's opinion in writing. That opinion should
be subjected to normal IETF process and published as a standards
track document which can be cited as a normative reference.
Again, as I stated last night, nothing is black and white, and I do
not claim that we need IAB statements on every aspect of protocol
design. But there have been some major upsets lately, and that is
even less appropriate. There has to be a happier medium.
Regards,
Charlie P.