Re: [arch-d] Call for Comment: <draft-iab-rfc3677bis> (IETF ISOC Board of Trustee Appointment Procedures)

Barry Leiba <> Wed, 24 February 2016 22:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3D2F11A0389; Wed, 24 Feb 2016 14:37:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q1ndEJqz03Eb; Wed, 24 Feb 2016 14:37:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 408D91A0382; Wed, 24 Feb 2016 14:37:48 -0800 (PST)
Received: by with SMTP id y8so1393570igp.1; Wed, 24 Feb 2016 14:37:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=Jf0M7N9C02X/akpSu6THhJrSZXlEthiBu/zET0Z/9eM=; b=WINFrhuuZHSo9oDHs5IZzNJAdHWJSc15hH6+54an3AK3a7xVrk2R9I5f9NAr9C7UQC uX8u9ReBvNNDV7w4tkBHxIQgeyolN/w0amazpLKnWYkFD4MfnN9fc5nUO7MPIY5esKj6 CJheYgjLVY0qkHjQsR6RWD8JW7DZOOoa9jrEcs2DlRKlx8sGRDYcLd1MXQk7VAfXqtRh dflTimVfoy1soqvQYKlvx1RjcmMq4mK6weAv/MP+a9RsYSgOHhJRHnEDnnepnX7x9pWw vLJ32q50ZqqDbLXfDNcS4Mf7g6Hbee2A+/Salwb3a8/jKPpEg6WUJFNMqCQcXki4BqvA Hedg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Jf0M7N9C02X/akpSu6THhJrSZXlEthiBu/zET0Z/9eM=; b=W+G4hQl6ayz/IsdXl19fEm++cvdyJSCIbvNQjaduEl89tHlfLdBbhmyIfdVsg8idmb iJu+2z5T2IvUiCjq5niQmyoqm++hufVbiXmn+1guTrA7Y1Fp18rROVt+SRPfX/ozoGA+ cdr23OhaCxA55yfIf4fYhmv+fh3rzSX0Eu1abTfskJNXNG9F5ILwKLmeOnvzyCn4Asth jgDOy4TSkIfiLqM/r2lV6MYOo379MLR1fVBBtsJqXMlO2+oP0vlgLCKRWSXihi5YXn1V nyTeYMtPLFrPq8TmMrs9qFcOe2KRpqYqz1RG0hC5baoVhm2CsYV60BiU+ZuqQtRHmj41 HBBw==
X-Gm-Message-State: AG10YORHs+mEahGgUXLKQtOxxcbk1qt36F0XqF9ZGvd1iM2IjMIAgN9ZdCnSwObZBWfUV3kosn5g1MaXl6O9Ww==
MIME-Version: 1.0
X-Received: by with SMTP id ct6mr204887igb.54.1456353467662; Wed, 24 Feb 2016 14:37:47 -0800 (PST)
Received: by with HTTP; Wed, 24 Feb 2016 14:37:47 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 24 Feb 2016 14:37:47 -0800
X-Google-Sender-Auth: BASj-4_8EtVjKwsZch136xnUzfM
Message-ID: <>
Subject: Re: [arch-d] Call for Comment: <draft-iab-rfc3677bis> (IETF ISOC Board of Trustee Appointment Procedures)
From: Barry Leiba <>
To: "Joe Hildebrand (jhildebr)" <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: IAB <>, IETF discussion list <>, "" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Feb 2016 22:37:49 -0000

Barry said...
>>> While this is certainly expedient, it's quite open-ended, entirely
>>> left up to the judgment of the sitting IAB about what "reasonable
>>> modifications" might mean.  Certainly, with a by-law change that adds
>>> a board appointment, most anyone would consider it reasonable to just
>>> add that appointment with the appropriate periodicity, and it's
>>> reasonable not to have to rev this document for that.

Brian said...
>>Yes, but I think this needs to be circumscribed. Wouldn't it be better
>>to require that BCP 77 is appropriately updated within 12 months in
>>such a case, i.e. trust the IAB to do the right thing but also commit
>>to updating the rules accordingly?

Joe said...
> I guess I'm ok with that. We could also trust the IAB to know the
> difference between a substantive change and a minor one.

Actually, I'm fine with trusting the IAB here, as it's limited to
appointments that it is given the power to make; I just want to make
absolutely sure that the community knows what it's agreeing to.
That's why I'd rather simply shift this to an IAB statement now, and
make it clear that BCP 77 as a whole is now obsolete, and that the
process that BCP 77 formerly described is now described in the IAB

[To keep this in perspective, I'm not going to hold out on this point;
it's a suggestion -- one that I think makes it fully clear what's
being changed in how we document this process.]