My thoughts about the problems of the IETF
kempf at docomolabs-usa.com
Mon Apr 21 09:54:56 CEST 2003
The potential for the KRE decision to be interpreted as more wide
ranging than it was intended, which I interpret to be your concern,
was discussed and the wording of the decision was phrased to
explicitly rule out that possibility. The decision was intended to
just apply to the particular case at hand. I believe it is important
for people to understand that it was not intended to be an open-ended
invitation for anyone to file an appeal every time some point was
unclear to them in a draft approved by the IESG.
> I think we are into dangerous territory here. Following one
> line of your argument (and Pete's), and generalizing from what
> the IAB did decide in the Elz decision, perhaps we need an
> explicit criterion on all standards-track RFCs that are
> candidates for advancement that says "this document must be
> clear enough that it is precisely obvious to anyone skilled in
> the area what needs to be tested for interoperability". With
> such a rule in place, or a more general rule that IESG approval
> of _anything_ that is unclear in a substantive way, or that has
> swept important issues under the proverbial carpet, is subject
> to appeal, we get a better tool, but we also get at least a
> strong possibility for IAB technical review on anything that
> comes out of the IESG.
> Ending up in that state would be, I think, controversial. But
> it would also address the issue you raise in a useful way: if
> the IESG _and_ IAB determine that a document is clear on which
> features must be checked for interoperability, then whether or
> not a particular feature has been checked is a procedural
> matter, not a technical one (although, given documentation that
> it had been checked, whether it had been checked "well enough"
> and passed would remain a technical question.
> --On Thursday, 17 April, 2003 15:06 -0400 Margaret Wasserman
> <mrw at windriver.com> wrote:
> > I think that this is all an argument about how we use the
> > terms "technical" and "process".
> > In an appeal, I think that anything that concerns technical
> > issues is a technical appeal, and therefore can't be appealed
> > to ISOC.
> > Let's assume, for the moment, that the IAB had come back with
> > a finding in the Elz appeal that said "Ah ha! The IPv6 group
> > didn't check for two interoperable implementations of <foo>."
> > This would still, IMO, be a technical finding on a technical
> > appeal... If we appealed that decision to ISOC, I hope they
> > would refuse to consider it, as they have no more place in
> > deciding what constitutes a feature of IPv6 that needs to be
> > tested for interoperability than they do in deciding if an
> > IPv6 document is technically correct or sufficiently clear.
> > Margaret
> > At 01:53 PM 4/17/2003 -0500, Pete Resnick wrote:
> >> On 4/17/03 at 2:21 PM -0400, Margaret Wasserman wrote:
> >>> But, the Elz appeal was a technical issue involving document
> >>> clarity.
> >> Actually, I believe (and Robert can correct me if I'm wrong
> >> if he's listening) that the Elz appeal *was* about a process
> >> violation (not checking for two implementations), but the
> >> IAB decided that the document was not clear enough to
> >> determine what the protocol required. They sidestepped the
> >> issue of whether there actually was a process violation.
> >> pr
> >> --
> >> Pete Resnick <mailto:presnick at qualcomm.com>
> >> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax:
> >> (858)651-1102
More information about the Problem-statement