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@xxxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf