Subject: Comments on draft-iab-rfc-editor: IETF control

From: Sam Hartman <[email-masked]>
Date: Thu, 25 May 2006 16:30:12 -0400

I finished reading the RFC editor document and have one major concern.

Ultimately, the rfc-editor function needs to be accountable to the
IETF community because we're the ones paying for it.

In particular I believe that the IETF should be able to pass a BCP
placing requirements on an rfc-editor stream.  We've done this with
RFC 3932 for example, and I think that was a good thing.

In effect, community consensus within the IETF should trump anything
else.

Now, we need to be careful about how to use that consensus.  Several
RFC streams serve communities broader than the IETF.  Unless we have
good reason to do so, we should not step on those communities by
overriding their requirements.

I also have specific concerns about how this document interacts with
the IAOC and IASA.

1) The document gives the IAB the authority to terminate the
    rfc-editor contract.  Depending on when we do that, there may be
    significant budget impacts and it may not be consistent with
    ISOC's carrying out its financial responsibilities to terminate
    the rfc-editor contract at an arbitrary point in time.

2) The document allows the IAB to create new streams of rfcs on its
   own authority.  It seems that we need ISOC and IAOC approval at
   least on the budget question to do so.

--Sam

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 25 May 2006 20:16:05 -0400

Sam,

Some high-level responses, and I'm sure we'll hear other
input:

1/ I think you're overlooking something in "IETF pays for RFC
Editor"; RFC Editor has been paid by ISOC for years, and *that*
largely comes out of contributions from corporations.  We actually
have no data beyond the fact that they support the RFC Editor
as currently constituted (i.e., including independent submissions).

We've already heard (in IETF discussion in March) input that
no in fact the IETF does not get to define the *in*dependent
submission process; one purpose of the planned discussion is
to ensure that the process is not at odds with the IETF's
standards needs, but that is very different than having the
IETF define it, as you describe.

2/ Termination of any contract is always going to be based on
terms in said contract.  I assume ISOC BoT wouldn't approve
something that leaves them with dangerous exposure; that's
what they do.

This document is aiming to capture the principle of the
IAB's responsibility; the counter example is not
right, either (the IASA giving the IAB/IETF the news that
there is a new RFC Editor in town).

3/ Re. approval of ISOC BoT/IASA for creation of new streams:  we
need to be careful with terminology.  The IASA exists to implement
adminstrative support to meet the needs of the IETF & IAB & IRTFs
needs.

Leslie.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 25 May 2006 20:30:40 -0400

>>>>> "Leslie" == Leslie Daigle <[email-masked]> writes:

    Leslie> Sam,

    Leslie> Some high-level responses, and I'm sure we'll hear other
    Leslie> input:

    Leslie> 1/ I think you're overlooking something in "IETF pays for
    Leslie> RFC Editor"; RFC Editor has been paid by ISOC for years,
    Leslie> and *that* largely comes out of contributions from
    Leslie> corporations.  We actually have no data beyond the fact
    Leslie> that they support the RFC Editor as currently constituted
    Leslie> (i.e., including independent submissions).

    Leslie> We've already heard (in IETF discussion in March) input
    Leslie> that no in fact the IETF does not get to define the
    Leslie> *in*dependent submission process; one purpose of the
    Leslie> planned discussion is to ensure that the process is not at
    Leslie> odds with the IETF's standards needs, but that is very
    Leslie> different than having the IETF define it, as you describe.

OK. I was not paying that much attention in March,and if I'm too late,
I certainly have no problem with the community choosing to allow a
broader group to control the independent submission track, or to seed
that to the IAB.

I think though that the community ultimately needs to have the power
to take back anything it has given.  Basically, I think it is critical
that ultimately everything within the greater IETF context be
accountable to the IETF community.  That is true of the IESG, the IAB
and everything they do.

I don't think this document represents that.

--Sam

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 25 May 2006 20:38:14 -0400

Howdy,

 > I don't think this document represents that.

It is, at its heart, an -00 :-)  Let's work on trying to fix the
text before assuming the whole structure is wrong.

Let's set aside *which* community for a moment (IETF community
or something larger) and work on making sure the document
is clear where the IAB makes decisions versus where it facilitates
the detection of and action upon consensus. Can you propose
some text improvements?

Leslie.

---

From: Pete Resnick <[email-masked]>
Date: Fri, 26 May 2006 09:37:46 -0700

>IETF community because we're the ones paying for it.

Sam, I'm sorry, but this is completely unadulterated NONSENSE. Who is 
this "we" to whom you are referring that is "paying for it"? The IETF 
folks who happen to go to face-to-face meetings (which isn't nearly 
everyone in the "IETF community", let alone everyone who gets to 
publish RFCs) pay enough to cover meeting costs and a part of the 
secretariat. So the money you are talking about is really ISOC money, 
and you had better not be claiming that the RFC Editor is accountable 
to ISOC's corporate sponsors.

I also notice how you quickly slip from "IETF Community" (which some 
people mean to encompass the IAB, IRTF, and assorted other folks who 
might have reason to publish RFCs) straight to "IETF":

>In effect, community consensus within the IETF should trump anything else.

Absolutely not. I strenuously object to any such attempt.

RFC 3932 was the IESG telling the RFC Editor that it was no longer 
going to do technical review of non-IETF documents (something that it 
should never have been doing in the first place) and the RFC Editor 
and IESG officially agreeing that the IESG could put a statement of 
conflict on those documents. Had the IESG tried to, for instance, say 
that it could stop certain RFCs from being published, the ensuing 
constitutional crisis would have been less than amusing.

The IESG (in the name of the IETF) does *not* get to control the 
publication practices of the IAB, or the IRTF, or any other person or 
group that happens to publish through the RFC Editor. And they 
bloody-well don't get to control the RFC Editor. If you want to push 
for changes to RFC 2850 which change how that works, you go right 
ahead. You won't get my support.

>    least on the budget question to do so.

The number of IETF working groups affects the budget too. But 
creation of working groups (even 50 new ones) does not require ISOC 
or IAOC approval. Should a point come when a decision of the IESG 
significantly impacts the budget, ISOC and the IAOC will surely let 
the IESG know that through its liaisons and decisions can be made at 
that time how to best accommodate the situation. There is no need for 
any formal requirement of approval, and in fact I would claim that 
such a requirement runs counter to the whole idea of the 
administrative restructuring: There is a separate entity (IASA) with 
a separate oversight committee (IAOC) such that there is no undue 
influence into internal processes by those who hold the purse strings.

I see no need for a formal requirement of *approval* in this case either.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Pete Resnick <[email-masked]>
Date: Fri, 26 May 2006 09:37:46 -0700

pr

---

From: Sam Hartman <[email-masked]>
Date: Fri, 26 May 2006 13:12:34 -0400

>>>>> "Pete" == Pete Resnick <[email-masked]> writes:

    Pete> On 5/25/06 at 4:30 PM -0400, Sam Hartman wrote:
    >> Ultimately, the rfc-editor function needs to be accountable to
    >> the IETF community because we're the ones paying for it.

    Pete> Sam, I'm sorry, but this is completely unadulterated
    Pete> NONSENSE. Who is this "we" to whom you are referring that is
    Pete> "paying for it"? The IETF folks who happen to go to
    Pete> face-to-face meetings (which isn't nearly everyone in the
    Pete> "IETF community", let alone everyone who gets to publish
    Pete> RFCs) pay enough to cover meeting costs and a part of the
    Pete> secretariat. So the money you are talking about is really
    Pete> ISOC money, and you had better not be claiming that the RFC
    Pete> Editor is accountable to ISOC's corporate sponsors.

We, here, is the set of people collectively who recently decided that
we wanted greater budget accountability and went to a lot of trouble
to form IASA and to start documenting a bunch of informal
arrangements.  As part of that I at least expected to have greater
accountability to the community.  I don't care what community.  I
don't see a difference between IETF, IETF community, Internet
community and rfc-interest community.
I understand some people do.

I do see a huge difference between the IAB and all of the above.  (I
see a huge difference between IESG and all of the above too, if anyone
cares.)

It's fine in my mind if the IAB judges consensus of the community
whatever community that is.

However there needs to be a way for a member of this
community--whatever it is--to make a proposal, to get enough support,
and to have that proposal be adopted.

I.E. it is fine if the IAB of whomever can do a lot of things on their
own.  However the community needs the ability to either guide the IAB
or override the IAB if there is disagreement.

There needs to be a formal process because that's how we get
accountabilitiy.  That process needs to be open and fair.  Open and
fair processes have some dispute resolution/appeal mechanism.

I do not relish the prospect of inventing all that all over again just
for the rfc-editor.  I'd much rather use the heaviest weight process
(publishing a BCP) we have available to us as an override.  I'm happy
if the last call for such a BCP needs to have input from a broader
community.  I'm happy if the IAB rather than the IESG judges consensus
provided there is an appeals process that involves more than just the
IAB.

--Sam

---

From: Geoff Huston <[email-masked]>
Date: Sat, 27 May 2006 08:31:05 +1000

>>Ultimately, the rfc-editor function needs to be accountable to the IETF 
>>community because we're the ones paying for it.

when you assert that

     "Ultimately, the rfc-editor function needs to be accountable to the 
IETF community"

it makes sense to me - this is, after all, a record of the 'outcomes' of 
the IETF process. I suspect, however, that the accountability set is a 
little broader than just the IETF folk and assumes different 
characteristics for different players, but accountability to the IETF has 
always been part and parcel of the RFC Editor role.

"because we're the ones paying for it"

Historically this has not been the case if "we" = IETF meeting attendees 
+  IETF mailing list members.

Delving down a bit here, I suspect that, as always, the longstanding issue 
here is the actual level of 'independence" of the RFC Editor, and the 
potential for a player to perform an end run around the IETF Internet 
Standards Process and have an RFC published that was in some form of 
fashion previously rejected or contradicted by some part of the IETF. In 
practice I'm hard pressed to bring forward any concrete example of this 
potential, and I know that the folk at ISI who have performed this role 
take their independence very seriously and exercise their responsibility 
very carefully.

However attempting to codify this role is problematical - I don't see it as 
being helpful if we state categorically that IETF Consensus "should trump 
anything else", but nor do I see it as being helpful if we say "well the 
role is independent of the IETF- so we'll provide no input"

It seems to me that if you want a simple copy editor and publication 
function then you may have to trim down the role of the RFC Editor to 
simple direct functions performed under the direction of the Secretariat of 
the IETF - but bear in mind that this is NOT the entirety of the RFC Editor 
role that has been performed up until now. If you want a RFC Editor that 
has a role that continues to function much as the RFC Editor has been doing 
in the past then you need to vest a significant amount of discretion into 
the RFC Editor role and expect that at times it will lead to spirited 
debate from time to time in the future.

regards,

   Geoff

---

From: "Robert Sayre" <[email-masked]>
Date: Fri, 26 May 2006 18:56:22 -0400

On 5/26/06, Geoff Huston <[email-masked]> wrote:
> Standards Process

The problem with such documents is that their final designation does
not indicate the degree of consensus they enjoy.

I suggest replacing the Experimental and Informational designations
with "Non-Standard",  and requiring that any non-WG product (including
submissions to AD) start at this level. That approach shouldn't bother
anyone truly interested in establishing a stable reference, but it
would require the IETF to lessen WG rampup effort.

-- 

Robert Sayre

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 30 May 2006 14:14:35 +0100

> would require the IETF to lessen WG rampup effort.

There IS certainly a case for some better way of differentiating between
the various types of RFC so that there is no misrepresentation to, or
misinterpretation by, the end user.

Perhaps we should add an indicator in the numbering scheme to call
this out, something like; RFC==consensus/std, iRFC==informational, 
xRFC==independant, vRFC==vendor-spec etc etc.

- Stewart

---

From: Eliot Lear <[email-masked]>
Date: Tue, 30 May 2006 17:35:39 +0200

Sam,

> or override the IAB if there is disagreement.

I disagree.  Just as I expect you to use your judgment on the IESG I
expect the IAB to use their judgment.  Community oversight comes in the
form of the NOMCOM.  If you believe that oversight is not effective,
then let's discuss that instead.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 May 2006 18:00:38 +0200

Look at draft-ietf-newtrk-docid-00.txt

This isn't really a chartering issue, IMHO.

     Brian

---

From: Michael StJohns <[email-masked]>
Date: Tue, 30 May 2006 12:42:58 -0400

I'm in complete agreement with Eliot (but that may be off point for 
the general topic).  In recent years the IETF has been struck by a 
particularly virulent form of back seat driver syndrome which has not 
only caused the community to believe they should second guess all 
possible decisions, but unfortunately seems to have had that effect 
on both the IAB and IESG as well.

Note that I'm not against the IAB and/or IESG soliciting comments on 
general goals, specific issues or even whether to serve cookies at 
the break, but they got selected to deal with the bulk of the day to 
day issues and we should just let them.

On the specific topic of the RFC editor though, and the amount of 
independence of that function, this is a battle that has been fought 
repeatedly.  This particular document has a number of incorrect 
assumptions - particularly the one that the RFC series belongs to the IETF.

In the doc "
    It is the responsibility of the IAB to approve the appointment of an
    organization to act as RFC Editor and the general policy followed by
    the RFC Editor."

This is incorrect.  It should read:  "It is the responsibility of the 
IAB to approve the appointment of an organization to act as a channel 
for the publication of Internet From [email-masked] Tue May 30 12:47:18 2006
Date: Tue, 30 May 2006 12:42:58 -0400
To: Eliot Lear <[email-masked]>,Sam Hartman <[email-masked]>
From: Michael StJohns <[email-masked]>
Cc: Pete Resnick <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Comments on draft-iab-rfc-editor: IETF control
I'm in complete agreement with Eliot (but that may be off point for 
the general topic).  In recent years the IETF has been struck by a 
particularly virulent form of back seat driver syndrome which has not 
only caused the community to believe they should second guess all 
possible decisions, but unfortunately seems to have had that effect 
on both the IAB and IESG as well.

Note that I'm not against the IAB and/or IESG soliciting comments on 
general goals, specific issues or even whether to serve cookies at 
the break, but they got selected to deal with the bulk of the day to 
day issues and we should just let them.

On the specific topic of the RFC editor though, and the amount of 
independence of that function, this is a battle that has been fought 
repeatedly.  This particular document has a number of incorrect 
assumptions - particularly the one that the RFC series belongs to the IETF.

In the doc "
    It is the responsibility of the IAB to approve the appointment of an
    organization to act as RFC Editor and the general policy followed by
    the RFC Editor."

This is incorrect.  It should read:  "It is the responsibility of the 
IAB to approve the appointment of an organization to act as a channel 
for the publication of Internet Standards and prescribe the manner in 
which such standards are approved."

E.g. the IAB can choose who publishes the ISs, but that doesn't 
necessarily give the IAB control over everything that organization publishes.

The RFC series just happens to be the current (and historical) 
channel for getting internet standards published.  If the IAB decided 
to go another direction (e.g. new organization for hire) it's unclear 
the RFC name would follow the internet standards to the new organization.

The document should be re-written to take the above into account.

The RFC series is and always has been wider than just what the IETF 
(IAB, IESG, IRTF etc) has in mind.  It's independence from those 
bodies has been key to avoid some pretty large misteps in the past 
and has been key to getting the broader community involved.  It's 
hubris (and somewhat of a landgrab) to declare after all this time that "
Consistent with the rest of the streams, there needs to be a
    community consensus document to define that [independent 
submission] process.  The IAB will
    establish a community forum for defining a community consensus based
    document to define the approval process for this stream.  The IAB
    will be responsible for gauging consensus on that document, as well
    as providing the forum for any needed future revisions of the
    document."

I believe the RFC editor continues to be well equipped to handle 
independent submissions and to set their own process consistent with 
the best interests of the community.

E.g. the IAB should keep its hands off the independent submission 
process at least with this "channel"

Mike

---

From: Geoff Huston <[email-masked]>
Date: Wed, 31 May 2006 05:02:13 +1000

"This isn't really a chartering issue, IMHO."

I must strongly disagree here Brian - irrespective of any details of 
implementation, the level of independence and discretion granted to the RFC 
Editor to edit and publish documents that are not the outcome of the IETF's 
peer review process is, I believe, a central matter in any version of an 
RFC Editor Charter.

regards,

      Geoff

---

From: John C Klensin <[email-masked]>
Date: Tue, 30 May 2006 19:12:30 -0400

--On Wednesday, 31 May, 2006 05:02 +1000 Geoff Huston
<[email-masked]> wrote:

> I must strongly disagree here Brian - irrespective of any
> details of implementation, the level of independence and
> discretion granted to the RFC Editor to edit and publish
> documents that are not the outcome of the IETF's peer review
> process is, I believe, a central matter in any version of an
> RFC Editor Charter.

While I agree with Geoff, this then makes the question of how
that charter should be reviewed and approved a critical issue.  

I'm comfortable having the IAB do that, as long as it is done in
collaboration with the current RFC Editor staff rather than as
an independent decision made in an adversarial climate (I don't
read a requirement for, or an assumption of, an adversarial
climate into the draft or Leslie's note) and as long as the IAB
understands that it is responsible to a community that extends
well beyond the IETF and that may have an affirmative interest
in views that dissent from IETF (or IESG) decisions and
positions.

For those who believe that "the IETF" --presumably as
represented by the IESG-- should have controlling authority over
what the RFC Editor does across the board, I'd recommend a
thought experiment:  As I understand it, none of the support for
the RFC Editor in recent years (or ever) has come from IETF
meeting fees.  The support comes from ISOC and the largest
fraction of that ISOC support is earmarked corporate
contributions.   Now, with the understanding that I'm neither
predicting nor advocating this course of action, suppose those
companies were convinced that an independent RFC Editor
--independent of IETF control -- was important and that they
would prefer to fund that and let the IETF take care of itself
(or, more likely, that they would fund the two separately but
control the ratios).   It seems to me that would leave us in
exactly the position others have suggested: the IAB could
designate the "technical publisher" for IETF documents, but that
might be an entity completely separate from the RFC Editor and
the "RFC" name and series might stay with the entity designated
by ISOC or the relevant sponsors.

Now, it seems to me that it is in everyone's interest to avoid
getting anywhere near a state in which a scenario like that
started being seriously discussed.   Doing so implies, I think,
a minimum of hubris, a minimum of assertions about IETF
authority over non-IETF documents, and a maximum of IAB working
together with the RFC Editor to find a right way forward, rather
than assuming that one body can dictate to the other.

That line of reasoning, and the consequences of the thought
experiment, leads to another conclusion which I would not have
guessed at a few weeks ago: the IAOC has limited or no authority
to compete an "RFC Editor contract" to cover tasks other than
those directly related to the IETF except on the advice and
consent of the ISOC BoT or some other ISOC entity (in either
case with the ISOC entity acting as representative of the
relevant organizational members).  I believe that a
well-designed RFI process is, at worst, harmless and might
produce information that would be beneficial to all parties.
But the assumption that the IAOC can then award a contract that
covers non-IETF publications may not be reasonable.

What a strange world our reasoning and desires for more control
get us into.
 
        john

---

From: "Margaret Wasserman" <[email-masked]>
Date: Wed, 31 May 2006 12:24:37 -0400

Hi Eliot,

> I disagree.  Just as I expect you to use your judgment on the 
> IESG I expect the IAB to use their judgment.  Community 
> oversight comes in the form of the NOMCOM.  If you believe 
> that oversight is not effective, then let's discuss that instead.

If an AD or the IESG makes a mistake, there is also an appeals mechanism
available.  There isn't any documented appeals mechanism for IAB decisions.
Should there be?

Margaret

---

From: Fred Baker <[email-masked]>
Date: Wed, 31 May 2006 10:45:45 -0700

On May 31, 2006, at 9:24 AM, Margaret Wasserman wrote:
> If an AD or the IESG makes a mistake, there is also an appeals  
> mechanism available.  There isn't any documented appeals mechanism  
> for IAB decisions. Should there be?

Actually, there is. See section 6.5.3 of RFC 2026. As with an appeal  
to the IAB, the question changes somewhat when it is invoked (an  
appeal to the IESG claims a bad decision by a WG chair or an AD,  
while an appeal to the IAB claims a process failure), and in point of  
fact it has never been invoked. An appeal in each case reviews the  
actions of a lower level, and if upheld, tells the lower level to fix  
its process and then review its decision according to the revised  
process; an appeal of the IAB's decision is questioning the process  
documents that govern the IETF, and if upheld, directs that they be  
revised according to an appropriate process.

------------------------------------------------------------------------ 
-----
RFC 2026               Internet Standards Process           October 1996

    The IAB decision is final with respect to the question of whether or
    not the Internet standards procedures have been followed and with
    respect to all questions of technical merit.

6.5.2 Process Failures

    This document sets forward procedures required to be followed to
    ensure openness and fairness of the Internet Standards Process, and
    the technical viability of the standards created. The IESG is the
    principal agent of the IETF for this purpose, and it is the IESG  
that
    is charged with ensuring that the required procedures have been
    followed, and that any necessary prerequisites to a standards action
    have been met.

    If an individual should disagree with an action taken by the IESG in
    this process, that person should first discuss the issue with the
    ISEG Chair. If the IESG Chair is unable to satisfy the complainant
    then the IESG as a whole should re-examine the action taken, along
    with input from the complainant, and determine whether any further
    action is needed.  The IESG shall issue a report on its review of  
the
    complaint to the IETF.

    Should the complainant not be satisfied with the outcome of the IESG
    review, an appeal may be lodged to the IAB. The IAB shall then  
review
    the situation and attempt to resolve it in a manner of its own
    choosing and report to the IETF on the outcome of its review.

    If circumstances warrant, the IAB may direct that an IESG  
decision be
    annulled, and the situation shall then be as it was before the IESG
    decision was taken. The IAB may also recommend an action to the  
IESG,
    or make such other recommendations as it deems fit. The IAB may not,
    however, pre-empt the role of the IESG by issuing a decision which
    only the IESG is empowered to make.

    The IAB decision is final with respect to the question of whether or
    not the Internet standards procedures have been followed.

6.5.3 Questions of Applicable Procedure

    Further recourse is available only in cases in which the procedures
    themselves (i.e., the procedures described in this document) are
    claimed to be inadequate or insufficient to the protection of the
    rights of all parties in a fair and open Internet Standards Process.
    Claims on this basis may be made to the Internet Society Board of
    Trustees.  The President of the Internet Society shall acknowledge
    such an appeal within two weeks, and shall at the time of
    acknowledgment advise the petitioner of the expected duration of the
    Trustees' review of the appeal.  The Trustees shall review the

Bradner                  Best Current Practice                 [Page 23]
^L
RFC 2026               Internet Standards Process           October 1996

    situation in a manner of its own choosing and report to the IETF on
    the outcome of its review.

    The Trustees' decision upon completion of their review shall be  
final
    with respect to all aspects of the dispute.

---

From: "Bill Fenner" <[email-masked]>
Date: Wed, 31 May 2006 15:56:28 -0400

On 5/31/06, Fred Baker <[email-masked]> wrote:
> > There isn't any documented appeals mechanism
> Actually, there is. See section 6.5.3 of RFC 2026.

Fred,

  Do you read that as being able to say "the IAB made a mistake in
their (RFC Editor selection|liaison management|other IAB-assigned
task)"?  I read it as being able to say "the IAB upheld my appeal to
the IESG because RFC 2026 supports them, but RFC 2026 is wrong" and
nothing more.

  Bill

---

From: Fred Baker <[email-masked]>
Date: Wed, 31 May 2006 13:33:53 -0700

On May 31, 2006, at 12:56 PM, Bill Fenner wrote:
> task)"?  I read it as being able to say "the IAB upheld my appeal  
> to the IESG because RFC 2026 supports them, but RFC 2026 is wrong"  
> and nothing more.

Well, since RFC 2026 assigns the tasks (or perhaps more properly,  
notes that the tasks have been so assigned), if the community thought  
the IAB did something wrong in their tasks, they would appeal on that  
basis to the ISOC Board. You are correct that the set of responses  
that the ISOC Board is empowered to give is not particularly broad -  
the board would basically be forced to say that RFC 2026 assigned the  
task to the wrong group, and direct the IETF to conduct an  
appropriate process to figure out who should have been given the job.  
In context, that translates roughly as "you guys go talk about it and  
come up with a more appropriate solution".

The interesting question is not who the IAB appeals go to, though. It  
is to whom the IAOC appeals go. After all, if it is the IAD that  
signs contracts such as the RFC Editor's contract, he is overseen by  
the IAOC, and the IAOC is very carefully structured as *not*  
reporting to the ISOC Board.