Hans,
I think this formulation is consistent with what I, and others,
have been trying to say. I would, however, add one element.
The IESG was asked to approve a code point for work developed
elsewhere. There is no question that they could have approved
it and approved it on the basis of the request, rather than
requiring or conducting an expert technical review (that is what
2780 quite clearly says). Perhaps they should have done so,
perhaps not.
However, especially since the IETF maintains liaisons with at
least a subset of the other standards bodies involved, when the
IESG decided that a technical review was necessary, they should
have managed things so that one was performed. Elements of such
a review might have included contacting the other organization
and making a review plan with them (including a document
distribution plan if appropriate), or discussions with the WGs
involved on the IETF side, or other work in the community,
presumably leading up to a Last Call or the equivalent.
Instead, the IESG chose to do its own review internally, without
consulting either the relevant WGs, or their Chairs, or the
broader community. And that, we agree, was the wrong thing to
do.
Fwis, draft-klensin-iana-reg-policy-00.txt is an attempt to give
the community a chance to clarify and establish the type of
policy it prefers be applied in this sort of matter.
john
--On Wednesday, 29 June, 2005 21:49 -0400 Hans Kruse
<kruse(_at_)ohiou(_dot_)edu> wrote:
Margaret,
my concerns (and those of others) are a bit different I think.
Again, I see what happened as:
1. A non-IETF standard is being developed.
2. The standard is being reviewed by another organization.
3. The group working on the standard requests a code point
from IANA
The "IESG review" is the only available process since no
technical review is requested within the IETF (both of the
other options would seem to imply such a review).
The IESG seems to have reacted by assuming that it had to
substitute its judgment for the technical review which is not
part of the request, and I think _that was wrong_.
If the IESG concluded that a technical review was needed, then
_IETF consensus_ would be appropriate. BUT, in this case my
read is that the IESG should _not_ have conducted a technical
review, but rather should have limited the review only on
whether a code point was available, and whether a hop-by-hop
option unknown to most devices would cause any foreseeable
problems.
That last point bothers me the most; if a standard is being
developed within the framework of another known standards
organization and on top of this (in this case) by a known set
of engineers, should the IETF not focus on interoperability
instead of second-guessing the outside work? I could see how
an unknown IPv6 option header could possibly become a problem
(although that would point to bad protocol design or
implementation, IMHO), so interoperability should be reviewed,
but otherwise I _cannot_ see how the _content_ of the option
could harm a device that does not want to deal with it.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf