Re: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-05.txt

Barry Leiba <> Fri, 01 October 2021 19:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 427C33A077E for <>; Fri, 1 Oct 2021 12:31:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4Q_970NvCJJA for <>; Fri, 1 Oct 2021 12:31:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D32F53A0776 for <>; Fri, 1 Oct 2021 12:31:23 -0700 (PDT)
Received: by with SMTP id k32so7437770uae.2 for <>; Fri, 01 Oct 2021 12:31:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AjPpknChBEyfGMIMSxWD3JrbIR1Yc09njpNdb83D4EA=; b=CXdFm/84Wdtf3rK3c5GQ35NGfaOZ8aHN9gwTz+BbJCpwiQNrAsE/g/mZ87nPnR6e2E srnETHfECn0GVAPBbH0jYNGoVGXZAkGKvYTbEckNBV1siG2sI2fBHd1gRJq3K5d1bMn3 iyShsK9Qa1OYY6sMrRkohJhTNiVM9Q721m4i6zuCK1KFke7KaptmMPv1f4aXRhQO8gxM Nfji8OKmHkBEkYACPoCWq9PTy5NzyMWgax5QYmULHyLnVKzkNTFNM8oFhMx9n3ITt1qg wdL3+ObJQVWVuntHvKUOZmzKYL1xV2cj88y+kUiN8LMt1ABj2+X95ik9YQCczO2a6aRJ P5/w==
X-Gm-Message-State: AOAM5327v92OgT36DfugW71egu3zdHyJz1EzlLpGadpi5ZLj2RvmJlRg XU+tY3y4nvG6NYNodjK7qYY05812jMJ60WAnehW2CLMw
X-Google-Smtp-Source: ABdhPJwPiEZ9vf217r7wWqs22KnACWalJdXOfitts2dTQt80iUYJ1RuYGZz5Z/3SNvOW8Lel2fNhmvlvOR/fNvkPRV4=
X-Received: by 2002:ab0:7382:: with SMTP id l2mr3393711uap.94.1633116682752; Fri, 01 Oct 2021 12:31:22 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Barry Leiba <>
Date: Fri, 1 Oct 2021 15:31:11 -0400
Message-ID: <>
To: Keith Moore <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Gendispatch] New Version Notification - draft-eggert-bcp45bis-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Area Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Oct 2021 19:31:28 -0000

As the one who proposed moving to the normal appeals process, let me
support that proposal:

1. If one has a problem with what someone does, one should start
there.  In this case, ask the SAAs (politely and without assuming
they're being evil) to reconsider, and give reasons.

2. One should then move up the chain.  In this case, the next step is
to ask the one who appointed them -- the IETF Chair -- to review the
situation and weigh in.  Given that the IETF Chair appoints the SAAs
and then steps back and lets them do their jobs, it's reasonable that
the IETF Chair has not even been following the specific situation.
S/he should be given a chance to resolve it.

3. Continue moving up.  The next "up" is the IESG, and then the IAB
after that.  They're all available, and it makes sense to invoke them
in turn, just as for any other decision in the IETF.  This does not
allow the IESG to suppress anything, because an appeal can still
always go to the IAB.

4. The original plan, where the IAB is the only entity to appeal to,
gives no mechanism for reasonable review and resolution by the chair
or relevant ADs.  As I said at the time, a multi-level appeal process
is always better than having only one step available.

Keith, please tell us why you think the IETF Chair and the IESG should
not have a chance to review -- and perhaps support -- an appeal before
it goes to the IAB.  Given that it *can* still go to the IAB, how does
letting the IESG try to resolve it first allow them to suppress input
that it doesn't like?


On Fri, Oct 1, 2021 at 3:20 PM Keith Moore <> wrote:
> I definitely do not think that either the IETF Chair or the IESG should
> be in the appeals process for SAA actions.   This lets the IESG
> effectively suppress input that it does not like, for arbitrary reasons,
> and makes any notions of IETF Consensus extremely dubious.
> Please consider this objection added to my other several objections to
> this proposal.
> Keith
> On 10/1/21 2:39 AM, wrote:
> > A new version (-05) has been submitted for draft-eggert-bcp45bis:
> >
> >
> >
> >
> > The IETF datatracker page for this Internet-Draft is:
> >
> >
> > Diff from previous version:
> >
> >
> > IETF Secretariat.
> >
> >
> --
> Gendispatch mailing list