IETF Logo Mail Archive

Re: [Iasa20] 6635bis

"Livingood, Jason" <Jason_Livingood@comcast.com> Fri, 26 April 2019 19:55 UTC

Return-Path: <Jason_Livingood@comcast.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 6CF06120370 for <iasa20@ietfa.amsl.com>; Fri, 26 Apr 2019 12:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 NiLIBy2V8wtV for <iasa20@ietfa.amsl.com>; Fri, 26 Apr 2019 12:55:42 -0700 (PDT)
Received: from copdcmhout01.cable.comcast.com (copdcmhout01.cable.comcast.com [162.150.44.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77446120256 for <iasa20@ietf.org>; Fri, 26 Apr 2019 12:55:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1556308535; x=2420222135; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lenLyCrGutwI85F5IDpbAT6jlPj7VTaS9526GoV60ss=; b=pwLfVLV9npB65UaE46MDrlAzmUpzOFuSEWamBS/fSKQK51UExko4WrjfJDmHuUUt gWhsU/xhGGpQPwEGns5OsyNEkXVMEYn95B8knU4DKI+FIg4pW594OWcbt9ni7gVJ ONvRm7APhmid2KZxyLjqNwR7blg3vj8XSCz+asVFCrYcgwccwpr2eT2SYNsNcXmu gPdGjWafOjC3LpqKk0ZzuI1Gm39ojKhAEhfhXGKp6AN/uukWd1Mv/w7Z9fLZMnSZ LN8fc5DTUCH3dDeg+JH85ebG5f8eGjsJBFdMjTNXRV/xMLtMSqS5DXkfRY4zfkq6 QbhT660tOoVbJlQO9r4Dgw==;
X-AuditID: a2962c47-d05ff70000021564-58-5cc36237dcc9
Received: from COPDCEXC38.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by copdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 52.7A.05476.73263CC5; Fri, 26 Apr 2019 13:55:35 -0600 (MDT)
Received: from COPDCEXC37.cable.comcast.com (147.191.125.136) by COPDCEXC38.cable.comcast.com (147.191.125.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 26 Apr 2019 15:55:40 -0400
Received: from COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94]) by COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94%15]) with mapi id 15.01.1713.004; Fri, 26 Apr 2019 15:55:40 -0400
From: "Livingood, Jason" <Jason_Livingood@comcast.com>
To: Russ Housley <housley@vigilsec.com>, Bob Hinden <bob.hinden@gmail.com>, Sean Turner <sean@sn3rd.com>, "iasa20@ietf.org" <iasa20@ietf.org>
Thread-Topic: [Iasa20] 6635bis
Thread-Index: AQHU+5LF79eEJXtiYUi6XjZQJDHXOqZNuY+AgAEfC4CAAARMAA==
Date: Fri, 26 Apr 2019 19:55:40 +0000
Message-ID: <FE58E896-F9AF-4F22-A454-288118475F47@cable.comcast.com>
References: <CCCFB260-660F-4CB9-AA4F-60F8B88465CB@sn3rd.com> <0A8ABED3-77B1-487C-BCCA-F1A4523DB9CF@gmail.com> <E6CBE88F-CA59-41D3-B62C-46330ED8FAB4@vigilsec.com>
In-Reply-To: <E6CBE88F-CA59-41D3-B62C-46330ED8FAB4@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.18.0.190414
x-originating-ip: [96.114.156.9]
Content-Type: text/plain; charset="utf-8"
Content-ID: <60CA599CDEB7C74BAA31CB9D4A5499AB@comcast.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRmVeSWpSXmKPExsWSUDRnsq550uEYg89N0hZb3+9js3j14ia7 xZLpG5ksrqxqZHZg8dg56y67x5IlP5k8Dh5k9Fh15wtrAEtUA6NNSUZRamKJS2paal5xqh2X AgawSUpNyy9KdU0syqkMSs1JTcSuDKQyJTUnsyy1SB+rMfpYzUnoYso4czit4AV3Rd/RuAbG A9xdjBwcEgImEh033LsYuTiEBHYxSaycNpMRwmlhklix7ASUc5pRYsfrE6xdjJwcbAJmEncX XmEGSYgI9DNKTGnawgSSEBaQlXj+ZzMziC0iICdx+MhbRgjbSeLPpLssIOtYBFQlVi6XBQnz CrhItC6awgSxYCmjxOz/j8DqOQUcJOYe7gebySggJvH91Bowm1lAXOLWk/lgtoSAgMSSPeeZ IWxRiZeP/4EdJyqgL7FnwR1GiLiCxPt/p9hA9jILaEqs36UPMcZK4uj8AywQtqLElO6H7BD3 CEqcnPmEBaJVHOj8HawTGCVmIdk8C2HSLCSTZiGZNAvJpAWMrKsYeQ3NjPQMTQ30TEz0zA03 MQIT0aJpOu47GD+cjz3EKMDBqMTDu8r9cIwQa2JZcWXuIUYJDmYlEV5104MxQrwpiZVVqUX5 8UWlOanFhxilOViUxHm5GvfHCAmkJ5akZqemFqQWwWSZODilGhiXGP1P9WV5ljMjJPHEr+aX brs571k6L6/mzUlUN7MLdeyf8ck1svEma0LaJReW+z0Z6+f//RbSoDKrZa14BvPRd2uPX7x3 0frJJJlFp/4z+TOU/CiSs+H+xFfkMSvDfcaEzXujVxx71pt3XHllgklpV9OdeS+ZJjm9CJDY zLF16vx15nt1/X8psRRnJBpqMRcVJwIA7Lux3EADAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/htiNuBc0GsTNYLe6xcxu0kKVr9Q>
Subject: Re: [Iasa20] 6635bis
X-BeenThere: iasa20@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions relating to reorganising the IETF administrative structures in the so called “IASA 2.0” project. <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: Fri, 26 Apr 2019 19:55:44 -0000

Some personal observations on this topic/discussion:
- Seems like consensus is consistent with other IASA2 docs - we don't want to over-specify things and value operational flexibility for the LLC. 
- The various people performing RFC-related administrative functions could be contractors, employees, or a mix of the two. 
- It doesn't seem worthwhile to constrain/specify the categories for the people performing the functions (e.g. role X may only be a contractor).
- The LLC is administratively & legally responsible to contract/terminate/hire/fire in this area. Other groups would (obviously) provide input/advice into those decisions but I think on a strictly legal basis those actions seem to fall to the LLC.

I'm not sure how to resolve this. If the WG doesn't want to address all these issues now then perhaps a helpful compromise is to add a section at the end of 6635bis that somehow highlights this as an open issue to be resolved in the future, and that in the meantime the LLC is the responsible legal party and will need to conduct itself accordingly? Dunno...

Thanks
Jason

v2.23.0 | Report a Bug | By Email