From nobody Sun Apr 3 05:58:16 2016 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125AC12D1A3; Sun, 3 Apr 2016 05:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 HLvzgGTVUVpU; Sun, 3 Apr 2016 05:58:11 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C96F12D535; Sun, 3 Apr 2016 05:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6254; q=dns/txt; s=iport; t=1459688290; x=1460897890; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=V+ZZBkSJSLFdi3/jxLVzGEVarplcCLpMwcQtsRAaQGY=; b=OAUKop5S8k4QcUk8tEgOEfw2TeAtMe2Oer/K+UNiDgaR1cH/IZbvNQBy E/EJUL+4CLjH+6rnoGPuE5tHJtxpOeaOtK4Dh5AknYaw4Ix9bNK4TctOs Oaf6cTz3N+h7RdhmUMZzIlOGtAijUY2UDEyUuGsJGX2+d5qqR6yIu5rWb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgBkEgFX/4sNJK1dgzdTfQa7GwENg?= =?us-ascii?q?XIXCoUiSh6BBTgUAQEBAQEBAWUnhEMBBAEBASARMRQSARoIAggeAgQlCxUCEAQ?= =?us-ascii?q?BDQUUCIgLDqlYkQoBAQEBAQEBAQEBAQEBAQEBAQEBAQERBHyFJIF1glWHPyuCK?= =?us-ascii?q?wWNTYo0AYEqhEiCcoUjgWiETYhajxkBHgEBQoNnbIcMfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,436,1454976000"; d="scan'208";a="256017884" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Apr 2016 12:58:09 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u33Cw9xW006009 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 3 Apr 2016 12:58:09 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 3 Apr 2016 08:58:08 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Sun, 3 Apr 2016 08:58:08 -0400 From: "Joe Hildebrand (jhildebr)" To: "architecture-discuss@ietf.org" , "ietf@ietf.org" Thread-Topic: Remote participation in IAB workshops Thread-Index: AQHRjah4kcLD23/qI0CAnNsEkCbc7w== Date: Sun, 3 Apr 2016 12:58:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.8.48] Content-Type: text/plain; charset="utf-8" Content-ID: <6C69854DE6F0614CA8649B19A5C8A932@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IAB Subject: [arch-d] Remote participation in IAB workshops X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 12:58:13 -0000 VGhlIElBQiBoYXMgaGVhcmQgZnJvbSB0aGUgY29tbXVuaXR5IGEgZGVzaXJlIGZvciBtb3JlIG9w ZW5uZXNzIGluIG91ciB3b3Jrc2hvcHMsIGluY2x1ZGluZyByZW1vdGUgYWNjZXNzLiAgQWZ0ZXIg YSBnb29kIGFtb3VudCBvZiBkaXNjdXNzaW9uLCB3ZSBjb250aW51ZSB0byBiZWxpZXZlIHRoYXQg Zm9yIElBQiB3b3Jrc2hvcHMsIHRoZXJlIGFyZSBzb21ldGltZXMgZ29vZCByZWFzb25zIG5vdCB0 byBkZWZhdWx0IHRvIHRoZSBJRVRGJ3MgdXN1YWwgc3RhbmNlIG9mIGZ1bGwgcmVhbHRpbWUgcmVt b3RlIGFjY2VzcyBmb3IgYW55b25lIHRoYXQgd2FudHMgdG8gcGFydGljaXBhdGUuICBPdXIgcHJh Y3RpY2Ugd2lsbCBjb250aW51ZSB0byBiZSB0byBhbGxvdyB0aGUgUHJvZ3JhbSBDb21taXR0ZWUg KFBDKSBmb3IgYSBnaXZlbiB3b3Jrc2hvcCB0byBkZWNpZGUgaG93IGJlc3QgdG8gaW5jbHVkZSB0 aGUgY29tbXVuaXR5IGluIG9yZGVyIHRvIGFjY29tcGxpc2ggdGhlIHRlY2huaWNhbCBnb2FscyBv ZiBhIGdpdmVuIHdvcmtzaG9wLg0KDQpXZSBhcmUgdXBkYXRpbmcgb3VyIGludGVybmFsIGRvY3Vt ZW50YXRpb24gb24gaG93IHRvIHJ1biBhIHdvcmtzaG9wIHdpdGggdHJhZGVvZmZzIGZvciB0aGUg UEMgdG8gY29uc2lkZXIsIHBhcnRpY3VsYXJseSBhcm91bmQgaG93IG9wZW4gdG8gbWFrZSB0aGUg ZGlzY3Vzc2lvbi4gIEhlcmUgYXJlIHNvbWUgb2YgdGhvc2UgY29uc2lkZXJhdGlvbnMsIGZvciBj b21tdW5pdHkgY29tbWVudDoNCg0KS2VlcGluZyBpbiBtaW5kIHRoYXQgYW4gSUFCIHdvcmtzaG9w IGlzIG9mdGVuIGhlbGQgYXQgdGhlIHZlcnkgYmVnaW5uaW5nIG9mIG91ciBjb21tdW5pdHkncyBk aXNjdXNzaW9uIG9mIGEgZ2l2ZW4gdG9waWMsIGl0IGlzIHNvbWV0aW1lcyBpbXBvcnRhbnQgZm9y IHRoZSBkaXNjdXNzaW9uIHRvIGJlIGFzIHVuZW5jdW1iZXJlZCBhcyBwb3NzaWJsZSBieSBBdWRp by9WaXN1YWwgb3ZlcmhlYWQgKFN0YW5kIFRoZXJlISBTcGVhayBpbnRvIHRoZSBtaWMhIFNheSB5 b3VyIG5hbWUhKSBpbiBvcmRlciB0byBnZXQgdG8gdGhlIGhlYXJ0IG9mIGFuDQphcmNoaXRlY3R1 cmFsIGRpc2N1c3Npb24gaW4gdGhlIHNob3J0IHRpbWUgd2UgaGF2ZSBmb3IgdGhlIHdvcmtzaG9w LiAgQWxsb3dpbmcgZnVsbCByZW1vdGUgcGFydGljaXBhdGlvbiAoSmFiYmVyIHJlbGF5ISBNdXRl IHlvdXIgbGluZSEpIHdvdWxkIGNhdXNlIGV2ZW4gbW9yZSBpbXBhY3QgdG8gdGhlIGluLXJvb20g ZGlzY3Vzc2lvbiwgd2l0aCB0b2RheSdzIHR5cGljYWwgdGVjaG5vbG9neS4NCg0KRm9yIHNvbWUg d29ya3Nob3BzLCBhdCBsZWFzdCBhIHBvcnRpb24gb2YgdGhlIGRpc2N1c3Npb24gaXMgaGVsZCB1 c2luZyB0aGUgQ2hhdGhhbSBIb3VzZSBSdWxlIChodHRwczovL3d3dy5jaGF0aGFtaG91c2Uub3Jn L2Fib3V0L2NoYXRoYW0taG91c2UtcnVsZSksIGluIGFuIGF0dGVtcHQgdG8gZWxpY2l0IGlucHV0 IHRoYXQgcGFydGljaXBhbnRzIHdvdWxkIG5vdCBiZSBhYmxlIHRvIG9mZmVyIGluIGEgc2Vzc2lv biB3aGVyZSBhbGwgaW5wdXQgaXMgYXR0cmlidXRlZC4gIEluIHRob3NlIGNhc2VzLCByZW1vdGUg cGFydGljaXBhbnRzIHdvdWxkIG5lZWQgdG8gYWNjZXB0IHRoZSBSdWxlIGV4cGxpY2l0bHksIG9y IGJlIGRyb3BwZWQgZm9yIHRoYXQgcG9ydGlvbiBvZiB0aGUgY29udmVyc2F0aW9uLiAgV2l0aCBy ZW1vdGUgcGFydGljaXBhbnRzLCBDaGF0aGFtIEhvdXNlIFJ1bGUgY29udHJpYnV0aW9ucyBjYW4g YmUgbW9yZSBkaWZmaWN1bHQgdG8gZWxpY2l0IGJlY2F1c2UgaXQgaXMgbW9yZSBkaWZmaWN1bHQg dG8gYnVpbGQgdGhlIHBlcnNvbmFsIHRydXN0IHJlcXVpcmVkLiAgVGhlIHVzZSBvZiB0aGUgQ2hh dGhhbSBIb3VzZSBSdWxlICpoYXMqIGJlZW4gdXNlZnVsIGluIHNldmVyYWwgcHJldmlvdXMgd29y a3Nob3BzLg0KDQpGb3IgbWFueSB3b3Jrc2hvcHMsIGEgdm9pY2Ugb3IgdmlkZW8gcmVjb3JkaW5n IGlzIG1hZGUgdG8gYXNzaXN0IGluIGxhdGVyIHByZXBhcmF0aW9uIG9mIG5vdGVzLiAgUmVjb3Jk aW5nIGRldmljZXMgYXJlIHN0b3BwZWQgZHVyaW5nIGFueSBwb3J0aW9uIG9mIHRoZSBkaXNjdXNz aW9uIHRoZSBoYXBwZW5zIHVuZGVyIHRoZSBDaGF0aGFtIEhvdXNlIFJ1bGUsIGluIG9yZGVyIHRv IGhlbHAgc2hpZWxkIHRoZSBhbm9ueW1pdHkgb2YgdGhlIHBhcnRpY2lwYW50cyBpbiB0aG9zZSBk aXNjdXNzaW9ucy4NCg0KRm9yIHNvbWUgd29ya3Nob3BzLCBpbmRpdmlkdWFsIGludml0ZWQgcmVt b3RlIGNvbnRyaWJ1dG9ycyBtaWdodCBiZSBhY2NvbW1vZGF0ZWQuICBUaGlzIGFwcHJvYWNoIGNh biBhdm9pZCAqc29tZSogb2YgdGhlIHByZXZpb3VzIGlzc3VlcyBieSB0cmFpbmluZyB0aGUgcmVt b3RlIHBhcnRpY2lwYW50IGFoZWFkIG9mIHRoZSBtZWV0aW5nIChjaGVjayBoYXJkd2FyZSwgZW5z dXJlIHRoZXkgYXJlIGFsd2F5cyBvbiBtdXRlIHVubGVzcyBzcGVha2luZywgZXRjKSwgYW5kIGVu c3VyaW5nIHRoYXQgdGhlIHJlbW90ZSBwYXJ0aWNpcGFudCBoYXMgZXhwbGljaXRseSBhZ3JlZWQg dG8gd2hhdGV2ZXIgb3BlcmF0aW5nIHJ1bGVzIGFyZSBjaG9zZW4gYnkgdGhhdCB3b3Jrc2hvcC4g IFN1Y2ggaW52aXRhdGlvbnMgYXJlIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBQQywgYW5kIHdp bGwgYmUgYmFsYW5jZWQgYmV0d2VlbiB0aGUgdXNlZnVsbmVzcyBvZiB0aGUgcmVtb3RlIGNvbnRy aWJ1dGlvbiBhbmQgdGhlIGNvc3QvY29tcGxleGl0eS9kaXNjdXNzaW9uIG92ZXJoZWFkIGNyZWF0 ZWQuDQoNCkZvciBhbGwgd29ya3Nob3BzLCB0aGUgUEMgd2lsbCBzdHJpdmUgdG8gbWFrZSByYXcg bWludXRlcyBhdmFpbGFibGUgYXMgcXVpY2tseSBhcyBwb3NzaWJsZSBhZnRlciB0aGUgd29ya3No b3AuICBGb3Igc2V2ZXJhbCBvZiB0aGUgb2YgdGhlIHJlY2VudCB3b3Jrc2hvcHMsIHRyYW5zY3Jp cHRzIGhhdmUgYmVlbiBhdmFpbGFibGUgd2l0aGluIGEgd2VlayBvciBzby4gIFRoZSBJQUItc3Ry ZWFtIFJGQyB3aXRoIHRoZSBmdWxsIHdvcmtzaG9wIHJlcG9ydCBvZiBjb3Vyc2UgdGFrZXMgbG9u Z2VyIHRvIHByZXBhcmUsIGFuYWx5emUsIGFuZCBhcHByb3ZlLg0KDQpUaGUgUEMgd2lsbCB0aGVy ZWZvcmUgbmVlZCB0byBkZWNpZGUgdGhlIHZhbHVlIG9mIGdldHRpbmcgdGhlIGxhcmdlciBjb21t dW5pdHkgaW5mb3JtYXRpb24gaW4gbmVhciByZWFsIHRpbWUgdnMgd2FpdGluZyBhIHdlZWsgb3Ig c28gZm9yIHRyYW5zY3JpcHRzLiAgSWYgdGhleSBkZWNpZGUgbW9yZSByZW1vdGUgcGFydGljaXBh dGlvbiBpcyBkZXNpcmVkLCB0aGV5IHdpbGwgaGF2ZSB0byBidWRnZXQgYXBwcm9wcmlhdGVseSBm b3IgZXF1aXBtZW50LCB3ZWIgbWVldGluZyBzZXJ2aWNlcywgdGVjaG5pY2lhbnMsIGV0Yy4NCg0K SW4gdGhlIGNhc2Ugb2YgdGhlIE1hUk5FVyB3b3Jrc2hvcCwgdGhlIFBDIGRlY2lkZWQgdGhhdCB3 ZSB3YW50ZWQgYSByb2J1c3QgaW4tcGVyc29uIGRpc2N1c3Npb24gd2l0aCBhIHBvcnRpb24gYmVp bmcgdW5kZXIgdGhlIENoYXRoYW0gSG91c2UgUnVsZS4gIFdlIGZ1cnRoZXIgY29tbWl0dGVkIHRv IGdldHRpbmcgbWludXRlcyBwdWJsaXNoZWQgYXMgcXVpY2tseSBhcyBwb3NzaWJsZSAoaGVyZTog aHR0cHM6Ly9naXRodWIuY29tL01hUk5FVy9NaW51dGVzKS4gIEFzIHN1Y2gsIHdlIGRlY2lkZWQg dGhhdCByZW1vdGUgcGFydGljaXBhdGlvbiB3YXMgbm90IGEgcHJpb3JpdHkgZm9yIHRoaXMgd29y a3Nob3AuDQoNCkluIHRoZSBjYXNlIG9mIHRoZSBJT1RTSSB3b3Jrc2hvcCwgdGhlIHB1cnBvc2Ug d2FzIHRvIGdldCBwYXJ0aWNpcGFudHMgZnJvbSBtYW55IFNET3MgYW5kIG9yZ2FuaXphdGlvbnMg d2l0aCBkaWZmZXJlbnQgSVBSIHJ1bGVzLiAgKEluZGVlZCwgYXMgZGlzY3Vzc2VkIGF0IHRoZSBJ RVRGIDkyIHRlY2ggcGxlbmFyeSwgdGhlIElvVCBzZW1hbnRpYyBpbnRlcm9wZXJhYmlsaXR5IHBy b2JsZW0gaXMgbGFyZ2VseSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgSUVURi4pICBBcyBzdWNo LCB0aGUgUEMgZGVjaWRlZCB0aGF0IHRoZSBJRVRGIE5vdGUgV2VsbCB3b3VsZCBiZSBpbmFwcHJv cHJpYXRlLCBhbmQgdGhhdCBpdCB3b3VsZCBiZSB1cCB0byB0aGUgcGFydGljaXBhbnRzIHdoZXRo ZXIgQ2hhdGhhbSBIb3VzZSBydWxlcyB3b3VsZCBhcHBseS4gIFRoZXJlZm9yZSwgdGhlIFBDIGRl Y2lkZWQgdGhhdCByZW1vdGUgcGFydGljaXBhdGlvbiB3YXMgbm90IGEgcHJpb3JpdHkgZm9yIHRo aXMgd29ya3Nob3AuDQoNCg0KSWYgeW91IHdvdWxkIGxpa2UgdG8gZGlzY3VzcyB0aGlzIGZ1cnRo ZXIgaW4gcHVibGljLCBwbGVhc2UgdXNlIGFyY2hpdGVjdHVyZS1kaXNjdXNzQGlldGYub3JnIChz dWJzY3JpYmUgYXQgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcmNoaXRl Y3R1cmUtZGlzY3VzcykuICBDb25maWRlbnRpYWwgbm90ZXMgY2FuIGJlIHNlbnQgdG8gdGhlIElB QiBhdCBpYWJAaWFiLm9yZy4NCg0KDQotLSANCkpvZSBIaWxkZWJyYW5kDQpPbiBiZWhhbGYgb2Yg dGhlIElBQg0K From nobody Sun Apr 3 11:55:56 2016 Return-Path: X-Original-To: architecture-discuss@ietf.org Delivered-To: architecture-discuss@ietfa.amsl.com Received: from iab.org (dhcp-b2a2.meeting.ietf.org [31.133.178.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id BF8F012D0D8; Sun, 3 Apr 2016 11:36:34 -0700 (PDT) Date: Sun, 3 Apr 2016 14:36:30 -0400 From: IAB Chair To: ietf@ietf.org, ietf-announce@ietf.org, architecture-discuss@ietf.org Message-ID: <20160403183629.GB540@iab.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: X-Mailman-Approved-At: Sun, 03 Apr 2016 11:55:54 -0700 Subject: [arch-d] Report from the IAB before IETF 95 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 18:36:36 -0000 Dear colleagues, This is the report to the community from the IAB about our activities since IETF 94 (which was in Yokohama). We used to go over much of this sort of material in the plenary sessions. Shorter time for plenary sessions in the weekly agenda led us to try this form of report, and it was popular. So we are continuing with it. We hope that this form allows you to prepare topics you might want to discuss during the open mic. But of course, if you have views you want to make known by email, we're easy to reach: send mail to architecture-discuss@iab.org to reach our public discussion list, and iab@iab.org to reach just the IAB The IAB has a few chartered roles. We confirm the appointments to the IESG and perform standards process oversight and handle appeals. We also perform architectural oversight, we manage the RFC series and the IETF's relationship with IANA, and we handle liaisons both to ISOC and to other organizations. We try to ensure that anything we do is part of one of these areas of responsibility, and we try to make sure these are all covered. Since IETF 94, here is what we've done: • RFC 7720, "DNS Root Name Service Protocol and Deployment Requirements". This is a BCP and therefore ended up an AD sponsored RFC. The purpose of this was to modernize RFC 2870 and take out the parts that are not really the IETF's or IAB's job. (External liaisons) • RFC 7687, "Report from the Strengthening the Internet (STRINT) Workshop". More on workshops below. (Architectural oversight) • RFC 7749, "The 'xml2rfc' Version 2 Vocabulary". More about documents about the RFC series below. (Manage the RFC series) • RFC 7754, "Technical Considerations for Internet Service Blocking and Filtering". This is the sort of architectural analysis document that is a big part of the IAB's job. It is fair to say that most of us prefer this sort of work over the administrative pieces. (Architectural oversight) • RFC 7827, "The Role of the IRTF Chair". This is an IAB stream document because the IAB appoints the IRTF Chair. • Internet Of Things Semantic Interoperability (IOTSI) workshop. The IAB gratefully acknowledges the sponsorship of Ericsson in holding this workshop. (Architectural oversight) • Comments on the ICANN CCWG-Accountability third draft report. (External liaison) • Comments on ICANN's “Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars”. (External liaison) • Confirmed the IESG appointments from the Nomcom, for members whose term will start at IETF 95. (Confirm IESG) • Selected Adam Roach as a new member for the RFC Series Oversight Committee. (Manage the RFC series) • Selected a new appointment to the ISOC Board of Trustees. As of this writing, the new appointment hasn't been announced. The IAB's selection is to be confirmed by the IESG. (ISOC liaison) WELCOME TO NEW MEMBERS AND THANKS TO DEPARTING MEMBERS The first IETF meeting of the year is when the new IAB is seated. This also means we sometimes have to say good-bye to departing IAB members. This year, we wish our colleagues Mary Barnes and Marc Blanchet a fond farewell. Mary joined the IAB in 2014 after serving from 2012 to 2014 as the IAB Executive Director. Marc joined the IAB in 2012. The IAB and the Internet community have benefitted greatly from their insights and service, and we thank them both. This year, we are pleased to welcome Lee Howard and Martin Thomson. We know that they will both bring their usual sharp observations and vigour to the IAB's activities. We thank them for being willing to serve the community this way, and thank the Nomcom for their appointment. DOCUMENTS The IAB has several documents in flight. Find the current list of every IAB document in the datatracker, at https://datatracker.ietf.org/stream/iab/. Architectural oversight makes up an important chunk of the current documents: draft-iab-privsec-confidentiality-mitigations-06 Confidentiality in the Face of Pervasive Surveillance draft-iab-protocol-transitions-01 Out With the Old and In With the New: Planning for Protocol Transitions draft-iab-rfc3677bis-00 IETF ISOC Board of Trustee Appointment Procedures draft-iab-web-pki-problems-01 Problems with the Public Key Infrastructure (PKI) for the World Wide Web Currently, there are also quite a few documents related to the planned RFC series format change: draft-iab-html-rfc-02 HyperText Markup Language Request For Comments Format draft-iab-rfc-css-00 CSS Requirements for RFCs draft-iab-rfc-framework-04 RFC Format Framework draft-iab-rfc-nonascii-01 The Use of Non-ASCII Characters in RFCs draft-iab-rfc-plaintext-02 Requirements for Plain-Text RFCs draft-iab-rfc-use-of-pdf-01 PDF for an RFC Series Output Document Format draft-iab-rfc5741bis-02 On RFC Streams, Headers, and Boilerplates draft-iab-rfcv3-preptool-01 RFC v3 Prep Tool Description draft-iab-svg-rfc-02 SVG Drawings for RFCs: SVG 1.2 RFC draft-iab-xml2rfc-03 The "xml2rfc" version 3 Vocabulary These have been out for public comment. As we said previously, the way these are getting handled is that they all note that they're likely to change. We'll publish them, then get some experience. Later, we might find that some of our choices turn out to be less than ideal, so we'll have a chance to adjust the final implementation. WORKSHOPS As noted above, the IAB held the IOTSI workshop in March. We've decided to continue using the mailing list for further follow-on discussion; you can join iotsi@iab.org at https://www.iab.org/mailman/listinfo/iotsi. An issue came up with this workshop that has come up before and that we mentioned last time: workshop transparency and remote participation. As part of the IAB's job of architectural oversight, we try to convene workshops to inform observations. These are usually about gaps or issues we see, in an effort to draw attention to those things from the wider IETF community. Workshops of this sort work best when the group is somewhat small and informal, because that tends to encourage informal discussion and easy exploration of the issues. But of course, the IAB is often not the only group that notices the issues or gaps, and others often want to participate. Some people can't make the trip to a workshop; others just want to follow along. Yet the necessary style to support remote participation is probably more formal and presentation-oriented than may always be good. The IAB's current policies about this are reflected in a note we posted at https://mailarchive.ietf.org/arch/msg/architecture-discuss/Vns0-GWYOHqP9wq7uic0DS331co. The short version is that we are not going to commit to remote participation generally, but it will be something we ask workshop organizers to consider in designing workshops. Please have a look at the full posting for all the considerations on this topic. PROGRAMS The IAB organizes its work, for the most part, into programs. There are basically two classes: management programs and architectural programs. The former are how we handle the oversight of various things, and the latter are where we do architectural work. The former are expected to last as long as the IAB continues to have that oversight function; the latter last until the IAB has come to a conclusion on the relevant group of topics, and we expect them to wind down afterwards. Since IETF 94, we have taken to reviewing the programs as part of our regular teleconferences. The goal is to perform one review of every program between every IETF meeting, though that won't always be possible. We'd noticed that program reviews were too infrequent (historically, just once a year, at the IAB retreat). More regular review allows us to adjust program priorities and membership more often, and we hope that it will ensure that programs remain vital (or else close down). Minutes of the reviews appear in the regular IAB meeting minutes, which you can find at https://www.iab.org/documents/minutes/. Every program has an associated discussion list where topics relevant to the program can be discussed by anyone who wants to join. You can find the lists at https://www.iab.org/iab-mailing-lists/. Management programs: IANA Evolution IETF Protocol Registries Oversight Committee (IPROC, with IAOC) These programs have been attending to the anticipated change to the IANA's relationship to the US Government. The former of these is responsible to keep track of the IETF's use of IANA, and the latter ensures that the IANA Memorandum of Understanding with ICANN is administered effectively. Participants in this area have been, perhaps unfortunately, extremely busy as a result of the IANA changes. IPROC was reviewed on 2016-01-27 and IANA oversight was reviewed on 2016-02-10. Liaison Oversight Reviewed on 2016-03-23. RFC Editor (includes RSOC) This program has of course been at the centre of the RFC series format changes; it was reviewed 2016-02-24. Architectural issues: Emergency Services Reviewed 2016-02-03, closed as of 2016-04-03 Internationalization This program is up for review soon. At a previous technical plenary we had some discussion of the state of affairs with internationalization, and there is still reason to be concerned that this topic is in serious trouble around the IETF. IP Stack Evolution Reviewed 2016-03-02 Names and Identifiers The Names and Identifiers program has not been reviewed yet (it is up next), but it has been generating quite a bit of discussion on inip-discuss@iab.org. The arcing BoF at IETF 95 was inspired in part by some of those discussions. Privacy and Security Reviewed 2016-01-13. INTERNET RESEARCH TASK FORCE The IAB appoints the IRTF Chair. Lars Eggert, the current IRTF Chair, has announced that he will not seek re-appointment, having served since March of 2011. The IAB is starting its search for a new Chair. We are grateful for Lars's tremendous service in this role, and we'll have our work cut out for us. We will be making announcements soon about our search, so look for those. In the meantime, if you are interested or know someone who you think might be a good candidate, have a look at RFC 7827 to see what the job entails. Respectfully submitted, Andrew Sullivan For the IAB -- IAB Chair (Andrew Sullivan) iab-chair@iab.org From nobody Wed Apr 20 11:18:57 2016 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A9E12DF7D; Wed, 20 Apr 2016 11:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 NqQujU6OETuO; Wed, 20 Apr 2016 11:18:53 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 75BDB12E2FC; Wed, 20 Apr 2016 11:18:42 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 27E2EF2402A; Wed, 20 Apr 2016 14:18:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id doprNttL2y6a; Wed, 20 Apr 2016 14:03:14 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 72E2D9A4001; Wed, 20 Apr 2016 14:18:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <6EC360A9-BE71-4EFF-A4DF-9D9F8CD0614F@harvard.edu> Date: Wed, 20 Apr 2016 14:18:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2BF65369-2400-46DC-88A4-5159A3B8FBAB@vigilsec.com> References: <20160224175935.21103.69618.idtracker@ietfa.amsl.com> <6EC360A9-BE71-4EFF-A4DF-9D9F8CD0614F@harvard.edu> To: Scott Bradner X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IAB , IETF , "architecture-discuss@ietf.org" Subject: Re: [arch-d] [IAB] Call for Comment: (IETF ISOC Board of Trustee Appointment Procedures) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 18:18:55 -0000 Scott: I cannot see how the change that you are proposing to the ISOC Bylaws = has any impact on the content of rfc3677bis. What am I missing? If I am not missing anything, then it seems to me that waiting to move = forward on this is counter to may of the other comments that we got = about acting promptly to keep our document in sync with the current = bylaws. Russ On Feb 25, 2016, at 7:27 AM, Bradner, Scott wrote: > re section 3.5 mid-term vacancies >=20 > please hold off on this particular section for a bit - I am in the = middle of proposing some changes=20 > to the ISOC bylaws - mostly to clear up some confusions - and one of = these changes concerns IETF vacancy appointments >=20 > the current bylaws do not limit when the IETF can appoint someone to = fill a vacancy but do limit when such an > appointment can take office to the start of the ISOC mid year meeting, = when all new trustees take office - which might > be a bit frustrating to the appointee >=20 > I am proposing a bylaws update that will put the IETF appointment t = fill a vacancy to be the same > as it is for the chapters & org members - with until the next = appointment cycle (to do otherwise > provided unequal treatment for the IETF) >=20 > in any case some change is needed to clarify the existing situation >=20 > Scott >=20 >> On Feb 24, 2016, at 12:59 PM, IAB Executive Administrative Manager = wrote: >>=20 >> This is an announcement of an IETF-wide Call for Comment on >> draft-iab-rfc3677bis-00. >>=20 >> The document is being considered for publication as a Best Current=20 >> Practice RFC within the IAB stream, and is available for inspection=20= >> here: https://datatracker.ietf.org/doc/draft-iab-rfc3677bis/ >>=20 >> The Call for Comment will last until 2016-03-23. Please send comments = to >> architecture-discuss@ietf.org and iab@iab.org. >>=20 >>=20 >> Abstract >>=20 >> This memo, which obsoletes RFC3677, outlines the process by which = the >> IETF makes a selection of an Internet Society (ISOC) Board of >> Trustees appointment. >>=20 >=20 From nobody Wed Apr 20 11:41:25 2016 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE4E12EBD0; Wed, 20 Apr 2016 11:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 6qrqFfRDcU7I; Wed, 20 Apr 2016 11:41:23 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B27912EE0D; Wed, 20 Apr 2016 11:41:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 1FC5F1C6E1D9; Wed, 20 Apr 2016 14:41:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZwFmklsdskD; Wed, 20 Apr 2016 14:41:15 -0400 (EDT) Received: from [10.251.213.164] (unknown [65.112.10.217]) by sobco.sobco.com (Postfix) with ESMTPSA id B228B1C6E1CE; Wed, 20 Apr 2016 14:41:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Scott O. Bradner" X-Mailer: iPhone Mail (13E238) In-Reply-To: <2BF65369-2400-46DC-88A4-5159A3B8FBAB@vigilsec.com> Date: Wed, 20 Apr 2016 14:41:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1606171A-73E6-4553-AFB4-9C5AE2C6B7DE@sobco.com> References: <20160224175935.21103.69618.idtracker@ietfa.amsl.com> <6EC360A9-BE71-4EFF-A4DF-9D9F8CD0614F@harvard.edu> <2BF65369-2400-46DC-88A4-5159A3B8FBAB@vigilsec.com> To: Russ Housley Archived-At: Cc: "architecture-discuss@ietf.org" , IAB , Scott Bradner , IETF Subject: Re: [arch-d] [IAB] Call for Comment: (IETF ISOC Board of Trustee Appointment Procedures) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 18:41:24 -0000 My quick read of the vacancy process assumed an approach that made an appoin= tment when a vacancy occurs and the proposal is to have the IETF follow the= same process as the other groups that select trustees and add the seat to t= he next selection cycle I may have misread the 3677bis proposal If so please correct me=20 Scott Sent from my iPhone > On Apr 20, 2016, at 2:18 PM, Russ Housley wrote: >=20 > Scott: >=20 > I cannot see how the change that you are proposing to the ISOC Bylaws has a= ny impact on the content of rfc3677bis. What am I missing? >=20 > If I am not missing anything, then it seems to me that waiting to move for= ward on this is counter to may of the other comments that we got about actin= g promptly to keep our document in sync with the current bylaws. >=20 > Russ >=20 >> On Feb 25, 2016, at 7:27 AM, Bradner, Scott wrote: >>=20 >> re section 3.5 mid-term vacancies >>=20 >> please hold off on this particular section for a bit - I am in the middle= of proposing some changes=20 >> to the ISOC bylaws - mostly to clear up some confusions - and one of thes= e changes concerns IETF vacancy appointments >>=20 >> the current bylaws do not limit when the IETF can appoint someone to fill= a vacancy but do limit when such an >> appointment can take office to the start of the ISOC mid year meeting, wh= en all new trustees take office - which might >> be a bit frustrating to the appointee >>=20 >> I am proposing a bylaws update that will put the IETF appointment t fill a= vacancy to be the same >> as it is for the chapters & org members - with until the next appointment= cycle (to do otherwise >> provided unequal treatment for the IETF) >>=20 >> in any case some change is needed to clarify the existing situation >>=20 >> Scott >>=20 >>> On Feb 24, 2016, at 12:59 PM, IAB Executive Administrative Manager wrote: >>>=20 >>> This is an announcement of an IETF-wide Call for Comment on >>> draft-iab-rfc3677bis-00. >>>=20 >>> The document is being considered for publication as a Best Current=20 >>> Practice RFC within the IAB stream, and is available for inspection=20 >>> here: https://datatracker.ietf.org/doc/draft-iab-rfc3677bis/ >>>=20 >>> The Call for Comment will last until 2016-03-23. Please send comments to= >>> architecture-discuss@ietf.org and iab@iab.org. >>>=20 >>>=20 >>> Abstract >>>=20 >>> This memo, which obsoletes RFC3677, outlines the process by which the >>> IETF makes a selection of an Internet Society (ISOC) Board of >>> Trustees appointment. >>>=20 >>=20 >=20 From nobody Wed Apr 20 11:43:33 2016 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1054D12D82E; Wed, 20 Apr 2016 11:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 575fIr6Y8nnO; Wed, 20 Apr 2016 11:43:26 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2735A12DB98; Wed, 20 Apr 2016 11:43:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 55C141C6E297; Wed, 20 Apr 2016 14:43:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0k1gU3t02IrQ; Wed, 20 Apr 2016 14:43:23 -0400 (EDT) Received: from [10.251.213.164] (unknown [65.112.10.217]) by sobco.sobco.com (Postfix) with ESMTPSA id 0FDDA1C6E286; Wed, 20 Apr 2016 14:43:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Scott O. Bradner" X-Mailer: iPhone Mail (13E238) In-Reply-To: <2BF65369-2400-46DC-88A4-5159A3B8FBAB@vigilsec.com> Date: Wed, 20 Apr 2016 14:43:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4F6B020D-E3B7-48BE-9BD1-77D814D25F2E@sobco.com> References: <20160224175935.21103.69618.idtracker@ietfa.amsl.com> <6EC360A9-BE71-4EFF-A4DF-9D9F8CD0614F@harvard.edu> <2BF65369-2400-46DC-88A4-5159A3B8FBAB@vigilsec.com> To: Russ Housley Archived-At: Cc: "architecture-discuss@ietf.org" , IAB , Scott Bradner , IETF Subject: Re: [arch-d] [IAB] Call for Comment: (IETF ISOC Board of Trustee Appointment Procedures) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 18:43:32 -0000 Ps the trustees approved sending the by laws proposals out for comment and t= hat will happen in the next few days Scott Sent from my iPhone > On Apr 20, 2016, at 2:18 PM, Russ Housley wrote: >=20 > Scott: >=20 > I cannot see how the change that you are proposing to the ISOC Bylaws has a= ny impact on the content of rfc3677bis. What am I missing? >=20 > If I am not missing anything, then it seems to me that waiting to move for= ward on this is counter to may of the other comments that we got about actin= g promptly to keep our document in sync with the current bylaws. >=20 > Russ >=20 >> On Feb 25, 2016, at 7:27 AM, Bradner, Scott wrote: >>=20 >> re section 3.5 mid-term vacancies >>=20 >> please hold off on this particular section for a bit - I am in the middle= of proposing some changes=20 >> to the ISOC bylaws - mostly to clear up some confusions - and one of thes= e changes concerns IETF vacancy appointments >>=20 >> the current bylaws do not limit when the IETF can appoint someone to fill= a vacancy but do limit when such an >> appointment can take office to the start of the ISOC mid year meeting, wh= en all new trustees take office - which might >> be a bit frustrating to the appointee >>=20 >> I am proposing a bylaws update that will put the IETF appointment t fill a= vacancy to be the same >> as it is for the chapters & org members - with until the next appointment= cycle (to do otherwise >> provided unequal treatment for the IETF) >>=20 >> in any case some change is needed to clarify the existing situation >>=20 >> Scott >>=20 >>> On Feb 24, 2016, at 12:59 PM, IAB Executive Administrative Manager wrote: >>>=20 >>> This is an announcement of an IETF-wide Call for Comment on >>> draft-iab-rfc3677bis-00. >>>=20 >>> The document is being considered for publication as a Best Current=20 >>> Practice RFC within the IAB stream, and is available for inspection=20 >>> here: https://datatracker.ietf.org/doc/draft-iab-rfc3677bis/ >>>=20 >>> The Call for Comment will last until 2016-03-23. Please send comments to= >>> architecture-discuss@ietf.org and iab@iab.org. >>>=20 >>>=20 >>> Abstract >>>=20 >>> This memo, which obsoletes RFC3677, outlines the process by which the >>> IETF makes a selection of an Internet Society (ISOC) Board of >>> Trustees appointment. >>>=20 >>=20 >=20 From nobody Wed Apr 20 12:30:40 2016 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C74B12E4BF; Wed, 20 Apr 2016 12:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 jZoFqpkyKN6Q; Wed, 20 Apr 2016 12:30:32 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 10F7712E49C; Wed, 20 Apr 2016 12:30:32 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id BB9DE9A4001; Wed, 20 Apr 2016 15:30:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id JX9z7OxTBewb; Wed, 20 Apr 2016 15:15:03 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D0B95F2402A; Wed, 20 Apr 2016 15:30:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <1606171A-73E6-4553-AFB4-9C5AE2C6B7DE@sobco.com> Date: Wed, 20 Apr 2016 15:30:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6F1589B6-8408-4533-BBBF-5BFD7BE36756@vigilsec.com> References: <20160224175935.21103.69618.idtracker@ietfa.amsl.com> <6EC360A9-BE71-4EFF-A4DF-9D9F8CD0614F@harvard.edu> <2BF65369-2400-46DC-88A4-5159A3B8FBAB@vigilsec.com> <1606171A-73E6-4553-AFB4-9C5AE2C6B7DE@sobco.com> To: Scott Bradner X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "architecture-discuss@ietf.org" , IAB , Scott Bradner , IETF Subject: Re: [arch-d] [IAB] Call for Comment: (IETF ISOC Board of Trustee Appointment Procedures) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 19:30:35 -0000 Scott: I think that the language can be aligned with very minimal changes. If I have understood the potential change to the ISOC Bylaws, this will work with the current bylaws and the poposed ones, if they are approved. OLD: This document describes the process for the general, annual appointment of ISOC Trustees to fill the seats of Trustees whose terms are ending. However, if an IETF-appointed Trustee is unable to serve his or her full term, the IAB may, at its discretion, immediately select a replacement to serve the remainder of the term using the interim process defined in Section 3.5.1. If the IAB does not invoke the interim process, the next annual selection process will fill the vacancy (if the vacant term does not end at that point) as well as the regular appointment for that selection cycle. NEW: This document describes the process for the general, annual appointment of ISOC Trustees to fill the seats of Trustees whose terms are ending. However, if an IETF-appointed Trustee is unable to serve his or her full term, the IAB may, at its discretion, select a replacement to serve the remainder of the term using the interim process defined in Section 3.5.1, with a start date consistent with the [ISOC-By-Laws]. If the IAB does not invoke the interim process, the next annual selection process will fill the vacancy (if the vacant term does not end at that point) as well as the regular appointment for that selection cycle. Russ On Apr 20, 2016, at 2:41 PM, Scott O. Bradner wrote: > My quick read of the vacancy process assumed an approach that made an = appointment when a vacancy occurs and the proposal is to have the IETF = follow the same process as the other groups that select trustees and add = the seat to the next selection cycle >=20 > I may have misread the 3677bis proposal > If so please correct me=20 >=20 > Scott >=20 >=20 > Sent from my iPhone >=20 >> On Apr 20, 2016, at 2:18 PM, Russ Housley = wrote: >>=20 >> Scott: >>=20 >> I cannot see how the change that you are proposing to the ISOC Bylaws = has any impact on the content of rfc3677bis. What am I missing? >>=20 >> If I am not missing anything, then it seems to me that waiting to = move forward on this is counter to may of the other comments that we got = about acting promptly to keep our document in sync with the current = bylaws. >>=20 >> Russ >>=20 >>> On Feb 25, 2016, at 7:27 AM, Bradner, Scott wrote: >>>=20 >>> re section 3.5 mid-term vacancies >>>=20 >>> please hold off on this particular section for a bit - I am in the = middle of proposing some changes=20 >>> to the ISOC bylaws - mostly to clear up some confusions - and one of = these changes concerns IETF vacancy appointments >>>=20 >>> the current bylaws do not limit when the IETF can appoint someone to = fill a vacancy but do limit when such an >>> appointment can take office to the start of the ISOC mid year = meeting, when all new trustees take office - which might >>> be a bit frustrating to the appointee >>>=20 >>> I am proposing a bylaws update that will put the IETF appointment t = fill a vacancy to be the same >>> as it is for the chapters & org members - with until the next = appointment cycle (to do otherwise >>> provided unequal treatment for the IETF) >>>=20 >>> in any case some change is needed to clarify the existing situation >>>=20 >>> Scott >>>=20 >>>> On Feb 24, 2016, at 12:59 PM, IAB Executive Administrative Manager = wrote: >>>>=20 >>>> This is an announcement of an IETF-wide Call for Comment on >>>> draft-iab-rfc3677bis-00. >>>>=20 >>>> The document is being considered for publication as a Best Current=20= >>>> Practice RFC within the IAB stream, and is available for inspection=20= >>>> here: https://datatracker.ietf.org/doc/draft-iab-rfc3677bis/ >>>>=20 >>>> The Call for Comment will last until 2016-03-23. Please send = comments to >>>> architecture-discuss@ietf.org and iab@iab.org. >>>>=20 >>>>=20 >>>> Abstract >>>>=20 >>>> This memo, which obsoletes RFC3677, outlines the process by which = the >>>> IETF makes a selection of an Internet Society (ISOC) Board of >>>> Trustees appointment. >>>>=20 >>>=20 >>=20 From nobody Wed Apr 20 12:41:18 2016 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8451912E61C; Wed, 20 Apr 2016 12:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 4ano4xVxGIrt; Wed, 20 Apr 2016 12:41:12 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581BE12E52A; Wed, 20 Apr 2016 12:41:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 7B5851C6F25C; Wed, 20 Apr 2016 15:41:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mvJhl_VEONP; Wed, 20 Apr 2016 15:41:04 -0400 (EDT) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 3F5211C6F245; Wed, 20 Apr 2016 15:41:04 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Scott O. Bradner" In-Reply-To: <6F1589B6-8408-4533-BBBF-5BFD7BE36756@vigilsec.com> Date: Wed, 20 Apr 2016 15:41:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7D1073A2-E7F5-4B0B-A70D-5F5218F4CB09@sobco.com> References: <20160224175935.21103.69618.idtracker@ietfa.amsl.com> <6EC360A9-BE71-4EFF-A4DF-9D9F8CD0614F@harvard.edu> <2BF65369-2400-46DC-88A4-5159A3B8FBAB@vigilsec.com> <1606171A-73E6-4553-AFB4-9C5AE2C6B7DE@sobco.com> <6F1589B6-8408-4533-BBBF-5BFD7BE36756@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IAB , IETF , "architecture-discuss@ietf.org" Subject: Re: [arch-d] [IAB] Call for Comment: (IETF ISOC Board of Trustee Appointment Procedures) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 19:41:13 -0000 that is not actually consistent the proposed bylaws change says that the seat is added to the next = selection cycle not that someone gets picked outside of the cycle and only gets seated = when the=20 people seated by the next selection cycle get seated it would seem to be more straightforward to just say =E2=80=9Cadded to = the next selection cycle=E2=80=9D and I think it would be easier on the IETF to not run multiple selection = processes (perhaps overlapping)=20 in a year Scott > On Apr 20, 2016, at 3:30 PM, Russ Housley = wrote: >=20 > Scott: >=20 > I think that the language can be aligned with very minimal changes. >=20 > If I have understood the potential change to the ISOC Bylaws, this > will work with the current bylaws and the poposed ones, if they are > approved. >=20 > OLD: >=20 > This document describes the process for the general, annual > appointment of ISOC Trustees to fill the seats of Trustees whose > terms are ending. However, if an IETF-appointed Trustee is unable = to > serve his or her full term, the IAB may, at its discretion, > immediately select a replacement to serve the remainder of the term > using the interim process defined in Section 3.5.1. If the IAB does > not invoke the interim process, the next annual selection process > will fill the vacancy (if the vacant term does not end at that = point) > as well as the regular appointment for that selection cycle. >=20 > NEW: >=20 > This document describes the process for the general, annual > appointment of ISOC Trustees to fill the seats of Trustees whose > terms are ending. However, if an IETF-appointed Trustee is unable = to > serve his or her full term, the IAB may, at its discretion, select a > replacement to serve the remainder of the term using the interim > process defined in Section 3.5.1, with a start date consistent > with the [ISOC-By-Laws]. If the IAB does not invoke the interim > process, the next annual selection process will fill the vacancy > (if the vacant term does not end at that point) as well as the > regular appointment for that selection cycle. >=20 > Russ >=20 >=20 > On Apr 20, 2016, at 2:41 PM, Scott O. Bradner wrote: >=20 >> My quick read of the vacancy process assumed an approach that made an = appointment when a vacancy occurs and the proposal is to have the IETF = follow the same process as the other groups that select trustees and add = the seat to the next selection cycle >>=20 >> I may have misread the 3677bis proposal >> If so please correct me=20 >>=20 >> Scott >>=20 >>=20 >> Sent from my iPhone >>=20 >>> On Apr 20, 2016, at 2:18 PM, Russ Housley = wrote: >>>=20 >>> Scott: >>>=20 >>> I cannot see how the change that you are proposing to the ISOC = Bylaws has any impact on the content of rfc3677bis. What am I missing? >>>=20 >>> If I am not missing anything, then it seems to me that waiting to = move forward on this is counter to may of the other comments that we got = about acting promptly to keep our document in sync with the current = bylaws. >>>=20 >>> Russ >>>=20 >>>> On Feb 25, 2016, at 7:27 AM, Bradner, Scott = wrote: >>>>=20 >>>> re section 3.5 mid-term vacancies >>>>=20 >>>> please hold off on this particular section for a bit - I am in the = middle of proposing some changes=20 >>>> to the ISOC bylaws - mostly to clear up some confusions - and one = of these changes concerns IETF vacancy appointments >>>>=20 >>>> the current bylaws do not limit when the IETF can appoint someone = to fill a vacancy but do limit when such an >>>> appointment can take office to the start of the ISOC mid year = meeting, when all new trustees take office - which might >>>> be a bit frustrating to the appointee >>>>=20 >>>> I am proposing a bylaws update that will put the IETF appointment t = fill a vacancy to be the same >>>> as it is for the chapters & org members - with until the next = appointment cycle (to do otherwise >>>> provided unequal treatment for the IETF) >>>>=20 >>>> in any case some change is needed to clarify the existing situation >>>>=20 >>>> Scott >>>>=20 >>>>> On Feb 24, 2016, at 12:59 PM, IAB Executive Administrative Manager = wrote: >>>>>=20 >>>>> This is an announcement of an IETF-wide Call for Comment on >>>>> draft-iab-rfc3677bis-00. >>>>>=20 >>>>> The document is being considered for publication as a Best Current=20= >>>>> Practice RFC within the IAB stream, and is available for = inspection=20 >>>>> here: https://datatracker.ietf.org/doc/draft-iab-rfc3677bis/ >>>>>=20 >>>>> The Call for Comment will last until 2016-03-23. Please send = comments to >>>>> architecture-discuss@ietf.org and iab@iab.org. >>>>>=20 >>>>>=20 >>>>> Abstract >>>>>=20 >>>>> This memo, which obsoletes RFC3677, outlines the process by which = the >>>>> IETF makes a selection of an Internet Society (ISOC) Board of >>>>> Trustees appointment. >>>>>=20 >>>>=20 >>>=20 >=20 From nobody Wed Apr 20 12:51:31 2016 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F140212E4B9; Wed, 20 Apr 2016 12:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 Ajutoqm9PwRD; Wed, 20 Apr 2016 12:51:29 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1BB12E4C7; Wed, 20 Apr 2016 12:51:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id C5EB01C6F6D3; Wed, 20 Apr 2016 15:51:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QssQqqeWbcuq; Wed, 20 Apr 2016 15:51:27 -0400 (EDT) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 42D151C6F6C5; Wed, 20 Apr 2016 15:51:27 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Scott O. Bradner" In-Reply-To: <6F1589B6-8408-4533-BBBF-5BFD7BE36756@vigilsec.com> Date: Wed, 20 Apr 2016 15:51:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160224175935.21103.69618.idtracker@ietfa.amsl.com> <6EC360A9-BE71-4EFF-A4DF-9D9F8CD0614F@harvard.edu> <2BF65369-2400-46DC-88A4-5159A3B8FBAB@vigilsec.com> <1606171A-73E6-4553-AFB4-9C5AE2C6B7DE@sobco.com> <6F1589B6-8408-4533-BBBF-5BFD7BE36756@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IAB , IETF , "architecture-discuss@ietf.org" Subject: Re: [arch-d] [IAB] Call for Comment: (IETF ISOC Board of Trustee Appointment Procedures) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 19:51:30 -0000 since we are talking about it - here is the proposal - it would have = come out in the next few days anyway Current bylaws text in Article II section 3: = --------------------------------------------------------------------------= ---------------------------------------------------------------------- Any vacancy for a Board seat filled by election shall be filled by = including the open seat in the next regular election or selection = process for that seat after the vacancy occurs so long as a call for = nominations has not been announced. If an election includes seats with = terms or remaining terms that are unequal in length, then the seat with = the longest term shall be filled by the candidate receiving the most = votes, the seat with the next longest term shall be filled by the = candidate receiving the next most votes, and so on. =20 Any vacancy for a board seat filled by the Internet Engineering Task = Force shall be filled by the Internet Engineering Task Force using a = process of their own choosing. =20 Any Trustee elected or appointed by the above processes to fill a = vacancy will hold office commencing at the start of the Annual General = Meeting (AGM) following their election or appointment. Proposal: = --------------------------------------------------------------------------= ---------------------------------------------------------------------- remove "or selection" from the first sentence of the first paragraph. Reason: to be consistent with proposed change to Article 2 section 1. Proposal: replace 2nd paragraph with the following: = --------------------------------------------------------------------------= ---------------------------------------------------------------------- Any vacancy for a Board seat filled by the Internet Engineering Task = Force shall be filled by including the open seat in the next regular = appointment process for that seat after the vacancy occurs so long as a = call for candidates has not been announced. If an appointment process = includes seats with terms or remaining terms that are unequal in length, = then Internet Engineering Task Force shall decide which appointment is = to receive which term though a mechanism of its own choosing. Reason: = --------------------------------------------------------------------------= ---------------------------------------------------------------------- to remove the confusion that would result if the IETF were to fill a = vacancy and the selection would not be able to be seated until the next = AGM and to make the vacancy processes consistent for all trustees= From nobody Wed Apr 20 13:14:16 2016 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A883112DC75; Wed, 20 Apr 2016 13:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 ep-wP-7fD-3g; Wed, 20 Apr 2016 13:14:13 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0FFA12DB4B; Wed, 20 Apr 2016 13:14:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id A4D9B1C700A7; Wed, 20 Apr 2016 16:14:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN6oWI2ArKwq; Wed, 20 Apr 2016 16:14:10 -0400 (EDT) Received: from [10.0.1.16] (173-166-5-69-newengland.hfc.comcastbusiness.net [173.166.5.69]) by sobco.sobco.com (Postfix) with ESMTPSA id 1F5EB1C70096; Wed, 20 Apr 2016 16:14:10 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Scott O. Bradner" In-Reply-To: Date: Wed, 20 Apr 2016 16:14:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160224175935.21103.69618.idtracker@ietfa.amsl.com> <6EC360A9-BE71-4EFF-A4DF-9D9F8CD0614F@harvard.edu> <2BF65369-2400-46DC-88A4-5159A3B8FBAB@vigilsec.com> <1606171A-73E6-4553-AFB4-9C5AE2C6B7DE@sobco.com> <6F1589B6-8408-4533-BBBF-5BFD7BE36756@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IAB , IETF , "architecture-discuss@ietf.org" Subject: Re: [arch-d] [IAB] Call for Comment: (IETF ISOC Board of Trustee Appointment Procedures) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 20:14:14 -0000 one other thing I should make clear - this is a proposal and the ISOC = Board will be asking for input on it it should not be seen as a fait accompli - a special address is being = setup for the comments & the request will be sent out in the next few days Scott > On Apr 20, 2016, at 3:51 PM, Scott O. Bradner wrote: >=20 > since we are talking about it - here is the proposal - it would have = come out in the next few days anyway >=20 > Current bylaws text in Article II section 3: > = --------------------------------------------------------------------------= ---------------------------------------------------------------------- > Any vacancy for a Board seat filled by election shall be filled by = including the open seat in the next regular election or selection = process for that seat after the vacancy occurs so long as a call for = nominations has not been announced. If an election includes seats with = terms or remaining terms that are unequal in length, then the seat with = the longest term shall be filled by the candidate receiving the most = votes, the seat with the next longest term shall be filled by the = candidate receiving the next most votes, and so on. >=20 > Any vacancy for a board seat filled by the Internet Engineering Task = Force shall be filled by the Internet Engineering Task Force using a = process of their own choosing. >=20 > Any Trustee elected or appointed by the above processes to fill a = vacancy will hold office commencing at the start of the Annual General = Meeting (AGM) following their election or appointment. >=20 >=20 > Proposal: > = --------------------------------------------------------------------------= ---------------------------------------------------------------------- > remove "or selection" from the first sentence of the first paragraph. > Reason: >=20 > to be consistent with proposed change to Article 2 section 1. >=20 >=20 > Proposal: replace 2nd paragraph with the following: > = --------------------------------------------------------------------------= ---------------------------------------------------------------------- > Any vacancy for a Board seat filled by the Internet Engineering Task = Force shall be filled by including the open seat in the next regular = appointment process for that seat after the vacancy occurs so long as a = call for candidates has not been announced. If an appointment process = includes seats with terms or remaining terms that are unequal in length, = then Internet Engineering Task Force shall decide which appointment is = to receive which term though a mechanism of its own choosing. >=20 >=20 > Reason: > = --------------------------------------------------------------------------= ---------------------------------------------------------------------- > to remove the confusion that would result if the IETF were to fill a = vacancy and the selection would not be able to be seated until the next = AGM and to make the vacancy processes consistent for all trustees