Re: [Iasa20] Comments on draft-ietf-iasa2-rfc4844-bis-01

Eliot Lear <lear@cisco.com> Sun, 10 February 2019 12:34 UTC

Return-Path: <lear@cisco.com>
X-Original-To: iasa20@ietfa.amsl.com
Delivered-To: iasa20@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1B1129BBF; Sun, 10 Feb 2019 04:34:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnRflsRX0FHl; Sun, 10 Feb 2019 04:34:03 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DF2126F72; Sun, 10 Feb 2019 04:34:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5510; q=dns/txt; s=iport; t=1549802042; x=1551011642; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Ixkur78BGpvQHZ/q7HiuShEPhbELdWcqaxClNbqC3KQ=; b=WRejFg/94vMsEhAxAfUVDNv6kG9tzc8fn+jPV5nqUVRL0jt3eqmXA4lU TuaXvv6unHERR9zrsAXeCX/a0luaCJ8yfz8mMQWYrfo2nYe++QRUpXpgy u9mNI/ZDTnJw505k9PBHabHSOGZz2FQVo5jHYjX4EW09/+qar1va03wtN U=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAAyGWBc/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgzoBIBInhASIGl+NG4kqiHqFb4F7CAM?= =?us-ascii?q?BAYRsAoNNNAkNAQMBAQIBAQJtKIVKAQEBAwEjTwcFCwsEFCoCAiE2BhODJAG?= =?us-ascii?q?BaQMNCKh3gS+FRII0DYIPD4JtiW2Bf4ERJx+CTIJXhTMxgiYChyeJXZFoMwm?= =?us-ascii?q?ER4oQPoM7GYpQiBCRHIgOgmsCBAYFAhSBRjiBVjMaCBsVZQGCQT6BaheOHz4?= =?us-ascii?q?DMI0rAQE?=
X-IronPort-AV: E=Sophos;i="5.58,354,1544486400"; d="asc'?scan'208,217";a="9991686"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2019 12:34:00 +0000
Received: from [10.61.201.117] ([10.61.201.117]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x1ACXwt1017758 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Feb 2019 12:33:59 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <9BC29406-F067-4BBD-8E3C-BE533B8EF1F5@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_6BE9AB95-C13B-4D48-A36B-2C42D4BFFDCA"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Sun, 10 Feb 2019 13:33:58 +0100
In-Reply-To: <0C57D4C6-0F6D-47E9-81FC-3DE005FDDDFC@gmail.com>
Cc: Richard Barnes <rlb@ipv.sx>, draft-ietf-iasa2-rfc4844-bis@ietf.org, "Joel M. Halpern" <jmh@joelhalpern.com>, IASA 2 WG <iasa20@ietf.org>
To: Bob Hinden <bob.hinden@gmail.com>
References: <32C06675-C60B-4D6A-979A-FC3653E56D42@cooperw.in> <23C614C4-5C79-4355-9D74-2ED7D0DE63B2@vigilsec.com> <CAL02cgTzEQPTXyPL-ermABDne2G8F8UjbPpYADkyxxWHnVVf4g@mail.gmail.com> <a0a2ef94-335f-5ab6-e49c-7b1c985af3fc@cs.tcd.ie> <CAL02cgSnxB8-W_m13KM_HsSrE308vv5DuRJzt=t140G9JBdhUw@mail.gmail.com> <8873e4a0-a3d4-02b3-1c7b-28a9ea347165@joelhalpern.com> <CAL02cgQTzWtNVAWRZizFEekLDmapL7wOUMkJ0CWT_P_t3SDEtA@mail.gmail.com> <7436cbec-32a2-274d-7a22-b3db8388b10a@joelhalpern.com> <CAL02cgRGFXZY7+nPZx6eLoWjZ9o4RQ--aKs_seXbOfepiYBCpA@mail.gmail.com> <0C57D4C6-0F6D-47E9-81FC-3DE005FDDDFC@gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-Outbound-SMTP-Client: 10.61.201.117, [10.61.201.117]
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/bQ1KBw07_U_leECDlg1fxWhxpbw>
Subject: Re: [Iasa20] Comments on draft-ietf-iasa2-rfc4844-bis-01
X-BeenThere: iasa20@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= <iasa20.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iasa20>, <mailto:iasa20-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iasa20/>
List-Post: <mailto:iasa20@ietf.org>
List-Help: <mailto:iasa20-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iasa20>, <mailto:iasa20-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Feb 2019 12:34:05 -0000


> On 10 Feb 2019, at 06:21, Bob Hinden <bob.hinden@gmail.com> wrote:
> 
>> On Feb 9, 2019, at 6:22 PM, Richard Barnes <rlb@ipv.sx> wrote:
>> 
>> To the extent that the RSE is defined as "the person the IAB calls the RSE", then yes, you are undoubtedly correct.  The IAB has unquestionable authority to choose that person.
>> 
>> To the extent that the RSE is the party of the RSE contract who is contracted and paid to act as RFC Series Editor, then no, the IAB and RSOC do not have the authority to choose that person, as long as they are not the other party to that contract.
> 
> I don’t think that is the right way to describe it.   The process is: the IAB decides who it want’s to be the RSE, it then asks the [was IAOC | will be LLC] to negotiate a contract with that person and report the results of that negotiation back to the IAB.  If the LLC can’t negotiate a contract, then the IAB will need to pick someone else.  The IAB decides who it wants for the RSE, and the LLC implements that via a contract.


This is the desired process.  I think what Richard is pointing out is that the LLC is under no formal obligation to pay attention to the IAB.  And so like all good contractual relationships one has to ask what the recourse is for the LLC not following through.  The answer is quite simple: appoint different LLC directors the next time around.

That’s it.  There is no more.

And so what we can do in the RFC series is document what the IETF wants, so that LLC members at least know, and can take heed (or not, at their peril).

Eliot