From nobody Wed Sep 2 09:11:57 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86071B40C9 for ; Wed, 2 Sep 2015 09:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.74 X-Spam-Level: X-Spam-Status: No, score=0.74 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 CnQxTpe-6G0G for ; Wed, 2 Sep 2015 09:11:52 -0700 (PDT) Received: from delivery2.ufrgs.br (delivery2.ufrgs.br [143.54.2.212]) by ietfa.amsl.com (Postfix) with ESMTP id 68E071B2AB7 for ; Wed, 2 Sep 2015 09:11:52 -0700 (PDT) Received: from delivery2.ufrgs.br (localhost [127.0.0.1]) by delivery2.ufrgs.br (Postfix) with ESMTP id AF4E220A1A4 for ; Wed, 2 Sep 2015 13:11:49 -0300 (BRT) Received: from msa1.ufrgs.br (msa1.ufrgs.br [143.54.2.208]) by delivery2.ufrgs.br (Postfix) with ESMTP id 4F014300824 for ; Wed, 2 Sep 2015 13:11:49 -0300 (BRT) From: Lisandro Zambenedetti Granville Content-Type: multipart/alternative; boundary="Apple-Mail=_B896F8DE-13EE-403D-B09A-E8A6FBB22F66" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Date: Wed, 2 Sep 2015 13:11:46 -0300 References: <133e01d0df7f$a7be94b0$f73bbe10$@rnp.br> To: codematch-develop In-Reply-To: <133e01d0df7f$a7be94b0$f73bbe10$@rnp.br> X-Mailer: Apple Mail (2.2104) X-AV-Checked: ClamAV using ClamSMTP Archived-At: Subject: Re: [Codematch-develop] Suggestion of work distribution X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 16:11:56 -0000 --Apple-Mail=_B896F8DE-13EE-403D-B09A-E8A6FBB22F66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Resending... This is an opportunity for additional developers Best regards, Lisandro > Em 25/08/2015, =C3=A0(s) 18:47, Wanderson Paim = escreveu: >=20 > Hello all, > =20 > In the last meeting we discussed the possibility to split the = development efforts of the CodeMatch project. So, based on the = =E2=80=98Feature Project Plan=E2=80=98, Matheus and I figured out some = candidate features that could be developed in parallel. > =20 > There they go: > =20 > Visitors, Potential Coder, IETFers, Consumers of Code, etc. > 1 - Will be able to view CodeRequests (and matches) by protocol or = working group/IETF area > 2 - Working group views of CodeRequests and Coders (matches) will be = available. > Reputation Scoring of Code > 3 - Will be limited to features of the code repository used by the = coder (ex. Github shows how active a project is, how many followers and = forks have been created) > Incentives/Awards > 4 - Way to show top coders - by volume of projects at first > =20 > =20 > The two first features refers basically to a filter for CodeRequests = (and Matches). There are some sort options in the current prototype = front-end, but it is not functional yet. > =20 > The third, related to the reputation of a project (based in the amount = of forks in GitHub, for example), lacks a bit of clarity. Maybe we can = discuss better in the next meeting. > =20 > The last feature might be easy to develop. It is about creating a = ranking of coders based in the amount of Projects/CodeMatches associated = to them. > =20 > See you tomorrow. > =20 > Best regards, > =20 > Wanderson > =20 > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop --Apple-Mail=_B896F8DE-13EE-403D-B09A-E8A6FBB22F66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Resending... This is an opportunity for additional = developers

Best = regards,

Lisandro
Em = 25/08/2015, =C3=A0(s) 18:47, Wanderson Paim <wanderson.jesus@rnp.br> escreveu:

Hello all,
 
In the last meeting = we discussed the possibility to split the development efforts of the = CodeMatch project. So, based on the =E2=80=98Feature Project Plan=E2=80=98= , Matheus and I figured out some candidate features that could be = developed in parallel.
 
There they go:
 
Visitors, Potential Coder, IETFers, = Consumers of Code, etc.
1 - Will be able to view CodeRequests = (and matches) by protocol or working group/IETF area
2 - Working group views of CodeRequests = and Coders (matches) will be available.
Reputation Scoring of Code
3 - Will be limited to features of the = code repository used by the coder (ex. Github shows how active a project = is, how many followers and forks have been created)
Incentives/Awards
4 - Way to show top coders - by volume = of projects at first
 
 
The two first = features refers basically to a filter for CodeRequests (and Matches). = There are some sort options in the current prototype front-end, but it = is not functional yet.
 
The third, related to the reputation of a = project (based in the amount of forks in GitHub, for example), lacks a = bit of clarity. Maybe we can discuss better in the next meeting.
 
The last feature = might be easy to develop.  It is about creating a ranking of coders = based in the amount of Projects/CodeMatches associated to them.
 
See you = tomorrow.
 
Best regards,
 
Wanderson
 
________________________________= _______________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

= --Apple-Mail=_B896F8DE-13EE-403D-B09A-E8A6FBB22F66-- From nobody Fri Sep 4 06:57:55 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D251B29FC for ; Fri, 4 Sep 2015 06:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 H034aO2lysGM for ; Fri, 4 Sep 2015 06:57:48 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0683.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:683]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6627E1ACD9F for ; Fri, 4 Sep 2015 06:57:48 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=oflaherty@isoc.org; Received: from [10.0.1.13] (167.61.60.74) by BLUPR0601MB771.namprd06.prod.outlook.com (10.141.254.14) with Microsoft SMTP Server (TLS) id 15.1.262.15; Fri, 4 Sep 2015 13:57:41 +0000 MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_868844EC-702F-4215-9802-52A8DF03BE36" From: Christian O'Flaherty In-Reply-To: <9B6DB401-A599-4C19-857C-D64241FC467B@inf.ufrgs.br> Date: Fri, 4 Sep 2015 10:57:36 -0300 Message-ID: References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> <55DE0CB3.8020001@nostrum.com> <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> <55DF0B7B.7020902@levkowetz.com> <9B6DB401-A599-4C19-857C-D64241FC467B@inf.ufrgs.br> To: Henrik Levkowetz X-Mailer: Apple Mail (2.2102) X-Originating-IP: [167.61.60.74] X-ClientProxiedBy: BLUPR01CA045.prod.exchangelabs.com (25.160.23.35) To BLUPR0601MB771.namprd06.prod.outlook.com (10.141.254.14) X-Microsoft-Exchange-Diagnostics: 1; BLUPR0601MB771; 2:cXJwhLTpNVbDX2sBINyRSQh01gANSVUE8SCkJP+lGEJ3gSXKi3TbQEay2EzANGRag05xvf2BIsQht5O3SJ36cosGUbQogH1MwU1TaIYclsKRrdzaPM8e7n3IezclgSpBh8q2DVbbL+a2iWl7AvjDloI5KOGMhWUzh9nwuxOYy8E=; 3:vZhXiTYNmxw9jHz7GWHRB9xvmsGrg2tUtbyApGob2F07+bGZ+3NvgUBjFzj8yNWi+FPsU7mE4UYlmsyLrUm+0QcpErYD2vyhrKlRLOI3xKHwluGKyhx2itZ4Qv2FC0r30o1cvfm3OMa7MxhpG1v5Qg==; 25:VK2Kxbu2/m/vwHFsnoHA/JBCNrL7r9PzdYuw2zNrFoULzdxONfwgq0aP+ZHskXiTaRrq7KLYwWICalXU2VdmkXPCDGUzrw6Xj+PUJLpapKB0W0uy2iS9P0frjZcLmPREJKp+3jZT8JGZ31yKmS8OxIh2/TM+4wl5w7MziMqt7LM/GsbjXoIf09rQxyqDlmqsqHYdX/WrHYglf7e9WPFhO8jC/JhtzRRBi1DTY38624vcaE3YeUaHVMse5AHUPmrZP9nJmWAHKj9xesUB5hBe6g== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0601MB771; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0601MB771; 20:af2JqDZ1IQ1z7amHZfpBfq40w/rFuFItUrFlvKDVQstqxVlmuHbHU3UDFBvfLgI76m3ZciqO9VRrWefU1mmjH5Wvsop+vxXNXrT2vW3O4kqttF69+ug9DOWqQ2og2oNipYnmzIM/CySws68f+Z4Io4G0KXqC3HjRwzFxIme1efy8KFC2LFUird4epc96ic0n4JgXA0GQ9HP5iZPgauAAMA/WO3CCElorgmaohH2OTCxFaaaP+bkQRoJRT/q6GMJ2mmLjuwuI/a0qav5ZwkkwgQqi3uIETh3oS5cj6IzIn4/BbJ6421dqqgmyDGEIumj1HvSdUAk1L+WW90WqSvq+f/QZjIx08HsXV+nKtZ3fJMd0/vbTyz68cYd+JrgVknWsRMCO9oGPT/MCFUBeSVBrXP/UCllzs8AoWyPVIrir959h7s8vCwyX+QeHAuexrKCFDL/p4NlHh/eWvyUcJX5qDw8PK1PqlF8s5+yCd0XSRKPY14wTOpLnoUb4eOgMV2Gc; 4:2eYZayIxyostA38HBazZZihWdjfm0WH3J8NWfD6sHfgLvMdpgGseeLhMfqrLwGL2FcjsbjmeHgzmAeYqkN30oPjlCSVzm1cegViqV9cs8capSxaozEnzGqQx/4g2hmDAFcTagNdvvpMJ3k1VgJT6/HDvZb5apyc7DRp01DgOqdEKNOAFO9hEqKTSgC2M8OtLCp43AD9tgTp09rPXkIhgVXm4+NkGLUVL13gMyEmu80hXQh7xkdFusRaFcvQkFhqGs0IGztkq4hFrY8t8wtwht8FZj/yf+EHorpGYwdMjG0DIhoChkev+YxlmcKKx/9zA X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(8121501046)(3002001); SRVR:BLUPR0601MB771; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0601MB771; X-Forefront-PRVS: 06891E23FB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(479174004)(189002)(69224002)(164054003)(24454002)(199003)(377454003)(377424004)(77096005)(110136002)(5001960100002)(189998001)(5001830100001)(68736005)(87976001)(19617315012)(33656002)(561944003)(15975445007)(83716003)(5001860100001)(77156002)(36756003)(62966003)(81156007)(2950100001)(93886004)(5007970100001)(92566002)(97736004)(42186005)(4001540100001)(5004730100002)(50986999)(106356001)(105586002)(86362001)(76176999)(19580405001)(19580395003)(512874002)(82746002)(101416001)(84326002)(46102003)(69556001)(40100003)(50226001)(122386002)(57306001)(64706001)(66066001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0601MB771; H:[10.0.1.13]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0601MB771; 23:WHYe+rP86F3Xi7cI0k2q3iQKE5n6smlX5/s4lD9m?= =?us-ascii?Q?ruGe+sO5UH86wKPRjB1p3Begl0JkRCdH4BFevHUgnz4EA+U0ijTamtVhX83n?= =?us-ascii?Q?ECMaNMMWRiofZabGdqsk4T86fDY9aUvNNqhqqlrZqIJRB1TaKIctGLAMUD9t?= =?us-ascii?Q?twQMQbWU34cupwkBA3+nCGCP9q9qFvhCzE7HYvEZhqDd1A3rLurXglcqQOY7?= =?us-ascii?Q?a2GaFS/a/OF8T2ryzT2beoBnlCtWduQ8lG5KpvSGKY5mwiKV1u1mTPu8kook?= =?us-ascii?Q?TrZWVVbZoABgU8VJGKw5IeVbPC3hHGwenuSf480zoJKyaDeCCyEE7yO+IgtJ?= =?us-ascii?Q?F9rjvMSUJhEF10t/yBzzsDpm52R2sh/aWSI8MVaz4olvIhwMystKuvyFCG7y?= =?us-ascii?Q?DKC+oHvCplm/CIXjERiqqHzeEiF5SP7q/UPtXxMoDulalp47LL+RozX/GrHJ?= =?us-ascii?Q?QX1tkAUJfEIyhhWhyMveNHPf639tuJlDuABvEcnnUDbqJPpVyhvc2mn2SCxp?= =?us-ascii?Q?jXZOqtwmIhrjYAFROuv7LKD/YkpwlQW+d5k17vL2op/KBorIh6rgyoXPEIxY?= =?us-ascii?Q?armhtRcaQV6trRWYgQdBqazhfiR/wfALsizsX2JUTIqhiXl2t4KklBVNlC8X?= =?us-ascii?Q?FZ9MM1RCQZXePfWNdC4/bBu71Y57X716z7Uf6XavIX5AmsgZonYo1E2SRpJf?= =?us-ascii?Q?ULiPO2uMs4i0fVFsQI9/apLxZfF8IkBXv/R3JcfkNH6GRAh0sBG98fdkDJov?= =?us-ascii?Q?UXeuYosPSiMWCFyXM5/f5OcJJvy8w0xLtBDxLiy2cmD93QgAKGvvor1O5bEi?= =?us-ascii?Q?rGHVMUh/Qe+7AWViCwHehD+ADpcCRjF0KdrIqKX5MiZ3PaLiCS4PHTWplWGy?= =?us-ascii?Q?h1U6kgcy/8fnFy1+wISsIV8GwCIz/JP2+YXe5JnsPHIsXLITdtUreC64VgNz?= =?us-ascii?Q?5ArrwpdycRkXeEVj+hhdUxyuoyACVhAwh5HyaUyhTY6Y2O1/cBIiyidI/oYR?= =?us-ascii?Q?m77m5o7yrBpb5jGDRCY5ekikUHXJKOV8/Er4gZEIOALnG+ZNFJcIUUL568eu?= =?us-ascii?Q?b552hfeDA6BCcCfYuOEjVFFTF1IFziIwwb06cM1hfHOkXaMS9qgrDDis3XX5?= =?us-ascii?Q?uVWqY6d//ozgIbRvJHjFlBo25GhgJ2ynbkLh7pzZKWy/PYfzjyd8o2XSwKbT?= =?us-ascii?Q?mSTj2/yDJCdfe7iMMuIq6J9cHtR4cUts3SoaM9NI2/3wob/KBkMSP7pe/zXP?= =?us-ascii?Q?xjLR3dCGWY0tpc2BrCDsBrWWBDNVj7MKxIgf4XR97961Xej2S5e1grstDlZ3?= =?us-ascii?Q?IGavlNnx5j1Fz8fE+QLCsukxnraM/wB+NVgaxJabdneRF4b93U+PdGG7c6uz?= =?us-ascii?Q?cNilSnUTiTLdJUpEhNOKxQmi1tHdTGXmWc6XWUTjFXnWywOGxGDIZqgdMNkH?= =?us-ascii?Q?tVggSgXUmg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0601MB771; 5:YyIFKYLXkY5NMv0kwX6lDtsH1XMKAHtlkDERWpZd6omhz9OmvW0EMxLwKC64SeQGtxFYiCIjKoNem83id5PabhOq+uZu/Cj2xfzWJTheM1+3t11uyEg+glNMwZ93+6dmSI9ttOC0v4m5R91LnkFMxg==; 24:z7DxhA8xtMOIL5pN4Lb5TH82DYxyn09Zf+8ySEqzTZto2gA/KATRXiChUwUrVuU11UQIpTOz+G0rf05Ztcy6ig03MUCeQMLQsVZOoucEl9E=; 20:X5bwitcC3Bynn07PIuqL3FheOYwL9g0vtxJ3Gi5IVSScY0jW6vci4ov6yF1l6Qfioil5NLOpM+CC6rGXfCiajQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2015 13:57:41.8246 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0601MB771 Archived-At: Cc: Lisandro Zambenedetti Granville , codematch-develop , Robert Sparks Subject: Re: [Codematch-develop] DataTracker and CodeMatch access control X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 13:57:54 -0000 --Apple-Mail=_868844EC-702F-4215-9802-52A8DF03BE36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Henrik, We will follow your advise on permissions and roles.=20 The Datamodel and readability issues (conventions on variable names and = class attributes) were also fixed (those that you flagged when we = started coding). We will need an assessment soon to check what=E2=80=99s missing to be = =E2=80=9Cappropriate=E2=80=9D and what would be the next steps to be = part of a Datatracker release. Can you help us with that?=20 Christian O'Flaherty - oflaherty@isoc.org Regional Development - Internet Society=20 Skype/Gmail/Yahoo!: christian.oflaherty=20 Phone: +598 98769636 > On Aug 27, 2015, at 3:30 PM, Lisandro Zambenedetti Granville = wrote: >=20 > Hello Henrik >=20 > Thanks for all clarifications. Going to the most important question: >=20 > "Could we agree on starting an RBAC implementation using has_role(), = and > once we have a bit more experience, and only then, consider taking on > the added complexity and technical debt of using 2 different = permission > handling systems in this non-COTS software?=E2=80=9D >=20 > Definitely yes. I=E2=80=99m convinced, after reading your arguments, = that having two different permission solutions in the same framework can = be ok for CodeMatch but it wouldn=E2=80=99t be ok for datatracker. An = your suggestion of concentrating now more on who can/cannot do what = should be a priority. >=20 > Best regards, >=20 > Lisandro >=20 >> Em 27/08/2015, =C3=A0(s) 10:07, Henrik Levkowetz = escreveu: >>=20 >> Hi Lisandro, >>=20 >> Jumping in here with some comments: >>=20 >> On 2015-08-26 21:38, Lisandro Zambenedetti Granville wrote: >>> Hello Robert >>>=20 >>>>>> You are not necessarily restricted to the Role names that are >>>>>> defined now (like "chair"). We could add Role names like=20 >>>>>> "codematcher" or "codematch_approver" or whatever other name >>>>>> matches the semantic for the permission you're wanting to >>>>>> manage. >>>>>=20 >>>>> That=E2=80=99s great, so that we can expand the current Roles = without >>>>> changing the data model. >>>>>=20 >>>>>> You could then have things like Lisandro Granville is >>>>>> codematch_approver in nmrg. >>>>>=20 >>>>> That is also what we need. >>>>=20 >>>> Just to be sure - you're saying that's sufficient, and while you're >>>> explaining the idea further below, you don't need it right now? >>>=20 >>> Sorry, I was not clear. Creating new Roles and allowing users being >>> assigned to these new Roles are things that we need in CodeMatch = too. >>> Further below I mention something that we are proposing (i.e., >>> has_right) in addition to having new roles. >>>=20 >>=20 >>>>>> Does that address the need? If not, could you walk me though a >>>>>> scenario where it makes it harder than it should? >>>>>=20 >>>>> What you mention above is the link among users, roles, and >>>>> groups. There is another link between roles and permissions that >>>>> seems to be hardcoded in datatracker. When we say >>>>>=20 >>>>> if has_role(request.user, ["Area Director", "IAB Chair", = "Secretariat=E2=80=9D]): >>>>> // do things the user with "permission X" can do >>>>>=20 >>>>> it implies that if we want to grant to, e.g., >>>>> =E2=80=9Ccodematch_approver=E2=80=9D the =E2=80=9Cpermission X=E2=80= =9D above, we should go back >>>>> to the code and change it to >>>>>=20 >>>>> if has_role(request.user, ["Area Director", "IAB Chair", >>>>> =E2=80=9CSecretariat=E2=80=9D, =E2=80=9Ccodematch_approver"]):... >>>>>=20 >>>>> We were then considering the possibility of moving the link >>>>> between roles and permission to the data model and implement >>>>> has_right (or has_permission) like: >>>>>=20 >>>>> if has_right(request.user, =E2=80=9Cpermission X=E2=80=9D): >>>>> // do things the user with "permission X" can do >>>>>=20 >>>>> If we want =E2=80=9Cpermission X=E2=80=9D to be granted to other = roles, that >>>>> would be a matter of including the proper records in the >>>>> database, instead of changing the code. >>>>>=20 >>>>> Trying not to go too much into details, the summary is that we >>>>> want to check if assigning permission to roles is ok to be done >>>>> in the database, instead of changing the code. >>>>=20 >>>> Well, you still have to type has_right(...) in the code, and >>>> specify something concrete in that has_right that would have to >>>> change, so I don't think we're really talking about avoiding >>>> changing code as much as we are about _where_ you model the idea of >>>> a permission in the database. >>>=20 >>> I agree. We are talking about modeling the link between roles and >>> permission in the database. >>=20 >> So, the design you propose is elegant and matches the way permissions >> are handled in many contexts, especially in COTS software (and for >> that matter, user-configurable FOSS software). >>=20 >> It is more flexible, but also has an added complexity, and an added >> abstraction level (in order to be useful, the permissions need to be >> named with names which express what effect they are having in the = code, >> and this may be non-trivial). >>=20 >> There is however one point you don't bring up, which I would like to >> bring up here. >>=20 >> Summarizing the two ways of writing the code, we can either have code >> which says >>=20 >> if has_role(user, ["CodeMatch Approver"]): >> # code to be exectuted >>=20 >> or code which says >>=20 >> if has_perm(user, ["approve codematch"]): >> # code to be exectuted >>=20 >> For IETF roles, the list of possible roles are very well codified, >> while the only way to know which permissions that need to be named >> and listed in a role_auth_permission table is to go through the >> code and name all the places we check for roles today. Naming those >> permissions, and making clear the correspondence between the names >> and the actual effect they will have in code is not necessarily >> trivial. >>=20 >> For the Codematch project, it may be that you have a much better = grasp >> of the named permissions needed, and not so good a grasp of the = roles. >>=20 >> However, since irrespective of how the correspondence between roles = and >> code is handled, whether it is via has_role() or has_perm(), you = actually >> _need_ to be able to describe the roles well, I would suggest that = you >> probably also have a much better grasp of the roles than of all the >> named permissions which may be needed. >>=20 >> Given that, I would suggest that you start out with the same approach >> which has been used in the current datatracker code, and once it is >> possible to inspect the code and see which actual places need to = check >> for different roles in order to determine if a given piece of code = may >> be executed, _and_ you have experience with the tool so that you can >> speak with confidence about which actions a given role should or = should >> not have, then _at that point_ we can consider refining things into >> roles and permissions, instead of listing roles explicitly in the = code. >>=20 >> More below. >>=20 >>>> I think the real essence of what we're talking about is the >>>> difference in how you would implement "Give all the WG chairs >>>> codematch-approval rights". >>>>=20 >>>> With your proposal, you would make a role to permission match to do >>>> that - one database row change - pretty efficient (*) With what we >>>> have now, you just add a Role of "codematch-approval" to any Person >>>> that has a wg chair role. So, I think what you're proposing is an >>>> optimization, and it comes with some complexity. We can keep >>>> talking about it, but I don't think we're at the point that we need >>>> it. >>>=20 >>> This complexity involves: >>>=20 >>> a) Creating a new intermediate table =E2=80=9Crole_auth_permission" = composed >>> of, at least, two columns: role_id and auth_permission_id; >>>=20 >>> b) Creating the function "has_right (user, permission_label)" which >>> given the user it retrieves the user=E2=80=99s roles, from roles it = retrieves >>> permissions and, among permissions, it checks if permission_label is >>> present. >>>=20 >>> Of course, the effort of doing a) and b) would be ours. And these >>> implementation would be used in CodeMatch only; it wouldn=E2=80=99t = be >>> changing or affecting DataTracker. >>=20 >> Understood. But for the datatracker, there is the added complexity = of >> maintaining code which uses 2 different mechanisms to handle = permissions. >> And that the technical debt of carrying two different solutions = forward >> is something you will not have to suffer, but the datatracker project >> will have to deal with. >>=20 >>>> (*) But, it's not really that easy. Right now we have a role of >>>> "chair" that is applied to all groups. There's no way to speak >>>> differently about WG chairs and RG chairs by simply saying "chair" >>>> - it takes more code. We have chairs of Teams, and _could_ have >>>> (but don't currently) chairs of other SDOs in the database. So, the >>>> apparent simplicity of matching a permission to a role-name isn't >>>> as strong as it first appears. >>>=20 >>> While coding the CodeMatch system, we notice that some portions of >>> the system may be or may be not available to different user roles. >>> Although we define somes roles now, changes on role-permissions will >>> probably happen along the development process. >>=20 >> Agreed. In which case, doing the necessary has_role() or has_perm()=20= >> code changes will most likely happen along with other code changes. >>=20 >>> The permissions we want the roles to have define, let me say, the >>> policy of CodeMatch. We wanted to decouple that policy from the >>> system implementation itself, thus implementing an RBAC model; if = the >>> link between roles and permissions (i.e., the system policy) = migrates >>> to the database, we can tag CodeMatch source code (i.e., define >>> permission labels) and redefine which roles are able to access >>> different parts of the system. Notice, this is just for CodeMatch, = of >>> course. >>=20 >> RBAC can be implemented both with has_role() and has_perm(); the = difference >> lies in how easy it is to reconfigure the permissions which are = associated >> with a given role. >>=20 >> For COTS software, where you cannot easily adapt the code itself to = the >> customer environment and wishes, other than through data lookup, the >> approach you suggest makes a lot of sense. For our case, where there = is >> one and only one production system, it is far less important, and it = is >> not obvious that the added complexity and technical debt incurred is >> offset by the added flexibility. >>=20 >> Please also consider the pace with which we release software for the >> datatracker: Formal releases are shown in the page: >>=20 >> https://datatracker.ietf.org/release/ >>=20 >> and in addition to that, we often apply patches. As an example, we >> have done 10 formal releases within the 6.x.y series, but during the >> same time, we have applied 36 patches, resulting in 20 patch release >> numbers in addition to the formal release numbers. With this release >> pace, and with the possibility of applying patches, we are probably >> agile enough to handle the necessary code changes almost as fast as = you >> could agree on what needs to be done and change the settings in a=20 >> role_auth_permission table. >>=20 >> Could we agree on starting an RBAC implementation using has_role(), = and >> once we have a bit more experience, and only then, consider taking on >> the added complexity and technical debt of using 2 different = permission >> handling systems in this non-COTS software? >>=20 >>=20 >> Best regards, >>=20 >> Henrik >>=20 >>=20 >>> Thanks, >>>=20 >>> Lisandro >>>=20 >>>>> We are of course talking about the CodeMatch code only; we are not = talking about the datatracker code at all, although examples were = inspired by has_role, which is used in datatracker. >>>>>=20 >>>>> Lisandro >>>>>=20 >>>>>> On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote: >>>>>>> Dear All >>>>>>>=20 >>>>>>> Last week we had our traditional CodeMatch meeting. One of the = questions discussed in the meeting was about role-based access control = (RBAC) in CodeMatch. We would like to propose adding an extra table in = the current data model to support RBAC. However, because we want to be = as aligned with DataTracker style as possible, we are sending this = message to start a discussion, specially with Henrik and Robert. >>>>>>>=20 >>>>>>> 1) Style of checking users=E2=80=99 permission >>>>>>>=20 >>>>>>> We observed the DataTracker code and it seems that in general, = permission checking is hardcoded, in the following style (using =E2=80=9CA= rea Director=E2=80=9D, =E2=80=9CIAB Chair=E2=80=9D, and =E2=80=9CSecretari= at" as examples): >>>>>>>=20 >>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", = "Secretariat"]): >>>>>>> // do something that only area diretor, IAB chair, and = secretariat could do, like =E2=80=9CCreate CodeRequest" >>>>>>>=20 >>>>>>>=20 >>>>>>> In CodeMatch, we would like to check permissions in the = following way: >>>>>>>=20 >>>>>>> if has_right(request.user, =E2=80=9CCreate CodeRequest=E2=80=9D): >>>>>>> // do something that only authorized people should be = able to do, like =E2=80=9CCreate CodeRequest=E2=80=9D >>>>>>>=20 >>>>>>> The =E2=80=9Chas_right=E2=80=9D function would check the = database to retrieve the users=E2=80=99 roles and, for each role, check = if it has permission to =E2=80=9CCreate CodeRequest=E2=80=9D. In this = way, permissions are associated to roles, and roles associated to users. >>>>>>>=20 >>>>>>> Because permissions and roles in CodeMatch are being defined = together with the implementation of the system prototype, the use of = =E2=80=9Chas_right=E2=80=9D would allow us to assign permissions to = roles just changing the database, instead of changing the CodeMatch code = if we use =E2=80=9Chas_role=E2=80=9D instead. >>>>>>>=20 >>>>>>> 2) Database >>>>>>>=20 >>>>>>> Today, permissions are listed in table auth_permission. Roles = are listed in table group_role. We would need a intermediate table = linking permissions to roles, i.e., a table linking author_permissions = and group_role. That would allow us to say, for example, that a mentor = (inside group_role) can add documents to a codeRequest (i.e., a = permission inside auth_permission). Adding this intermediate table = (let=E2=80=99s call it role_permission for the moment) would not affect = today=E2=80=99s database, although it would expand today=E2=80=99s data = model. >>>>>>>=20 >>>>>>> Do you think doing that is ok? >>>>>>>=20 >>>>>>> Best regards, >>>>>>>=20 >>>>>>> Lisandro, Wanderson, Matheus >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> Codematch-develop mailing list >>>>>> Codematch-develop@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>>=20 >>>=20 >>>=20 >=20 > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop --Apple-Mail=_868844EC-702F-4215-9802-52A8DF03BE36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Hi Henrik,

We will follow your advise on permissions and = roles. 
The Datamodel and readability issues = (conventions on variable names and class attributes) were also fixed = (those that you flagged when we started coding).

We will need an assessment soon to = check what=E2=80=99s missing to be =E2=80=9Cappropriate=E2=80=9D and = what would be the next steps to be part of a Datatracker = release.

Can = you help us with that? 

Christian = O'Flaherty - oflaherty@isoc.org
Regional Development - Internet Society 
Skype/Gmail/Yahoo!:=  christian.oflaherty 
Phone: +598 = 98769636

On Aug 27, 2015, at 3:30 PM, Lisandro Zambenedetti Granville = <granville@inf.ufrgs.br> wrote:

Hello Henrik

Thanks for all clarifications. Going to the = most important question:

"Could we agree on = starting an RBAC implementation using has_role(), and
once = we have a bit more experience, and only then, consider taking on
the added complexity and technical debt of using 2 different = permission
handling systems in this non-COTS = software?=E2=80=9D

Definitely yes. I=E2=80=99= m convinced, after reading your arguments, that having two different = permission solutions in the same framework can be ok for CodeMatch but = it wouldn=E2=80=99t be ok for datatracker. An your suggestion of = concentrating now more on who can/cannot do what should be a = priority.

Best regards,

Lisandro

Em 27/08/2015, =C3=A0(s) 10:07, Henrik Levkowetz <henrik@levkowetz.com> escreveu:

Hi Lisandro,

Jumping in here = with some comments:

On 2015-08-26 21:38, = Lisandro Zambenedetti Granville wrote:
Hello Robert

You are not necessarily = restricted to the Role names that are
defined now (like = "chair"). We could add Role names like
"codematcher" or = "codematch_approver" or whatever other name
matches the = semantic for the permission you're wanting to
manage.

That=E2=80=99s great, so that we = can expand the current Roles without
changing the data = model.

You could then have things like Lisandro Granville is
codematch_approver in nmrg.

That is also what we need.

Just to be sure - you're saying that's sufficient, and while = you're
explaining the idea further below, you don't need = it right now?

Sorry, I was not = clear. Creating new Roles and allowing users being
assigned = to these new Roles are things that we need in CodeMatch too.
Further below I mention something that we are proposing = (i.e.,
has_right) in addition to having new roles.


Does that = address the need? If not, could you walk me though a
scenario where it makes it harder than it should?

What you mention above is the = link among users, roles, and
groups. There is another link = between roles and permissions that
seems to be hardcoded = in datatracker. When we say

if = has_role(request.user, ["Area Director", "IAB Chair", = "Secretariat=E2=80=9D]):
// do things the user with = "permission X" can do

it implies that if we = want to grant to, e.g.,
=E2=80=9Ccodematch_approver=E2=80=9D= the =E2=80=9Cpermission X=E2=80=9D above, we should go back
to the code and change it to

if = has_role(request.user, ["Area Director", "IAB Chair",
=E2=80=9CSecretariat=E2=80=9D, = =E2=80=9Ccodematch_approver"]):...

We were = then considering the possibility of moving the link
between = roles and permission to the data model and implement
has_right (or has_permission) like:

if has_right(request.user, =E2=80=9Cpermission X=E2=80=9D):
= // do things the user with "permission X" can do

If we want =E2=80=9Cpermission X=E2=80=9D to be granted to = other roles, that
would be a matter of including the = proper records in the
database, instead of changing the = code.

Trying not to go too much into = details, the summary is that we
want to check if assigning = permission to roles is ok to be done
in the database, = instead of changing the code.

Well, you still have to type has_right(...) in the code, = and
specify something concrete in that has_right that = would have to
change, so I don't think we're really = talking about avoiding
changing code as much as we are = about _where_ you model the idea of
a permission in the = database.

I agree. We are = talking about modeling the link between roles and
permission= in the database.

So, the = design you propose is elegant and matches the way permissions
are handled in many contexts, especially in COTS software = (and for
that matter, user-configurable FOSS software).

It is more flexible, but also has an added = complexity, and an added
abstraction level (in order to be = useful, the permissions need to be
named with names which = express what effect they are having in the code,
and this = may be non-trivial).

There is however one = point you don't bring up, which I would like to
bring up = here.

Summarizing the two ways of writing = the code, we can either have code
which says

if has_role(user, ["CodeMatch Approver"]):
   # code to be exectuted

or code which says

if = has_perm(user, ["approve codematch"]):
=    # code to be exectuted

For = IETF roles, the list of possible roles are very well codified,
while the only way to know which permissions that need to be = named
and listed in a role_auth_permission table is to go = through the
code and name all the places we check for = roles today.  Naming those
permissions, and making = clear the correspondence between the names
and the actual = effect they will have in code is not necessarily
trivial.
For the Codematch project, it may be that you = have a much better grasp
of the named permissions needed, = and not so good a grasp of the roles.

However, since irrespective of how the correspondence between = roles and
code is handled, whether it is via has_role() or = has_perm(), you actually
_need_ to be able to describe the = roles well, I would suggest that you
probably also have a = much better grasp of the roles than of all the
named = permissions which may be needed.

Given = that, I would suggest that you start out with the same approach
which has been used in the current datatracker code, and once = it is
possible to inspect the code and see which actual = places need to check
for different roles in order to = determine if a given piece of code may
be executed, _and_ = you have experience with the tool so that you can
speak = with confidence about which actions a given role should or should
not have, then _at that point_ we can consider refining = things into
roles and permissions, instead of listing = roles explicitly in the code.

More = below.

I think the real essence = of what we're talking about is the
difference in how you = would implement "Give all the WG chairs
codematch-approval = rights".

With your proposal, you would make = a role to permission match to do
that - one database row = change - pretty efficient (*) With what we
have now, you = just add a Role of "codematch-approval" to any Person
that = has a wg chair role. So, I think what you're proposing is an
optimization, and it comes with some complexity. We can = keep
talking about it, but I don't think we're at the = point that we need
it.

This complexity involves:

a) = Creating a new intermediate table =E2=80=9Crole_auth_permission" = composed
of, at least, two columns: role_id and = auth_permission_id;

b) Creating the = function "has_right (user, permission_label)" which
given = the user it retrieves the user=E2=80=99s roles, from roles it = retrieves
permissions and, among permissions, it checks if = permission_label is
present.

Of= course, the effort of doing a) and b) would be ours. And these
implementation would be used in CodeMatch only; it wouldn=E2=80= =99t be
changing or affecting DataTracker.

Understood.  But for the = datatracker, there is the added complexity of
maintaining = code which uses 2 different mechanisms to handle permissions.
And that the technical debt of carrying two different = solutions forward
is something you will not have to = suffer, but the datatracker project
will have to deal = with.

(*) But, it's not really = that easy. Right now we have a role of
"chair" that is = applied to all groups. There's no way to speak
differently = about WG chairs and RG chairs by simply saying "chair"
- = it takes more code. We have chairs of Teams, and _could_ have
(but don't currently) chairs of other SDOs in the database. = So, the
apparent simplicity of matching a permission to a = role-name isn't
as strong as it first appears.

While coding the CodeMatch = system, we notice that some portions of
the system may be = or may be not available to different user roles.
Although = we define somes roles now, changes on role-permissions will
probably happen along the development process.

Agreed.  In which case, = doing the necessary has_role() or has_perm()
code changes = will most likely happen along with other code changes.

The permissions we want = the roles to have define, let me say, the
policy of = CodeMatch. We wanted to decouple that policy from the
system= implementation itself, thus implementing an RBAC model; if the
link between roles and permissions (i.e., the system policy) = migrates
to the database, we can tag CodeMatch source code = (i.e., define
permission labels) and redefine which roles = are able to access
different parts of the system. Notice, = this is just for CodeMatch, of
course.

RBAC can be implemented both with = has_role() and has_perm(); the difference
lies in how easy = it is to reconfigure the permissions which are associated
with a given role.

For COTS = software, where you cannot easily adapt the code itself to the
customer environment and wishes, other than through data = lookup, the
approach you suggest makes a lot of sense. =  For our case, where there is
one and only one = production system, it is far less important, and it is
not = obvious that the added complexity and technical debt incurred is
offset by the added flexibility.

Please also consider the pace with which we release software = for the
datatracker:  Formal releases are shown in = the page:

 https://datatracker.ietf.org/release/

and in addition to that, we often apply patches.  As an = example, we
have done 10 formal releases within the 6.x.y = series, but during the
same time, we have applied 36 = patches, resulting in 20 patch release
numbers in addition = to the formal release numbers.  With this release
pace,= and with the possibility of applying patches,  we are probably
agile enough to handle the necessary code changes almost as = fast as you
could agree on what needs to be done and = change the settings in a
role_auth_permission table.

Could we agree on starting an RBAC = implementation using has_role(), and
once we have a bit = more experience, and only then, consider taking on
the = added complexity and technical debt of using 2 different permission
handling systems in this non-COTS software?


Best regards,

Henrik


Thanks,

Lisandro
We are of course talking about the CodeMatch code only; we = are not talking about the datatracker code at all, although examples = were inspired by has_role, which is used in datatracker.
Lisandro

On 8/25/15 1:52 PM, Lisandro Zambenedetti = Granville wrote:
Dear = All

Last week we had our traditional = CodeMatch meeting. One of the questions discussed in the meeting was = about role-based access control (RBAC) in CodeMatch. We would like to = propose adding an extra table in the current data model to support RBAC. = However, because we want to be as aligned with DataTracker style as = possible, we are sending this message to start a discussion, specially = with Henrik and Robert.

1) Style of = checking users=E2=80=99 permission

We = observed the DataTracker code and it seems that in general, permission = checking is hardcoded, in the following style (using =E2=80=9CArea = Director=E2=80=9D, =E2=80=9CIAB Chair=E2=80=9D, and =E2=80=9CSecretariat" = as examples):

if has_role(request.user, = ["Area Director", "IAB Chair", "Secretariat"]):
// do = something that only area diretor, IAB chair, and secretariat could do, = like =E2=80=9CCreate CodeRequest"


In CodeMatch, we would like to check permissions in the = following way:

if has_right(request.user, = =E2=80=9CCreate CodeRequest=E2=80=9D):
// do = something that only authorized people should be able to do, like = =E2=80=9CCreate CodeRequest=E2=80=9D

The = =E2=80=9Chas_right=E2=80=9D function would check the database to = retrieve the users=E2=80=99 roles and, for each role, check if it has = permission to =E2=80=9CCreate CodeRequest=E2=80=9D. In this way, = permissions are associated to roles, and roles associated to users.

Because permissions and roles in CodeMatch are = being defined together with the implementation of the system prototype, = the use of =E2=80=9Chas_right=E2=80=9D would allow us to assign = permissions to roles just changing the database, instead of changing the = CodeMatch code if we use =E2=80=9Chas_role=E2=80=9D instead.

2) Database

Today, = permissions are listed in table auth_permission. Roles are listed in = table group_role. We would need a intermediate table linking permissions = to roles, i.e., a table linking author_permissions and group_role. That = would allow us to say, for example, that a mentor (inside group_role) = can add documents to a codeRequest (i.e., a permission inside = auth_permission). Adding this intermediate table (let=E2=80=99s call it = role_permission for the moment) would not affect today=E2=80=99s = database, although it would expand today=E2=80=99s data model.

Do you think doing that is ok?
Best regards,

Lisandro, = Wanderson, Matheus

_______________________________________________Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

= --Apple-Mail=_868844EC-702F-4215-9802-52A8DF03BE36-- From nobody Tue Sep 15 15:07:32 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 929FC1B2A77 for ; Tue, 15 Sep 2015 15:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 o7WRE1XhT0q5 for ; Tue, 15 Sep 2015 15:07:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0680.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:680]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1CF41B2BAC for ; Tue, 15 Sep 2015 15:07:24 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=oflaherty@isoc.org; Received: from [10.0.1.13] (167.61.89.181) by BLUPR0601MB770.namprd06.prod.outlook.com (10.141.254.139) with Microsoft SMTP Server (TLS) id 15.1.268.17; Tue, 15 Sep 2015 22:07:01 +0000 MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_9A54C364-DD09-4B3F-BADC-589BF51F23BE" From: Christian O'Flaherty In-Reply-To: Date: Tue, 15 Sep 2015 19:06:53 -0300 Message-ID: References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> <55DE0CB3.8020001@nostrum.com> <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> <55DF0B7B.7020902@levkowetz.com> <9B6DB401-A599-4C19-857C-D64241FC467B@inf.ufrgs.br> To: Henrik Levkowetz X-Mailer: Apple Mail (2.2104) X-Originating-IP: [167.61.89.181] X-ClientProxiedBy: CY1PR20CA0089.namprd20.prod.outlook.com (25.164.213.143) To BLUPR0601MB770.namprd06.prod.outlook.com (10.141.254.139) X-Microsoft-Exchange-Diagnostics: 1; BLUPR0601MB770; 2:zPsanrwIICiCiG0zn7y41o4sTHsuHZ48FsX5S9HohXfjSnYdwg6L8/s72yeVzqsjAE7gwNfk8ljC6wlxvxjp5BtnGz5ndSj2KrWYqTCO4WA8E9gN3ZHlPuEc8WccUeBrW7uqfCtBeoKymkiqnSZ0noXed5CsjLm6mEDFm8KK6zw=; 3:xZSFLMlOko0shQRQxgV4AOa6B1q4ZCwZk9W1zzUjfRZgp3sGUjO+154Tc1zZuykbEyw4AlYOrK6zknY6zLO7+uZ4CPUeBW2JNsYItprf04YhSCTeJpDq9UrVC6BEXQWHZfAeT+whTideR5jskc6MOQ==; 25:ykYiJpjN+HshhhEZdbfP7wP0ybDV/uN7hsOXjrq3NGw6AWLW7UtZsdyBoa2pxsu843NTZvVDrn57rU4ECmXSM8OohDDgkrYrkSA2J0XGfeAfDqD/VaesvaaBR8OaJj8azCBFNcbsr1abK3roldLms+miI1uBH+4GjHu4eAeKp2Cz3Fk86ZhDcSHDMPrFfOdtnBFabwGpUH9JZt+zvOjiB77UZR1/tTCyuWnQkQVlne9nxoh13kMpdbDNRhSdqZHpcCJ5rGPl4K/fd0hpvYcYbg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0601MB770; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0601MB770; 20:g602TL/1MsLh9Z57FXFInZwGSdd5Aa0aBRYt6SBLmzJplveQkurt4ofxvyyU7cGMLsh+gsUQnbcSnu88L9y/Yr1Bj8UqzHUI+P1csp9JXftVlJtyZhqkYRO3sltZUbJnUmtAKAVDcnpDS+nEbbLidw+3qdWY3iXnj5NgsnNk8FLOWFkMhKMuUwHXyT0zb+Fx5cSNQ2uks1kPdK25vmFP8MvV3gd6gONAxkFcp4q85O0Usjb+qevnguuZBi3cTl0NYkdM7mNcStO0H5d1QCRp7z1onafNr+eSiY6S84F+3FCXbpMJRf5x/2BykGtSzhhroWvZtION5Dvhx8bKRCjW54NgHwwrRc2W+bmFuPHm9JgpENHXtfxPhGiI+FYjXDI0jV/U3lXlh0veWHmK91uKakf6LBLdeKIDGzDbLI9i4JGkVLg6+5ghGaIEK0ze5BL0101SMw1tbkv1xu2f1B6AuhBDpdxeYRQZxKDhZyt1iUytx6qExO+ypVaYVcv2IGkO; 4:OoxYTS3BoMNzAjlWzxNAsqMG9d6PSS5QPYS34r30vx4hZKJLvMOS+cExy/0PhM6ts+sMxvXw6Y1z+FXp5YfJmPmgDc5jACqinLisWYeYOjd51lsZnOQ46OyIvEmT5D3VWa7M7NuZiCVpmb+yfvf6oStsnm7mZnnw8cySsSPt/eRAYStNdNaymao8HQsWBirb1woVTLKXAEdhcZzerWtxxC9a1Y47l4htrHsMi0l2IYI7/jAYDffxgZKwS7O9MlWZFBN9aVS4qGd4GU00EaipYj5aEWsm8rURHROjR4X04iyHZPt9rzljfGMyWpTtapQvrtx0fVQss/mxl4Gkjxt+5I0+afgaomW0coFkJb34nfw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(520075)(520078)(3002001); SRVR:BLUPR0601MB770; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0601MB770; X-Forefront-PRVS: 070092A9D3 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(24454002)(189002)(377454003)(479174004)(199003)(377424004)(69224002)(164054003)(87976001)(82746002)(561944003)(101416001)(15975445007)(46102003)(50986999)(77096005)(5001860100001)(64706001)(2950100001)(84326002)(105586002)(33656002)(69556001)(66066001)(50226001)(512874002)(83716003)(42186005)(106356001)(76176999)(81156007)(122386002)(68736005)(19580405001)(92566002)(110136002)(93886004)(19580395003)(86362001)(62966003)(189998001)(40100003)(5004730100002)(4001540100001)(77156002)(36756003)(5001960100002)(57306001)(97736004)(5001830100001)(19617315012)(5007970100001)(104396002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0601MB770; H:[10.0.1.13]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0601MB770; 23:Vt0TEWQe0Kct9Ug4Ppb+iQEqgtkou/T0VV90UyXB?= =?us-ascii?Q?QXF0rjDQLMXS7ZVmQOJw+GMcsIC3cryFgHV2Gh8MquhtrnVnymHD21Hq4B9P?= =?us-ascii?Q?/YGhJwXYMSHjhhpqWGywDpItJYLx7VoIjHE1dOjUdD/6xyQ1FI9EKrBZC+zr?= =?us-ascii?Q?38naC+UnJldnKa2v73g5UQSBPdKFLVvx30valgtyoI3jAqhWRIravJ//qaWZ?= =?us-ascii?Q?VC6qstGHYVKDgZ/JHZ0ZhbLEjviProbA5clWa88G5oLr3N8fN/HyUs9QF7vz?= =?us-ascii?Q?3L95ByuYlO0SJHEDd/PM0KIdAhEENNq0m6wmiBjrnrqc5NY7AcviOf65AVmu?= =?us-ascii?Q?Bb++oWL5bCk4bGSsiq1d6OU75qQzNQXY6IqV70iRJqaVOZVSK3qP6agKnNd2?= =?us-ascii?Q?EBBLNF2WO0/eENitiXGSI8gB8pvF5TK+jk+IZrRMtxf1BHjKqk82viutx5t1?= =?us-ascii?Q?9g/AmCtOP3cNbIy7lf8QGnOEYSNl4FypViCyh2bI+Jjqs6gA/JJNI+1gNVUz?= =?us-ascii?Q?ebZAF5eiPvC8tCGkXHTVudDlWnN3wLSQ4+5fKI3omhAocaixJJ1jUhplJkPc?= =?us-ascii?Q?5AHRaqTChyeFynGTfFG5KiR19CWoJD6GBJAIXS4yTH/USMGo8Z9U1r3vfdIn?= =?us-ascii?Q?DxNatIkrYBkq2ummTQiJaNgqmFB++zQNZaWTg4iC8y8SE2Q4Zd1P5WzUoPc4?= =?us-ascii?Q?PL6Z0FXDt3+Bd2ls4rUEd1vFiebYse3i1l/eqXdu0RxV5zgBsqFyNsRvAh9O?= =?us-ascii?Q?72WcW238dMUZRN8KNA/vn3hxKBxWh2AU3QXfb1wnR15DswYoDbPQc/0xM1gy?= =?us-ascii?Q?Lp91wUR0TuVpTlXlJNzeoi20mymrTW5A5g3Fv9yTb7dLEQJ7EsuotklR8gTA?= =?us-ascii?Q?lHv8ftLHoywRsOAlHCQaH4pvyPFNPNA9o7jhcYGjTqm6I1SsfTqFkd6xW4fI?= =?us-ascii?Q?+ymwoPR/zLGrNHb4U7koQUloKn711U31G5MKXLQGHQ+0pK1YLJa6ILenaswX?= =?us-ascii?Q?fnh+q+uJR9DJRX8rtCQySSPHxFrvyN1QMYUB7mEdA5zEkNvgXLl5TKpmuOVD?= =?us-ascii?Q?aCG3s7q4KiO+GerzZPynBYDRm0DI3EgYnGtuz9cpod5eKv1yX7+/bjSLsfBL?= =?us-ascii?Q?fgF99TozOVnvVVoW3zwYd/hfd3Y+B4AFKMH4IGaPJ4w2fCESZusee9OyGzjp?= =?us-ascii?Q?PIj5039mieikXeZuiCAJd9QtuZQoVXZGeFfHLe+dZkxIEO6z1iep9nKIiEKR?= =?us-ascii?Q?Zy8LdpAkhMaSIr0x/WlJVKsTkTVCTRzvzhGkEq3UkI+T7fBOk7iwADme5fcG?= =?us-ascii?Q?81dKtEuBLJsp4jxcHm1wkuc5edwWoFZYIo4lrMmnZZ0IxUU7QnVV1XHbDSRa?= =?us-ascii?Q?W9zIbn5GKoQ9aJ/kRBuND7nhjDHFiU91aY5ddNm28dGtKDsO2QGWMcndJ266?= =?us-ascii?Q?/prchZeM+B9aitHvRuWKAQvNQXGOcLo=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0601MB770; 5:0GuWKxJHKYMuIcxXVcgtceJ6DXAtmJpD5OmZ8T0OGzcW94fbuLKGKJNYUIM5w48S456L/KdSAaDqaZMuZ5xpr1tjx76XITfaPrguJSHB/9qrvl0OVhdpMIeE1QRyLCXKJg173my6gwUPcYPdhluX0A==; 24:LqGO9TcuqbfRpY3vK6r+4vvgU2E3/DMc4olqzrRWK1KNB1Fu4+inheJJRIOoimdPtYeLU4QHH19Qkd7yGj0lq+ztAKDrn7VNBOixtgER+m4=; 20:j+HIh/ILlYxj5AV1rnHVUmqMzXmtx8WTlClq6jObehl1QhDpNzMiKG1h7533a2c3Plm/N/8kJxDwhyHcvzC+KA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2015 22:07:01.8631 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0601MB770 Archived-At: Cc: Lisandro Zambenedetti Granville , codematch-develop , Robert Sparks Subject: Re: [Codematch-develop] DataTracker and CodeMatch access control X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 22:07:31 -0000 --Apple-Mail=_9A54C364-DD09-4B3F-BADC-589BF51F23BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" H Henrik,=20 I don=E2=80=99t want to be pushy but we will have our codematch call = tomorrow and we would like to discuss this part: > We will need an assessment soon to check what=E2=80=99s missing to be = =E2=80=9Cappropriate=E2=80=9D and what would be the next steps to be = part of a Datatracker release. Can you help us or join our call tomorrow at 16 UTC ? Thanks, Christian O'Flaherty - oflaherty@isoc.org Regional Development - Internet Society=20 Skype/Gmail/Yahoo!: christian.oflaherty=20 Phone: +598 98769636 > On Sep 4, 2015, at 10:57 AM, Christian O'Flaherty = wrote: >=20 > Hi Henrik, >=20 > We will follow your advise on permissions and roles.=20 > The Datamodel and readability issues (conventions on variable names = and class attributes) were also fixed (those that you flagged when we = started coding). >=20 > We will need an assessment soon to check what=E2=80=99s missing to be = =E2=80=9Cappropriate=E2=80=9D and what would be the next steps to be = part of a Datatracker release. >=20 > Can you help us with that?=20 >=20 > Christian O'Flaherty - oflaherty@isoc.org > Regional Development - Internet Society=20 > Skype/Gmail/Yahoo!: christian.oflaherty=20 > Phone: +598 98769636 >=20 >> On Aug 27, 2015, at 3:30 PM, Lisandro Zambenedetti Granville = > wrote: >>=20 >> Hello Henrik >>=20 >> Thanks for all clarifications. Going to the most important question: >>=20 >> "Could we agree on starting an RBAC implementation using has_role(), = and >> once we have a bit more experience, and only then, consider taking on >> the added complexity and technical debt of using 2 different = permission >> handling systems in this non-COTS software?=E2=80=9D >>=20 >> Definitely yes. I=E2=80=99m convinced, after reading your arguments, = that having two different permission solutions in the same framework can = be ok for CodeMatch but it wouldn=E2=80=99t be ok for datatracker. An = your suggestion of concentrating now more on who can/cannot do what = should be a priority. >>=20 >> Best regards, >>=20 >> Lisandro >>=20 >>> Em 27/08/2015, =C3=A0(s) 10:07, Henrik Levkowetz = > escreveu: >>>=20 >>> Hi Lisandro, >>>=20 >>> Jumping in here with some comments: >>>=20 >>> On 2015-08-26 21:38, Lisandro Zambenedetti Granville wrote: >>>> Hello Robert >>>>=20 >>>>>>> You are not necessarily restricted to the Role names that are >>>>>>> defined now (like "chair"). We could add Role names like=20 >>>>>>> "codematcher" or "codematch_approver" or whatever other name >>>>>>> matches the semantic for the permission you're wanting to >>>>>>> manage. >>>>>>=20 >>>>>> That=E2=80=99s great, so that we can expand the current Roles = without >>>>>> changing the data model. >>>>>>=20 >>>>>>> You could then have things like Lisandro Granville is >>>>>>> codematch_approver in nmrg. >>>>>>=20 >>>>>> That is also what we need. >>>>>=20 >>>>> Just to be sure - you're saying that's sufficient, and while = you're >>>>> explaining the idea further below, you don't need it right now? >>>>=20 >>>> Sorry, I was not clear. Creating new Roles and allowing users being >>>> assigned to these new Roles are things that we need in CodeMatch = too. >>>> Further below I mention something that we are proposing (i.e., >>>> has_right) in addition to having new roles. >>>>=20 >>>=20 >>>>>>> Does that address the need? If not, could you walk me though a >>>>>>> scenario where it makes it harder than it should? >>>>>>=20 >>>>>> What you mention above is the link among users, roles, and >>>>>> groups. There is another link between roles and permissions that >>>>>> seems to be hardcoded in datatracker. When we say >>>>>>=20 >>>>>> if has_role(request.user, ["Area Director", "IAB Chair", = "Secretariat=E2=80=9D]): >>>>>> // do things the user with "permission X" can do >>>>>>=20 >>>>>> it implies that if we want to grant to, e.g., >>>>>> =E2=80=9Ccodematch_approver=E2=80=9D the =E2=80=9Cpermission X=E2=80= =9D above, we should go back >>>>>> to the code and change it to >>>>>>=20 >>>>>> if has_role(request.user, ["Area Director", "IAB Chair", >>>>>> =E2=80=9CSecretariat=E2=80=9D, =E2=80=9Ccodematch_approver"]):... >>>>>>=20 >>>>>> We were then considering the possibility of moving the link >>>>>> between roles and permission to the data model and implement >>>>>> has_right (or has_permission) like: >>>>>>=20 >>>>>> if has_right(request.user, =E2=80=9Cpermission X=E2=80=9D): >>>>>> // do things the user with "permission X" can do >>>>>>=20 >>>>>> If we want =E2=80=9Cpermission X=E2=80=9D to be granted to other = roles, that >>>>>> would be a matter of including the proper records in the >>>>>> database, instead of changing the code. >>>>>>=20 >>>>>> Trying not to go too much into details, the summary is that we >>>>>> want to check if assigning permission to roles is ok to be done >>>>>> in the database, instead of changing the code. >>>>>=20 >>>>> Well, you still have to type has_right(...) in the code, and >>>>> specify something concrete in that has_right that would have to >>>>> change, so I don't think we're really talking about avoiding >>>>> changing code as much as we are about _where_ you model the idea = of >>>>> a permission in the database. >>>>=20 >>>> I agree. We are talking about modeling the link between roles and >>>> permission in the database. >>>=20 >>> So, the design you propose is elegant and matches the way = permissions >>> are handled in many contexts, especially in COTS software (and for >>> that matter, user-configurable FOSS software). >>>=20 >>> It is more flexible, but also has an added complexity, and an added >>> abstraction level (in order to be useful, the permissions need to be >>> named with names which express what effect they are having in the = code, >>> and this may be non-trivial). >>>=20 >>> There is however one point you don't bring up, which I would like to >>> bring up here. >>>=20 >>> Summarizing the two ways of writing the code, we can either have = code >>> which says >>>=20 >>> if has_role(user, ["CodeMatch Approver"]): >>> # code to be exectuted >>>=20 >>> or code which says >>>=20 >>> if has_perm(user, ["approve codematch"]): >>> # code to be exectuted >>>=20 >>> For IETF roles, the list of possible roles are very well codified, >>> while the only way to know which permissions that need to be named >>> and listed in a role_auth_permission table is to go through the >>> code and name all the places we check for roles today. Naming those >>> permissions, and making clear the correspondence between the names >>> and the actual effect they will have in code is not necessarily >>> trivial. >>>=20 >>> For the Codematch project, it may be that you have a much better = grasp >>> of the named permissions needed, and not so good a grasp of the = roles. >>>=20 >>> However, since irrespective of how the correspondence between roles = and >>> code is handled, whether it is via has_role() or has_perm(), you = actually >>> _need_ to be able to describe the roles well, I would suggest that = you >>> probably also have a much better grasp of the roles than of all the >>> named permissions which may be needed. >>>=20 >>> Given that, I would suggest that you start out with the same = approach >>> which has been used in the current datatracker code, and once it is >>> possible to inspect the code and see which actual places need to = check >>> for different roles in order to determine if a given piece of code = may >>> be executed, _and_ you have experience with the tool so that you can >>> speak with confidence about which actions a given role should or = should >>> not have, then _at that point_ we can consider refining things into >>> roles and permissions, instead of listing roles explicitly in the = code. >>>=20 >>> More below. >>>=20 >>>>> I think the real essence of what we're talking about is the >>>>> difference in how you would implement "Give all the WG chairs >>>>> codematch-approval rights". >>>>>=20 >>>>> With your proposal, you would make a role to permission match to = do >>>>> that - one database row change - pretty efficient (*) With what we >>>>> have now, you just add a Role of "codematch-approval" to any = Person >>>>> that has a wg chair role. So, I think what you're proposing is an >>>>> optimization, and it comes with some complexity. We can keep >>>>> talking about it, but I don't think we're at the point that we = need >>>>> it. >>>>=20 >>>> This complexity involves: >>>>=20 >>>> a) Creating a new intermediate table =E2=80=9Crole_auth_permission" = composed >>>> of, at least, two columns: role_id and auth_permission_id; >>>>=20 >>>> b) Creating the function "has_right (user, permission_label)" which >>>> given the user it retrieves the user=E2=80=99s roles, from roles it = retrieves >>>> permissions and, among permissions, it checks if permission_label = is >>>> present. >>>>=20 >>>> Of course, the effort of doing a) and b) would be ours. And these >>>> implementation would be used in CodeMatch only; it wouldn=E2=80=99t = be >>>> changing or affecting DataTracker. >>>=20 >>> Understood. But for the datatracker, there is the added complexity = of >>> maintaining code which uses 2 different mechanisms to handle = permissions. >>> And that the technical debt of carrying two different solutions = forward >>> is something you will not have to suffer, but the datatracker = project >>> will have to deal with. >>>=20 >>>>> (*) But, it's not really that easy. Right now we have a role of >>>>> "chair" that is applied to all groups. There's no way to speak >>>>> differently about WG chairs and RG chairs by simply saying "chair" >>>>> - it takes more code. We have chairs of Teams, and _could_ have >>>>> (but don't currently) chairs of other SDOs in the database. So, = the >>>>> apparent simplicity of matching a permission to a role-name isn't >>>>> as strong as it first appears. >>>>=20 >>>> While coding the CodeMatch system, we notice that some portions of >>>> the system may be or may be not available to different user roles. >>>> Although we define somes roles now, changes on role-permissions = will >>>> probably happen along the development process. >>>=20 >>> Agreed. In which case, doing the necessary has_role() or has_perm()=20= >>> code changes will most likely happen along with other code changes. >>>=20 >>>> The permissions we want the roles to have define, let me say, the >>>> policy of CodeMatch. We wanted to decouple that policy from the >>>> system implementation itself, thus implementing an RBAC model; if = the >>>> link between roles and permissions (i.e., the system policy) = migrates >>>> to the database, we can tag CodeMatch source code (i.e., define >>>> permission labels) and redefine which roles are able to access >>>> different parts of the system. Notice, this is just for CodeMatch, = of >>>> course. >>>=20 >>> RBAC can be implemented both with has_role() and has_perm(); the = difference >>> lies in how easy it is to reconfigure the permissions which are = associated >>> with a given role. >>>=20 >>> For COTS software, where you cannot easily adapt the code itself to = the >>> customer environment and wishes, other than through data lookup, the >>> approach you suggest makes a lot of sense. For our case, where = there is >>> one and only one production system, it is far less important, and it = is >>> not obvious that the added complexity and technical debt incurred is >>> offset by the added flexibility. >>>=20 >>> Please also consider the pace with which we release software for the >>> datatracker: Formal releases are shown in the page: >>>=20 >>> https://datatracker.ietf.org/release/ = >>>=20 >>> and in addition to that, we often apply patches. As an example, we >>> have done 10 formal releases within the 6.x.y series, but during the >>> same time, we have applied 36 patches, resulting in 20 patch release >>> numbers in addition to the formal release numbers. With this = release >>> pace, and with the possibility of applying patches, we are probably >>> agile enough to handle the necessary code changes almost as fast as = you >>> could agree on what needs to be done and change the settings in a=20 >>> role_auth_permission table. >>>=20 >>> Could we agree on starting an RBAC implementation using has_role(), = and >>> once we have a bit more experience, and only then, consider taking = on >>> the added complexity and technical debt of using 2 different = permission >>> handling systems in this non-COTS software? >>>=20 >>>=20 >>> Best regards, >>>=20 >>> Henrik >>>=20 >>>=20 >>>> Thanks, >>>>=20 >>>> Lisandro >>>>=20 >>>>>> We are of course talking about the CodeMatch code only; we are = not talking about the datatracker code at all, although examples were = inspired by has_role, which is used in datatracker. >>>>>>=20 >>>>>> Lisandro >>>>>>=20 >>>>>>> On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote: >>>>>>>> Dear All >>>>>>>>=20 >>>>>>>> Last week we had our traditional CodeMatch meeting. One of the = questions discussed in the meeting was about role-based access control = (RBAC) in CodeMatch. We would like to propose adding an extra table in = the current data model to support RBAC. However, because we want to be = as aligned with DataTracker style as possible, we are sending this = message to start a discussion, specially with Henrik and Robert. >>>>>>>>=20 >>>>>>>> 1) Style of checking users=E2=80=99 permission >>>>>>>>=20 >>>>>>>> We observed the DataTracker code and it seems that in general, = permission checking is hardcoded, in the following style (using =E2=80=9CA= rea Director=E2=80=9D, =E2=80=9CIAB Chair=E2=80=9D, and =E2=80=9CSecretari= at" as examples): >>>>>>>>=20 >>>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", = "Secretariat"]): >>>>>>>> // do something that only area diretor, IAB chair, and = secretariat could do, like =E2=80=9CCreate CodeRequest" >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> In CodeMatch, we would like to check permissions in the = following way: >>>>>>>>=20 >>>>>>>> if has_right(request.user, =E2=80=9CCreate CodeRequest=E2=80=9D):= >>>>>>>> // do something that only authorized people should be = able to do, like =E2=80=9CCreate CodeRequest=E2=80=9D >>>>>>>>=20 >>>>>>>> The =E2=80=9Chas_right=E2=80=9D function would check the = database to retrieve the users=E2=80=99 roles and, for each role, check = if it has permission to =E2=80=9CCreate CodeRequest=E2=80=9D. In this = way, permissions are associated to roles, and roles associated to users. >>>>>>>>=20 >>>>>>>> Because permissions and roles in CodeMatch are being defined = together with the implementation of the system prototype, the use of = =E2=80=9Chas_right=E2=80=9D would allow us to assign permissions to = roles just changing the database, instead of changing the CodeMatch code = if we use =E2=80=9Chas_role=E2=80=9D instead. >>>>>>>>=20 >>>>>>>> 2) Database >>>>>>>>=20 >>>>>>>> Today, permissions are listed in table auth_permission. Roles = are listed in table group_role. We would need a intermediate table = linking permissions to roles, i.e., a table linking author_permissions = and group_role. That would allow us to say, for example, that a mentor = (inside group_role) can add documents to a codeRequest (i.e., a = permission inside auth_permission). Adding this intermediate table = (let=E2=80=99s call it role_permission for the moment) would not affect = today=E2=80=99s database, although it would expand today=E2=80=99s data = model. >>>>>>>>=20 >>>>>>>> Do you think doing that is ok? >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Lisandro, Wanderson, Matheus >>>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Codematch-develop mailing list >>>>>>> Codematch-develop@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>>>=20 >>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> Codematch-develop mailing list >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop >=20 --Apple-Mail=_9A54C364-DD09-4B3F-BADC-589BF51F23BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" H Henrik, 

I don=E2=80=99t want to be pushy but we will have our = codematch call tomorrow and we would like to discuss this = part:

We will need an = assessment soon to check what=E2=80=99s missing to be =E2=80=9Cappropriate= =E2=80=9D and what would be the next steps to be part of a Datatracker = release.

Can you help us or join our = call tomorrow at 16 UTC ?

Thanks,

Christian = O'Flaherty - oflaherty@isoc.org
Regional Development - Internet Society 
Skype/Gmail/Yahoo!:=  christian.oflaherty 
Phone: +598 = 98769636

On Sep 4, 2015, at 10:57 AM, Christian O'Flaherty <oflaherty@isoc.org> = wrote:

Hi Henrik,

We will follow your = advise on permissions and roles. 
The = Datamodel and readability issues (conventions on variable names and = class attributes) were also fixed (those that you flagged when we = started coding).

We will need an assessment soon to check what=E2=80=99s = missing to be =E2=80=9Cappropriate=E2=80=9D and what would be the next = steps to be part of a Datatracker release.

Can you help us with = that? 

Christian = O'Flaherty - oflaherty@isoc.org
Regional Development - Internet Society 
Skype/Gmail/Yahoo!:=  christian.oflaherty 
Phone: +598 = 98769636

On Aug 27, 2015, at 3:30 PM, Lisandro Zambenedetti Granville = <granville@inf.ufrgs.br> wrote:

Hello Henrik

Thanks for all clarifications. Going to the = most important question:

"Could we agree on = starting an RBAC implementation using has_role(), and
once = we have a bit more experience, and only then, consider taking on
the added complexity and technical debt of using 2 different = permission
handling systems in this non-COTS = software?=E2=80=9D

Definitely yes. I=E2=80=99= m convinced, after reading your arguments, that having two different = permission solutions in the same framework can be ok for CodeMatch but = it wouldn=E2=80=99t be ok for datatracker. An your suggestion of = concentrating now more on who can/cannot do what should be a = priority.

Best regards,

Lisandro

Em 27/08/2015, =C3=A0(s) 10:07, Henrik Levkowetz <henrik@levkowetz.com> escreveu:

Hi Lisandro,

Jumping in here = with some comments:

On 2015-08-26 21:38, = Lisandro Zambenedetti Granville wrote:
Hello Robert

You are not necessarily = restricted to the Role names that are
defined now (like = "chair"). We could add Role names like
"codematcher" or = "codematch_approver" or whatever other name
matches the = semantic for the permission you're wanting to
manage.

That=E2=80=99s great, so that we = can expand the current Roles without
changing the data = model.

You could then have things like Lisandro Granville is
codematch_approver in nmrg.

That is also what we need.

Just to be sure - you're saying that's sufficient, and while = you're
explaining the idea further below, you don't need = it right now?

Sorry, I was not = clear. Creating new Roles and allowing users being
assigned = to these new Roles are things that we need in CodeMatch too.
Further below I mention something that we are proposing = (i.e.,
has_right) in addition to having new roles.


Does that = address the need? If not, could you walk me though a
scenario where it makes it harder than it should?

What you mention above is the = link among users, roles, and
groups. There is another link = between roles and permissions that
seems to be hardcoded = in datatracker. When we say

if = has_role(request.user, ["Area Director", "IAB Chair", = "Secretariat=E2=80=9D]):
// do things the user with = "permission X" can do

it implies that if we = want to grant to, e.g.,
=E2=80=9Ccodematch_approver=E2=80=9D= the =E2=80=9Cpermission X=E2=80=9D above, we should go back
to the code and change it to

if = has_role(request.user, ["Area Director", "IAB Chair",
=E2=80=9CSecretariat=E2=80=9D, = =E2=80=9Ccodematch_approver"]):...

We were = then considering the possibility of moving the link
between = roles and permission to the data model and implement
has_right (or has_permission) like:

if has_right(request.user, =E2=80=9Cpermission X=E2=80=9D):
= // do things the user with "permission X" can do

If we want =E2=80=9Cpermission X=E2=80=9D to be granted to = other roles, that
would be a matter of including the = proper records in the
database, instead of changing the = code.

Trying not to go too much into = details, the summary is that we
want to check if assigning = permission to roles is ok to be done
in the database, = instead of changing the code.

Well, you still have to type has_right(...) in the code, = and
specify something concrete in that has_right that = would have to
change, so I don't think we're really = talking about avoiding
changing code as much as we are = about _where_ you model the idea of
a permission in the = database.

I agree. We are = talking about modeling the link between roles and
permission= in the database.

So, the = design you propose is elegant and matches the way permissions
are handled in many contexts, especially in COTS software = (and for
that matter, user-configurable FOSS software).

It is more flexible, but also has an added = complexity, and an added
abstraction level (in order to be = useful, the permissions need to be
named with names which = express what effect they are having in the code,
and this = may be non-trivial).

There is however one = point you don't bring up, which I would like to
bring up = here.

Summarizing the two ways of writing = the code, we can either have code
which says

if has_role(user, ["CodeMatch Approver"]):
   # code to be exectuted

or code which says

if = has_perm(user, ["approve codematch"]):
=    # code to be exectuted

For = IETF roles, the list of possible roles are very well codified,
while the only way to know which permissions that need to be = named
and listed in a role_auth_permission table is to go = through the
code and name all the places we check for = roles today.  Naming those
permissions, and making = clear the correspondence between the names
and the actual = effect they will have in code is not necessarily
trivial.
For the Codematch project, it may be that you = have a much better grasp
of the named permissions needed, = and not so good a grasp of the roles.

However, since irrespective of how the correspondence between = roles and
code is handled, whether it is via has_role() or = has_perm(), you actually
_need_ to be able to describe the = roles well, I would suggest that you
probably also have a = much better grasp of the roles than of all the
named = permissions which may be needed.

Given = that, I would suggest that you start out with the same approach
which has been used in the current datatracker code, and once = it is
possible to inspect the code and see which actual = places need to check
for different roles in order to = determine if a given piece of code may
be executed, _and_ = you have experience with the tool so that you can
speak = with confidence about which actions a given role should or should
not have, then _at that point_ we can consider refining = things into
roles and permissions, instead of listing = roles explicitly in the code.

More = below.

I think the real essence = of what we're talking about is the
difference in how you = would implement "Give all the WG chairs
codematch-approval = rights".

With your proposal, you would make = a role to permission match to do
that - one database row = change - pretty efficient (*) With what we
have now, you = just add a Role of "codematch-approval" to any Person
that = has a wg chair role. So, I think what you're proposing is an
optimization, and it comes with some complexity. We can = keep
talking about it, but I don't think we're at the = point that we need
it.

This complexity involves:

a) = Creating a new intermediate table =E2=80=9Crole_auth_permission" = composed
of, at least, two columns: role_id and = auth_permission_id;

b) Creating the = function "has_right (user, permission_label)" which
given = the user it retrieves the user=E2=80=99s roles, from roles it = retrieves
permissions and, among permissions, it checks if = permission_label is
present.

Of= course, the effort of doing a) and b) would be ours. And these
implementation would be used in CodeMatch only; it wouldn=E2=80= =99t be
changing or affecting DataTracker.

Understood.  But for the = datatracker, there is the added complexity of
maintaining = code which uses 2 different mechanisms to handle permissions.
And that the technical debt of carrying two different = solutions forward
is something you will not have to = suffer, but the datatracker project
will have to deal = with.

(*) But, it's not really = that easy. Right now we have a role of
"chair" that is = applied to all groups. There's no way to speak
differently = about WG chairs and RG chairs by simply saying "chair"
- = it takes more code. We have chairs of Teams, and _could_ have
(but don't currently) chairs of other SDOs in the database. = So, the
apparent simplicity of matching a permission to a = role-name isn't
as strong as it first appears.

While coding the CodeMatch = system, we notice that some portions of
the system may be = or may be not available to different user roles.
Although = we define somes roles now, changes on role-permissions will
probably happen along the development process.

Agreed.  In which case, = doing the necessary has_role() or has_perm()
code changes = will most likely happen along with other code changes.

The permissions we want = the roles to have define, let me say, the
policy of = CodeMatch. We wanted to decouple that policy from the
system= implementation itself, thus implementing an RBAC model; if the
link between roles and permissions (i.e., the system policy) = migrates
to the database, we can tag CodeMatch source code = (i.e., define
permission labels) and redefine which roles = are able to access
different parts of the system. Notice, = this is just for CodeMatch, of
course.

RBAC can be implemented both with = has_role() and has_perm(); the difference
lies in how easy = it is to reconfigure the permissions which are associated
with a given role.

For COTS = software, where you cannot easily adapt the code itself to the
customer environment and wishes, other than through data = lookup, the
approach you suggest makes a lot of sense. =  For our case, where there is
one and only one = production system, it is far less important, and it is
not = obvious that the added complexity and technical debt incurred is
offset by the added flexibility.

Please also consider the pace with which we release software = for the
datatracker:  Formal releases are shown in = the page:

 https://datatracker.ietf.org/release/

and in addition to that, we often apply patches.  As an = example, we
have done 10 formal releases within the 6.x.y = series, but during the
same time, we have applied 36 = patches, resulting in 20 patch release
numbers in addition = to the formal release numbers.  With this release
pace,= and with the possibility of applying patches,  we are probably
agile enough to handle the necessary code changes almost as = fast as you
could agree on what needs to be done and = change the settings in a
role_auth_permission table.

Could we agree on starting an RBAC = implementation using has_role(), and
once we have a bit = more experience, and only then, consider taking on
the = added complexity and technical debt of using 2 different permission
handling systems in this non-COTS software?


Best regards,

Henrik


Thanks,

Lisandro
We are of course talking about the CodeMatch code only; we = are not talking about the datatracker code at all, although examples = were inspired by has_role, which is used in datatracker.
Lisandro

On 8/25/15 1:52 PM, Lisandro Zambenedetti = Granville wrote:
Dear = All

Last week we had our traditional = CodeMatch meeting. One of the questions discussed in the meeting was = about role-based access control (RBAC) in CodeMatch. We would like to = propose adding an extra table in the current data model to support RBAC. = However, because we want to be as aligned with DataTracker style as = possible, we are sending this message to start a discussion, specially = with Henrik and Robert.

1) Style of = checking users=E2=80=99 permission

We = observed the DataTracker code and it seems that in general, permission = checking is hardcoded, in the following style (using =E2=80=9CArea = Director=E2=80=9D, =E2=80=9CIAB Chair=E2=80=9D, and =E2=80=9CSecretariat" = as examples):

if has_role(request.user, = ["Area Director", "IAB Chair", "Secretariat"]):
// do = something that only area diretor, IAB chair, and secretariat could do, = like =E2=80=9CCreate CodeRequest"


In CodeMatch, we would like to check permissions in the = following way:

if has_right(request.user, = =E2=80=9CCreate CodeRequest=E2=80=9D):
// do = something that only authorized people should be able to do, like = =E2=80=9CCreate CodeRequest=E2=80=9D

The = =E2=80=9Chas_right=E2=80=9D function would check the database to = retrieve the users=E2=80=99 roles and, for each role, check if it has = permission to =E2=80=9CCreate CodeRequest=E2=80=9D. In this way, = permissions are associated to roles, and roles associated to users.

Because permissions and roles in CodeMatch are = being defined together with the implementation of the system prototype, = the use of =E2=80=9Chas_right=E2=80=9D would allow us to assign = permissions to roles just changing the database, instead of changing the = CodeMatch code if we use =E2=80=9Chas_role=E2=80=9D instead.

2) Database

Today, = permissions are listed in table auth_permission. Roles are listed in = table group_role. We would need a intermediate table linking permissions = to roles, i.e., a table linking author_permissions and group_role. That = would allow us to say, for example, that a mentor (inside group_role) = can add documents to a codeRequest (i.e., a permission inside = auth_permission). Adding this intermediate table (let=E2=80=99s call it = role_permission for the moment) would not affect today=E2=80=99s = database, although it would expand today=E2=80=99s data model.

Do you think doing that is ok?
Best regards,

Lisandro, = Wanderson, Matheus

_______________________________________________Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop


= --Apple-Mail=_9A54C364-DD09-4B3F-BADC-589BF51F23BE-- From nobody Tue Sep 15 15:33:29 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0670F1B2C88 for ; Tue, 15 Sep 2015 15:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7Zuv-4AoQOYV for ; Tue, 15 Sep 2015 15:33:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11FC41B2C86 for ; Tue, 15 Sep 2015 15:33:22 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8FMXKer030440 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 15 Sep 2015 17:33:21 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local To: "Christian O'Flaherty" , Henrik Levkowetz References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> <55DE0CB3.8020001@nostrum.com> <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> <55DF0B7B.7020902@levkowetz.com> <9B6DB401-A599-4C19-857C-D64241FC467B@inf.ufrgs.br> From: Robert Sparks Message-ID: <55F89CAB.1060207@nostrum.com> Date: Tue, 15 Sep 2015 17:33:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040308040306080208080001" Archived-At: Cc: Lisandro Zambenedetti Granville , codematch-develop Subject: Re: [Codematch-develop] DataTracker and CodeMatch access control X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 22:33:28 -0000 This is a multi-part message in MIME format. --------------040308040306080208080001 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I thought the calls were on Tuesdays - when did that change? That aside - My advice from long ago (discussed before and during the Hawaii meeting), and my understanding of the plan was that this would initially be developed and deployed as a separate application that _used_ the datatracker database in read only mode, and used its own database to back the additional django classes it needed. We would integrate this into the datatracker more tightly after we had some runtime experience (allowing you to refactor more easily based on that experience). Our more recent discussion about how to use the Role object is consistent with that. We can add Role records to the production datatracker database easily. So, it's not clear to me that being part of a datatracker release is what we need to be talking about right now? RjS On 9/15/15 5:06 PM, Christian O'Flaherty wrote: > H Henrik, > > I don’t want to be pushy but we will have our codematch call tomorrow > and we would like to discuss this part: > >> We will need an assessment soon to check what’s missing to be >> “appropriate” and what would be the next steps to be part of a >> Datatracker release. > > Can you help us or join our call tomorrow at 16 UTC ? > > Thanks, > > Christian O'Flaherty - oflaherty@isoc.org > Regional Development -Internet Society > Skype/Gmail/Yahoo!: christian.oflaherty > Phone:+598 98769636 > >> On Sep 4, 2015, at 10:57 AM, Christian O'Flaherty > > wrote: >> >> Hi Henrik, >> >> We will follow your advise on permissions and roles. >> The Datamodel and readability issues (conventions on variable names >> and class attributes) were also fixed (those that you flagged when we >> started coding). >> >> We will need an assessment soon to check what’s missing to be >> “appropriate” and what would be the next steps to be part of a >> Datatracker release. >> >> Can you help us with that? >> >> Christian O'Flaherty - oflaherty@isoc.org >> Regional Development -Internet Society >> Skype/Gmail/Yahoo!: christian.oflaherty >> Phone:+598 98769636 >> >>> On Aug 27, 2015, at 3:30 PM, Lisandro Zambenedetti Granville >>> > wrote: >>> >>> Hello Henrik >>> >>> Thanks for all clarifications. Going to the most important question: >>> >>> "Could we agree on starting an RBAC implementation using has_role(), and >>> once we have a bit more experience, and only then, consider taking on >>> the added complexity and technical debt of using 2 different permission >>> handling systems in this non-COTS software?” >>> >>> Definitely yes. I’m convinced, after reading your arguments, that >>> having two different permission solutions in the same framework can >>> be ok for CodeMatch but it wouldn’t be ok for datatracker. An your >>> suggestion of concentrating now more on who can/cannot do what >>> should be a priority. >>> >>> Best regards, >>> >>> Lisandro >>> >>>> Em 27/08/2015, à(s) 10:07, Henrik Levkowetz >>> > escreveu: >>>> >>>> Hi Lisandro, >>>> >>>> Jumping in here with some comments: >>>> >>>> On 2015-08-26 21:38, Lisandro Zambenedetti Granville wrote: >>>>> Hello Robert >>>>> >>>>>>>> You are not necessarily restricted to the Role names that are >>>>>>>> defined now (like "chair"). We could add Role names like >>>>>>>> "codematcher" or "codematch_approver" or whatever other name >>>>>>>> matches the semantic for the permission you're wanting to >>>>>>>> manage. >>>>>>> >>>>>>> That’s great, so that we can expand the current Roles without >>>>>>> changing the data model. >>>>>>> >>>>>>>> You could then have things like Lisandro Granville is >>>>>>>> codematch_approver in nmrg. >>>>>>> >>>>>>> That is also what we need. >>>>>> >>>>>> Just to be sure - you're saying that's sufficient, and while you're >>>>>> explaining the idea further below, you don't need it right now? >>>>> >>>>> Sorry, I was not clear. Creating new Roles and allowing users being >>>>> assigned to these new Roles are things that we need in CodeMatch too. >>>>> Further below I mention something that we are proposing (i.e., >>>>> has_right) in addition to having new roles. >>>>> >>>> >>>>>>>> Does that address the need? If not, could you walk me though a >>>>>>>> scenario where it makes it harder than it should? >>>>>>> >>>>>>> What you mention above is the link among users, roles, and >>>>>>> groups. There is another link between roles and permissions that >>>>>>> seems to be hardcoded in datatracker. When we say >>>>>>> >>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", >>>>>>> "Secretariat”]): >>>>>>> // do things the user with "permission X" can do >>>>>>> >>>>>>> it implies that if we want to grant to, e.g., >>>>>>> “codematch_approver” the “permission X” above, we should go back >>>>>>> to the code and change it to >>>>>>> >>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", >>>>>>> “Secretariat”, “codematch_approver"]):... >>>>>>> >>>>>>> We were then considering the possibility of moving the link >>>>>>> between roles and permission to the data model and implement >>>>>>> has_right (or has_permission) like: >>>>>>> >>>>>>> if has_right(request.user, “permission X”): >>>>>>> // do things the user with "permission X" can do >>>>>>> >>>>>>> If we want “permission X” to be granted to other roles, that >>>>>>> would be a matter of including the proper records in the >>>>>>> database, instead of changing the code. >>>>>>> >>>>>>> Trying not to go too much into details, the summary is that we >>>>>>> want to check if assigning permission to roles is ok to be done >>>>>>> in the database, instead of changing the code. >>>>>> >>>>>> Well, you still have to type has_right(...) in the code, and >>>>>> specify something concrete in that has_right that would have to >>>>>> change, so I don't think we're really talking about avoiding >>>>>> changing code as much as we are about _where_ you model the idea of >>>>>> a permission in the database. >>>>> >>>>> I agree. We are talking about modeling the link between roles and >>>>> permission in the database. >>>> >>>> So, the design you propose is elegant and matches the way permissions >>>> are handled in many contexts, especially in COTS software (and for >>>> that matter, user-configurable FOSS software). >>>> >>>> It is more flexible, but also has an added complexity, and an added >>>> abstraction level (in order to be useful, the permissions need to be >>>> named with names which express what effect they are having in the code, >>>> and this may be non-trivial). >>>> >>>> There is however one point you don't bring up, which I would like to >>>> bring up here. >>>> >>>> Summarizing the two ways of writing the code, we can either have code >>>> which says >>>> >>>> if has_role(user, ["CodeMatch Approver"]): >>>> # code to be exectuted >>>> >>>> or code which says >>>> >>>> if has_perm(user, ["approve codematch"]): >>>> # code to be exectuted >>>> >>>> For IETF roles, the list of possible roles are very well codified, >>>> while the only way to know which permissions that need to be named >>>> and listed in a role_auth_permission table is to go through the >>>> code and name all the places we check for roles today. Naming those >>>> permissions, and making clear the correspondence between the names >>>> and the actual effect they will have in code is not necessarily >>>> trivial. >>>> >>>> For the Codematch project, it may be that you have a much better grasp >>>> of the named permissions needed, and not so good a grasp of the roles. >>>> >>>> However, since irrespective of how the correspondence between roles and >>>> code is handled, whether it is via has_role() or has_perm(), you >>>> actually >>>> _need_ to be able to describe the roles well, I would suggest that you >>>> probably also have a much better grasp of the roles than of all the >>>> named permissions which may be needed. >>>> >>>> Given that, I would suggest that you start out with the same approach >>>> which has been used in the current datatracker code, and once it is >>>> possible to inspect the code and see which actual places need to check >>>> for different roles in order to determine if a given piece of code may >>>> be executed, _and_ you have experience with the tool so that you can >>>> speak with confidence about which actions a given role should or should >>>> not have, then _at that point_ we can consider refining things into >>>> roles and permissions, instead of listing roles explicitly in the code. >>>> >>>> More below. >>>> >>>>>> I think the real essence of what we're talking about is the >>>>>> difference in how you would implement "Give all the WG chairs >>>>>> codematch-approval rights". >>>>>> >>>>>> With your proposal, you would make a role to permission match to do >>>>>> that - one database row change - pretty efficient (*) With what we >>>>>> have now, you just add a Role of "codematch-approval" to any Person >>>>>> that has a wg chair role. So, I think what you're proposing is an >>>>>> optimization, and it comes with some complexity. We can keep >>>>>> talking about it, but I don't think we're at the point that we need >>>>>> it. >>>>> >>>>> This complexity involves: >>>>> >>>>> a) Creating a new intermediate table “role_auth_permission" composed >>>>> of, at least, two columns: role_id and auth_permission_id; >>>>> >>>>> b) Creating the function "has_right (user, permission_label)" which >>>>> given the user it retrieves the user’s roles, from roles it retrieves >>>>> permissions and, among permissions, it checks if permission_label is >>>>> present. >>>>> >>>>> Of course, the effort of doing a) and b) would be ours. And these >>>>> implementation would be used in CodeMatch only; it wouldn’t be >>>>> changing or affecting DataTracker. >>>> >>>> Understood. But for the datatracker, there is the added complexity of >>>> maintaining code which uses 2 different mechanisms to handle >>>> permissions. >>>> And that the technical debt of carrying two different solutions forward >>>> is something you will not have to suffer, but the datatracker project >>>> will have to deal with. >>>> >>>>>> (*) But, it's not really that easy. Right now we have a role of >>>>>> "chair" that is applied to all groups. There's no way to speak >>>>>> differently about WG chairs and RG chairs by simply saying "chair" >>>>>> - it takes more code. We have chairs of Teams, and _could_ have >>>>>> (but don't currently) chairs of other SDOs in the database. So, the >>>>>> apparent simplicity of matching a permission to a role-name isn't >>>>>> as strong as it first appears. >>>>> >>>>> While coding the CodeMatch system, we notice that some portions of >>>>> the system may be or may be not available to different user roles. >>>>> Although we define somes roles now, changes on role-permissions will >>>>> probably happen along the development process. >>>> >>>> Agreed. In which case, doing the necessary has_role() or has_perm() >>>> code changes will most likely happen along with other code changes. >>>> >>>>> The permissions we want the roles to have define, let me say, the >>>>> policy of CodeMatch. We wanted to decouple that policy from the >>>>> system implementation itself, thus implementing an RBAC model; if the >>>>> link between roles and permissions (i.e., the system policy) migrates >>>>> to the database, we can tag CodeMatch source code (i.e., define >>>>> permission labels) and redefine which roles are able to access >>>>> different parts of the system. Notice, this is just for CodeMatch, of >>>>> course. >>>> >>>> RBAC can be implemented both with has_role() and has_perm(); the >>>> difference >>>> lies in how easy it is to reconfigure the permissions which are >>>> associated >>>> with a given role. >>>> >>>> For COTS software, where you cannot easily adapt the code itself to the >>>> customer environment and wishes, other than through data lookup, the >>>> approach you suggest makes a lot of sense. For our case, where >>>> there is >>>> one and only one production system, it is far less important, and it is >>>> not obvious that the added complexity and technical debt incurred is >>>> offset by the added flexibility. >>>> >>>> Please also consider the pace with which we release software for the >>>> datatracker: Formal releases are shown in the page: >>>> >>>> https://datatracker.ietf.org/release/ >>>> >>>> and in addition to that, we often apply patches. As an example, we >>>> have done 10 formal releases within the 6.x.y series, but during the >>>> same time, we have applied 36 patches, resulting in 20 patch release >>>> numbers in addition to the formal release numbers. With this release >>>> pace, and with the possibility of applying patches, we are probably >>>> agile enough to handle the necessary code changes almost as fast as you >>>> could agree on what needs to be done and change the settings in a >>>> role_auth_permission table. >>>> >>>> Could we agree on starting an RBAC implementation using has_role(), and >>>> once we have a bit more experience, and only then, consider taking on >>>> the added complexity and technical debt of using 2 different permission >>>> handling systems in this non-COTS software? >>>> >>>> >>>> Best regards, >>>> >>>> Henrik >>>> >>>> >>>>> Thanks, >>>>> >>>>> Lisandro >>>>> >>>>>>> We are of course talking about the CodeMatch code only; we are >>>>>>> not talking about the datatracker code at all, although examples >>>>>>> were inspired by has_role, which is used in datatracker. >>>>>>> >>>>>>> Lisandro >>>>>>> >>>>>>>> On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote: >>>>>>>>> Dear All >>>>>>>>> >>>>>>>>> Last week we had our traditional CodeMatch meeting. One of the >>>>>>>>> questions discussed in the meeting was about role-based access >>>>>>>>> control (RBAC) in CodeMatch. We would like to propose adding >>>>>>>>> an extra table in the current data model to support RBAC. >>>>>>>>> However, because we want to be as aligned with DataTracker >>>>>>>>> style as possible, we are sending this message to start a >>>>>>>>> discussion, specially with Henrik and Robert. >>>>>>>>> >>>>>>>>> 1) Style of checking users’ permission >>>>>>>>> >>>>>>>>> We observed the DataTracker code and it seems that in general, >>>>>>>>> permission checking is hardcoded, in the following style >>>>>>>>> (using “Area Director”, “IAB Chair”, and “Secretariat" as >>>>>>>>> examples): >>>>>>>>> >>>>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", >>>>>>>>> "Secretariat"]): >>>>>>>>> // do something that only area diretor, IAB chair, and >>>>>>>>> secretariat could do, like “Create CodeRequest" >>>>>>>>> >>>>>>>>> >>>>>>>>> In CodeMatch, we would like to check permissions in the >>>>>>>>> following way: >>>>>>>>> >>>>>>>>> if has_right(request.user, “Create CodeRequest”): >>>>>>>>> // do something that only authorized people should be able to >>>>>>>>> do, like “Create CodeRequest” >>>>>>>>> >>>>>>>>> The “has_right” function would check the database to retrieve >>>>>>>>> the users’ roles and, for each role, check if it has >>>>>>>>> permission to “Create CodeRequest”. In this way, permissions >>>>>>>>> are associated to roles, and roles associated to users. >>>>>>>>> >>>>>>>>> Because permissions and roles in CodeMatch are being defined >>>>>>>>> together with the implementation of the system prototype, the >>>>>>>>> use of “has_right” would allow us to assign permissions to >>>>>>>>> roles just changing the database, instead of changing the >>>>>>>>> CodeMatch code if we use “has_role” instead. >>>>>>>>> >>>>>>>>> 2) Database >>>>>>>>> >>>>>>>>> Today, permissions are listed in table auth_permission. Roles >>>>>>>>> are listed in table group_role. We would need a intermediate >>>>>>>>> table linking permissions to roles, i.e., a table linking >>>>>>>>> author_permissions and group_role. That would allow us to say, >>>>>>>>> for example, that a mentor (inside group_role) can add >>>>>>>>> documents to a codeRequest (i.e., a permission inside >>>>>>>>> auth_permission). Adding this intermediate table (let’s call >>>>>>>>> it role_permission for the moment) would not affect today’s >>>>>>>>> database, although it would expand today’s data model. >>>>>>>>> >>>>>>>>> Do you think doing that is ok? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Lisandro, Wanderson, Matheus >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Codematch-develop mailing list >>>>>>>> Codematch-develop@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>>>> >>>>> >>>>> >>> >>> _______________________________________________ >>> Codematch-develop mailing list >>> Codematch-develop@ietf.org >>> https://www.ietf.org/mailman/listinfo/codematch-develop >> > --------------040308040306080208080001 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I thought the calls were on Tuesdays - when did that change?

That aside - My advice from long ago (discussed before and during the Hawaii meeting), and my understanding of the plan was that this would initially be developed and deployed as a separate application that _used_ the datatracker database in read only mode, and used its own database to back the additional django classes it needed. We would integrate this into the datatracker more tightly after we had some runtime experience (allowing you to refactor more easily based on that experience).

Our more recent discussion about how to use the Role object is consistent with that. We can add Role records to the production datatracker database easily.

So, it's not clear to me that being part of a datatracker release is what we need to be talking about right now?

RjS

On 9/15/15 5:06 PM, Christian O'Flaherty wrote:
H Henrik, 

I don’t want to be pushy but we will have our codematch call tomorrow and we would like to discuss this part:

We will need an assessment soon to check what’s missing to be “appropriate” and what would be the next steps to be part of a Datatracker release.

Can you help us or join our call tomorrow at 16 UTC ?

Thanks,

Christian O'Flaherty - oflaherty@isoc.org
Regional Development - Internet Society 
Skype/Gmail/Yahoo!:  christian.oflaherty 
Phone: +598 98769636

On Sep 4, 2015, at 10:57 AM, Christian O'Flaherty <oflaherty@isoc.org> wrote:

Hi Henrik,

We will follow your advise on permissions and roles. 
The Datamodel and readability issues (conventions on variable names and class attributes) were also fixed (those that you flagged when we started coding).

We will need an assessment soon to check what’s missing to be “appropriate” and what would be the next steps to be part of a Datatracker release.

Can you help us with that? 

Christian O'Flaherty - oflaherty@isoc.org
Regional Development - Internet Society 
Skype/Gmail/Yahoo!:  christian.oflaherty 
Phone: +598 98769636

On Aug 27, 2015, at 3:30 PM, Lisandro Zambenedetti Granville <granville@inf.ufrgs.br> wrote:

Hello Henrik

Thanks for all clarifications. Going to the most important question:

"Could we agree on starting an RBAC implementation using has_role(), and
once we have a bit more experience, and only then, consider taking on
the added complexity and technical debt of using 2 different permission
handling systems in this non-COTS software?”

Definitely yes. I’m convinced, after reading your arguments, that having two different permission solutions in the same framework can be ok for CodeMatch but it wouldn’t be ok for datatracker. An your suggestion of concentrating now more on who can/cannot do what should be a priority.

Best regards,

Lisandro

Em 27/08/2015, à(s) 10:07, Henrik Levkowetz <henrik@levkowetz.com> escreveu:

Hi Lisandro,

Jumping in here with some comments:

On 2015-08-26 21:38, Lisandro Zambenedetti Granville wrote:
Hello Robert

You are not necessarily restricted to the Role names that are
defined now (like "chair"). We could add Role names like
"codematcher" or "codematch_approver" or whatever other name
matches the semantic for the permission you're wanting to
manage.

That’s great, so that we can expand the current Roles without
changing the data model.

You could then have things like Lisandro Granville is
codematch_approver in nmrg.

That is also what we need.

Just to be sure - you're saying that's sufficient, and while you're
explaining the idea further below, you don't need it right now?

Sorry, I was not clear. Creating new Roles and allowing users being
assigned to these new Roles are things that we need in CodeMatch too.
Further below I mention something that we are proposing (i.e.,
has_right) in addition to having new roles.


Does that address the need? If not, could you walk me though a
scenario where it makes it harder than it should?

What you mention above is the link among users, roles, and
groups. There is another link between roles and permissions that
seems to be hardcoded in datatracker. When we say

if has_role(request.user, ["Area Director", "IAB Chair", "Secretariat”]):
// do things the user with "permission X" can do

it implies that if we want to grant to, e.g.,
“codematch_approver” the “permission X” above, we should go back
to the code and change it to

if has_role(request.user, ["Area Director", "IAB Chair",
“Secretariat”, “codematch_approver"]):...

We were then considering the possibility of moving the link
between roles and permission to the data model and implement
has_right (or has_permission) like:

if has_right(request.user, “permission X”):
// do things the user with "permission X" can do

If we want “permission X” to be granted to other roles, that
would be a matter of including the proper records in the
database, instead of changing the code.

Trying not to go too much into details, the summary is that we
want to check if assigning permission to roles is ok to be done
in the database, instead of changing the code.

Well, you still have to type has_right(...) in the code, and
specify something concrete in that has_right that would have to
change, so I don't think we're really talking about avoiding
changing code as much as we are about _where_ you model the idea of
a permission in the database.

I agree. We are talking about modeling the link between roles and
permission in the database.

So, the design you propose is elegant and matches the way permissions
are handled in many contexts, especially in COTS software (and for
that matter, user-configurable FOSS software).

It is more flexible, but also has an added complexity, and an added
abstraction level (in order to be useful, the permissions need to be
named with names which express what effect they are having in the code,
and this may be non-trivial).

There is however one point you don't bring up, which I would like to
bring up here.

Summarizing the two ways of writing the code, we can either have code
which says

if has_role(user, ["CodeMatch Approver"]):
   # code to be exectuted

or code which says

if has_perm(user, ["approve codematch"]):
   # code to be exectuted

For IETF roles, the list of possible roles are very well codified,
while the only way to know which permissions that need to be named
and listed in a role_auth_permission table is to go through the
code and name all the places we check for roles today.  Naming those
permissions, and making clear the correspondence between the names
and the actual effect they will have in code is not necessarily
trivial.

For the Codematch project, it may be that you have a much better grasp
of the named permissions needed, and not so good a grasp of the roles.

However, since irrespective of how the correspondence between roles and
code is handled, whether it is via has_role() or has_perm(), you actually
_need_ to be able to describe the roles well, I would suggest that you
probably also have a much better grasp of the roles than of all the
named permissions which may be needed.

Given that, I would suggest that you start out with the same approach
which has been used in the current datatracker code, and once it is
possible to inspect the code and see which actual places need to check
for different roles in order to determine if a given piece of code may
be executed, _and_ you have experience with the tool so that you can
speak with confidence about which actions a given role should or should
not have, then _at that point_ we can consider refining things into
roles and permissions, instead of listing roles explicitly in the code.

More below.

I think the real essence of what we're talking about is the
difference in how you would implement "Give all the WG chairs
codematch-approval rights".

With your proposal, you would make a role to permission match to do
that - one database row change - pretty efficient (*) With what we
have now, you just add a Role of "codematch-approval" to any Person
that has a wg chair role. So, I think what you're proposing is an
optimization, and it comes with some complexity. We can keep
talking about it, but I don't think we're at the point that we need
it.

This complexity involves:

a) Creating a new intermediate table “role_auth_permission" composed
of, at least, two columns: role_id and auth_permission_id;

b) Creating the function "has_right (user, permission_label)" which
given the user it retrieves the user’s roles, from roles it retrieves
permissions and, among permissions, it checks if permission_label is
present.

Of course, the effort of doing a) and b) would be ours. And these
implementation would be used in CodeMatch only; it wouldn’t be
changing or affecting DataTracker.

Understood.  But for the datatracker, there is the added complexity of
maintaining code which uses 2 different mechanisms to handle permissions.
And that the technical debt of carrying two different solutions forward
is something you will not have to suffer, but the datatracker project
will have to deal with.

(*) But, it's not really that easy. Right now we have a role of
"chair" that is applied to all groups. There's no way to speak
differently about WG chairs and RG chairs by simply saying "chair"
- it takes more code. We have chairs of Teams, and _could_ have
(but don't currently) chairs of other SDOs in the database. So, the
apparent simplicity of matching a permission to a role-name isn't
as strong as it first appears.

While coding the CodeMatch system, we notice that some portions of
the system may be or may be not available to different user roles.
Although we define somes roles now, changes on role-permissions will
probably happen along the development process.

Agreed.  In which case, doing the necessary has_role() or has_perm()
code changes will most likely happen along with other code changes.

The permissions we want the roles to have define, let me say, the
policy of CodeMatch. We wanted to decouple that policy from the
system implementation itself, thus implementing an RBAC model; if the
link between roles and permissions (i.e., the system policy) migrates
to the database, we can tag CodeMatch source code (i.e., define
permission labels) and redefine which roles are able to access
different parts of the system. Notice, this is just for CodeMatch, of
course.

RBAC can be implemented both with has_role() and has_perm(); the difference
lies in how easy it is to reconfigure the permissions which are associated
with a given role.

For COTS software, where you cannot easily adapt the code itself to the
customer environment and wishes, other than through data lookup, the
approach you suggest makes a lot of sense.  For our case, where there is
one and only one production system, it is far less important, and it is
not obvious that the added complexity and technical debt incurred is
offset by the added flexibility.

Please also consider the pace with which we release software for the
datatracker:  Formal releases are shown in the page:

 https://datatracker.ietf.org/release/

and in addition to that, we often apply patches.  As an example, we
have done 10 formal releases within the 6.x.y series, but during the
same time, we have applied 36 patches, resulting in 20 patch release
numbers in addition to the formal release numbers.  With this release
pace, and with the possibility of applying patches,  we are probably
agile enough to handle the necessary code changes almost as fast as you
could agree on what needs to be done and change the settings in a
role_auth_permission table.

Could we agree on starting an RBAC implementation using has_role(), and
once we have a bit more experience, and only then, consider taking on
the added complexity and technical debt of using 2 different permission
handling systems in this non-COTS software?


Best regards,

Henrik


Thanks,

Lisandro

We are of course talking about the CodeMatch code only; we are not talking about the datatracker code at all, although examples were inspired by has_role, which is used in datatracker.

Lisandro

On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote:
Dear All

Last week we had our traditional CodeMatch meeting. One of the questions discussed in the meeting was about role-based access control (RBAC) in CodeMatch. We would like to propose adding an extra table in the current data model to support RBAC. However, because we want to be as aligned with DataTracker style as possible, we are sending this message to start a discussion, specially with Henrik and Robert.

1) Style of checking users’ permission

We observed the DataTracker code and it seems that in general, permission checking is hardcoded, in the following style (using “Area Director”, “IAB Chair”, and “Secretariat" as examples):

if has_role(request.user, ["Area Director", "IAB Chair", "Secretariat"]):
// do something that only area diretor, IAB chair, and secretariat could do, like “Create CodeRequest"


In CodeMatch, we would like to check permissions in the following way:

if has_right(request.user, “Create CodeRequest”):
// do something that only authorized people should be able to do, like “Create CodeRequest”

The “has_right” function would check the database to retrieve the users’ roles and, for each role, check if it has permission to “Create CodeRequest”. In this way, permissions are associated to roles, and roles associated to users.

Because permissions and roles in CodeMatch are being defined together with the implementation of the system prototype, the use of “has_right” would allow us to assign permissions to roles just changing the database, instead of changing the CodeMatch code if we use “has_role” instead.

2) Database

Today, permissions are listed in table auth_permission. Roles are listed in table group_role. We would need a intermediate table linking permissions to roles, i.e., a table linking author_permissions and group_role. That would allow us to say, for example, that a mentor (inside group_role) can add documents to a codeRequest (i.e., a permission inside auth_permission). Adding this intermediate table (let’s call it role_permission for the moment) would not affect today’s database, although it would expand today’s data model.

Do you think doing that is ok?

Best regards,

Lisandro, Wanderson, Matheus

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop




_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop



--------------040308040306080208080001-- From nobody Tue Sep 15 15:39:15 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CAD1B2CC7 for ; Tue, 15 Sep 2015 15:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 3Dy2VqObvano for ; Tue, 15 Sep 2015 15:39:13 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217991B2CC1 for ; Tue, 15 Sep 2015 15:39:13 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8FMdCbJ031077 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 15 Sep 2015 17:39:12 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local To: "Christian O'Flaherty" , Henrik Levkowetz References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> <55DE0CB3.8020001@nostrum.com> <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> <55DF0B7B.7020902@levkowetz.com> <9B6DB401-A599-4C19-857C-D64241FC467B@inf.ufrgs.br> <55F89CAB.1060207@nostrum.com> From: Robert Sparks Message-ID: <55F89E0B.7030602@nostrum.com> Date: Tue, 15 Sep 2015 17:39:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55F89CAB.1060207@nostrum.com> Content-Type: multipart/alternative; boundary="------------090406030003030108030401" Archived-At: Cc: Lisandro Zambenedetti Granville , codematch-develop Subject: Re: [Codematch-develop] DataTracker and CodeMatch access control X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 22:39:14 -0000 This is a multi-part message in MIME format. --------------090406030003030108030401 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 9/15/15 5:33 PM, Robert Sparks wrote: > I thought the calls were on Tuesdays - when did that change? > Ignore that part - I see they've been mostly on Wednesdays for a long time. Please forward the coordinates? (I don't know if I can make tomorrow, but if I can move a meeting I'll be there). RjS --------------090406030003030108030401 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 9/15/15 5:33 PM, Robert Sparks wrote:
I thought the calls were on Tuesdays - when did that change?

Ignore that part - I see they've been mostly on Wednesdays for a long time.
Please forward the coordinates? (I don't know if I can make tomorrow, but if I can move a meeting I'll be there).

RjS
--------------090406030003030108030401-- From nobody Tue Sep 15 18:54:58 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1756E1B30C1 for ; Tue, 15 Sep 2015 18:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 PJ1ea0JQW5TK for ; Tue, 15 Sep 2015 18:54:53 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 977B01B30BF for ; Tue, 15 Sep 2015 18:54:53 -0700 (PDT) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t8G1sp1d028172 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Sep 2015 21:54:51 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t8G1sp1d028172 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1442368492; bh=SlB/tUgiu/tWTFesCwga15immso=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=rfXVy+MHRPQzrxrILhaySrTS1wwGx3LU7Dnfx/RL1x7rChY97pqeK4UtqA87ctEu8 QICPV8foaBfkNVNl9sOKnCGMiN6f9mUoKqQB/IpnOc2tKc5h/75hdUAwmMIsB7vYGP h6ykgaPvJWE3ZxcfVkKESoyGOTwk9hhVBBRC1M+4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t8G1sp1d028172 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd54.lss.emc.com (RSA Interceptor); Tue, 15 Sep 2015 21:54:26 -0400 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t8G1sY3I013077 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Sep 2015 21:54:35 -0400 Received: from MXHUB104.corp.emc.com (10.253.58.16) by mxhub19.corp.emc.com (10.254.93.48) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 15 Sep 2015 21:54:33 -0400 Received: from MX103CL02.corp.emc.com ([169.254.6.245]) by MXHUB104.corp.emc.com ([::1]) with mapi id 14.03.0224.002; Tue, 15 Sep 2015 21:54:33 -0400 From: "Moriarty, Kathleen" To: Robert Sparks Thread-Topic: [Codematch-develop] DataTracker and CodeMatch access control Thread-Index: AQHQ32c4cHcbq5mtxkSRoRecv6/mhp4eonoAgAA7QoCAAAlXgIAACqOAgAElFoCAAFpvgIAMRlMAgBHSWYCAAAdegIAAAaSA///zi7U= Date: Wed, 16 Sep 2015 01:54:32 +0000 Message-ID: References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> <55DE0CB3.8020001@nostrum.com> <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> <55DF0B7B.7020902@levkowetz.com> <9B6DB401-A599-4C19-857C-D64241FC467B@inf.ufrgs.br> <55F89CAB.1060207@nostrum.com>,<55F89E0B.7030602@nostrum.com> In-Reply-To: <55F89E0B.7030602@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: Lisandro Zambenedetti Granville , codematch-develop , Henrik Levkowetz , Christian O'Flaherty Subject: Re: [Codematch-develop] DataTracker and CodeMatch access control X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 01:54:56 -0000 Hi Robert, Thank you, here is the call information for tomorrow: JOIN WEBEX MEETING https://isoc.webex.com/isoc/j.php?MTID=3Dmcf3b8c886b81a58535ea02c3ba3ba940 Meeting number: 926 480 716 Meeting password: coder JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Access code: 926 480 716 Global call-in numbers: https://isoc.webex.com/isoc/globalcallin.php?serviceType=3DMC&ED=3D32209933= 2&tollFree=3D0 Best regards, Kathleen=20 Sent from my iPhone > On Sep 15, 2015, at 6:39 PM, Robert Sparks wrote: >=20 >=20 >=20 >> On 9/15/15 5:33 PM, Robert Sparks wrote: >> I thought the calls were on Tuesdays - when did that change? > Ignore that part - I see they've been mostly on Wednesdays for a long tim= e. > Please forward the coordinates? (I don't know if I can make tomorrow, but= if I can move a meeting I'll be there). >=20 > RjS > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop From nobody Wed Sep 16 06:18:50 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9E61B3686 for ; Wed, 16 Sep 2015 06:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 9hdvw-ix3GqM for ; Wed, 16 Sep 2015 06:18:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0638.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::638]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C6081B367A for ; Wed, 16 Sep 2015 06:18:46 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=oflaherty@isoc.org; Received: from 87-7-200.lacnic.net.uy (200.7.87.29) by CO2PR0601MB776.namprd06.prod.outlook.com (10.141.247.140) with Microsoft SMTP Server (TLS) id 15.1.262.15; Wed, 16 Sep 2015 13:18:20 +0000 MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_32E448A0-C94B-45C2-BF16-BB7194A16B62" From: Christian O'Flaherty In-Reply-To: Date: Wed, 16 Sep 2015 10:18:11 -0300 Message-ID: <8D85CDF3-9C77-46E6-B6B9-4A52EBCC9FC3@isoc.org> References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> <55DE0CB3.8020001@nostrum.com> <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> <55DF0B7B.7020902@levkowetz.com> <9B6DB401-A599-4C19-857C-D64241FC467B@inf.ufrgs.br> <55F89CAB.1060207@nostrum.com> <55F89E0B.7030602@nostrum.com> To: "Moriarty, Kathleen" X-Mailer: Apple Mail (2.2104) X-Originating-IP: [200.7.87.29] X-ClientProxiedBy: BY2PR04CA0076.namprd04.prod.outlook.com (10.255.247.44) To CO2PR0601MB776.namprd06.prod.outlook.com (10.141.247.140) X-Microsoft-Exchange-Diagnostics: 1; CO2PR0601MB776; 2:bHyQmSfiPzwx7hEuRwIDN2xgFhSS539X3VsywWyLeUjTzctT1RbO4iu/nXSzhxJveYlzgPtRN9MmzgcwXAGKtFQF8oZ52oy7aPoybhvmtUGtpYcivVERe0+0/S6wXU+uZ82vgBLYIg9Qts0VP5F3p9/3pygFvO03E1TrrIQNP1k=; 3:IJJdlSFHPaVRIQpaUcgp2ZFYJzVvc3Fl6b8jzhcMETXuurshYOJdlgeCOU5j8NfmNN6Wld6C4gTDA76Fi/82+TmrKc2CiJYI9vroxzZ5kGg80anwOI7HdMlaoXbSlFm0eLVHNZ6AI5EqqYU3KZe6+A==; 25:rbAxjMiKjPokVYrmVUwjNkZu8FNWFkSA29SuqH8eBPlOZOCadJkECHAhbg4PYUG8+3Th5zJJnd2sxnv3wRMcavW+JJdNZNaAjx4epGc/fjEzdxkm6nqg8SD98Rv8bZMzT8lZd0oETNzhez6vPOwswSB/hBHBy7J/me5SHzELKQap8sZ2eDqWLYefSmfNa+CY+BH/18ySH3VwbZPqYidXQICx7N+vRrhn3SVAEgXGTwL0lLGvINzzBLGEz4OAtKoJZpkg5xre6xD90gATU4yW5Q== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR0601MB776; X-Microsoft-Exchange-Diagnostics: 1; CO2PR0601MB776; 20:lE1/08YnEKyIZk4ktgL2OVHvrdYF8LyiWC3Ig/NJu1w/t+/ogIENkmCIjqOz+ChU+7rO5SFdgkED3U9mcDRy7MvVxx8PUWAzBDsQbfl636vWYZ/1x5C+ZlLO9WfBvkQwM/oguBZ9gh8sx0JsoviZkM5kWAinivgR7Jav68yVBTRlkRXPRswi9MWiuUzwJ6vVOlhwhdEv1D3TvJRQaZ8yjdFfhODXTFUxNOxJh3kP/V1YmLwJhoLU4Oa7B78MJaR7OlYeTxfcjdSlC6xsjpP3c/KvK0HWd92aBHZ95ZmWIT5HbDgihSokN7JnjWLtQ+DhYK90W3utOIw9AhX2h/4nT3OIns3a3lNtisub+mEH90Tg4haPnkH5WIhUsxMRzECpXNgRPId3h5hMkxPHrKM9/s8923RGmh3XLwcu4uN55EdkH3fgGqQFkaFVT8h5XwceihBh4xvQGHZRMMgJ+mO/Cw+QmPEMh+bLChAvnW3LR3PWtuLJrZTy5hwam22Npqqm; 4:43QjlS4TLCQw/Bk8CpAneM3V2dFe/hp4Qa6JlVWyrRWAnCKkBuJUaGOAbqPXWk0OoiXplSObZmuwheZk8mwuY+eCqJ0LpdULbGGd+tfnNUd2UQFlGsJDpga2b33fpdvEUbphJCRwKrytYnLUvL8ioY8+SMi/o9/YjE21JxDEiQuklzNGqof1f/K8g12e877RYuBA5jxzMS9/AewA7VANWmW4DFgp77iQASUcQSpi9aB6CFChh6EGW4LTB+tcjAbQlY00CqAIHLyyXRt/Dj2QQMzEJP5qUGdvzYtidNF+SIhamWKLYKTTFKyHxK9cYuF0YQ3unsYEBV+kNwAfUNHeb0j3j5WbqtfAOeWCHFsG0yiMe5js3mdTtSAb/K+j7vCy X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520075)(520078)(520058)(8121501046)(3002001); SRVR:CO2PR0601MB776; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0601MB776; X-Forefront-PRVS: 07013D7479 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(189002)(199003)(479174004)(377454003)(52314003)(24454002)(5003630100001)(92566002)(42186005)(5001830100001)(110136002)(5001960100002)(105586002)(33656002)(122386002)(40100003)(36756003)(53416004)(5001860100001)(5001920100001)(86362001)(106356001)(19580405001)(77156002)(62966003)(97736004)(15975445007)(69556001)(189998001)(5007970100001)(64706001)(69596002)(57306001)(16799955002)(19580395003)(19617315012)(77096005)(81156007)(50986999)(2950100001)(4001540100001)(84326002)(66066001)(68736005)(5004730100002)(551544002)(101416001)(50226001)(83716003)(46102003)(512874002)(87976001)(93886004)(76176999)(82746002)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR0601MB776; H:87-7-200.lacnic.net.uy; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR0601MB776; 23:r7Gt2FdPKG9wozNXcECy0vsz6F5+algSUBuMIAdt?= =?us-ascii?Q?2aYGOV7MW43T71Qrn3ebrCmCG/Hb4UDb1lLnsrjnYX0aEQD45jxHJ7hl6bhP?= =?us-ascii?Q?9by95L5Y1phlPRTA48CbmaDGtRDxt5DecOeq0QYHR0zNGLpLvd0YJF1ZA/Qb?= =?us-ascii?Q?u2J/I9ZdPe6PEvVGn7JOWvV654l0ioVBQ+AVqsr8hn1TwnGzljpwk3U9R9hA?= =?us-ascii?Q?FLI3WqmIlaVc1LdvY9UGDYxXgqRmGrIt0rwF+tc6YYyd0keLIdECvCNy5gQq?= =?us-ascii?Q?oKon7/HlVVNnGSFyvWqmD27zkdbJ63Ot6MZOXEelquPE2Iw3ZEBzBKG/sX+g?= =?us-ascii?Q?sAp4W5jse7A58rqrcK7d2kjoocX2K9GTChwZUzSfV5o7GDp4upmKk4LTvUyt?= =?us-ascii?Q?dg0VwhtUBa7Dnsh4lOxMj3ld6Ek18I8O+FdZU75f1ebAGRsIlVni1qex51eI?= =?us-ascii?Q?D31ae9ZAB7E7v7G1iYGtovXeuWXkGiS4Z/ywCxWSX3BYOuT+ofQgcCh47dj3?= =?us-ascii?Q?DNvqYNz0uXipriBZ8K288SfKd7yb2ki6+nKu9KiG62W7bme3pnZCDC+pwndn?= =?us-ascii?Q?OH4JwoEiFlCkupdDKO6jL1tc2k9VCTFOJFOk0qIKtiURl1nnz4QA3vKMYjhg?= =?us-ascii?Q?yNfHidBmpxCNcudMc3YNRUuzMHEtDPo+Ras/RnnjAvf4hMLO01JGDFfEWARW?= =?us-ascii?Q?jrYNYMPPNCH0llI/JxYQrAOk4ltwkiG5LV9UBvbEhZYwvAuSeRdt6NmiTIYJ?= =?us-ascii?Q?UV3l+rXFkjgLOrBVnKkCF9tHDb7pMhtF5SlJbZtrb0GHs6RZ09iqtjjYVuPS?= =?us-ascii?Q?qTOvgsW1mMkn1rhy3h29kpTqD3vAecyn/FNsIBf3k7X9v6bsmd0qSSphFaLi?= =?us-ascii?Q?CGqyzdhchzVWMxcFXvQWlb0dNsKPbhUGj+EHJahx7ptuqKgSLfeN1xdAUCzr?= =?us-ascii?Q?Gj8Ie+aO6cCG+cjnNsrxboiipkm5FzpukYVtStRBObv73NDoPCvWNK/K+NJs?= =?us-ascii?Q?BJpCF84sDbMV1jMyobW3vkGJbm66xSfe8cUgQVj5d5OWuNfM/J1c021zv83q?= =?us-ascii?Q?Bob3hm42VT8qLZtEMRmb+xxIrMASv0/ZzISMdBuFvwgAJg3KB8M++yUp750T?= =?us-ascii?Q?6XNnHItlbihJjFhfOoouUOJq42sJYaz3zFmxZVGwSeOsBJVKqMXl16mFaIMB?= =?us-ascii?Q?9Em0X01E7gYFCzyLH7qvbOzjcn87CuJQFA9fxeKf7MpWfMxU8y7Zw+lhVzn+?= =?us-ascii?Q?iteQpNFyByiwLL5xXPFWyJNdTDWAdjx+67llzwx0gr2cq77ST3z133qTDW3f?= =?us-ascii?Q?fmqjSg8CApchAtLR8LwLAMQ1tpW5lNpKWUGLaxq/RC8JuA4vCPry5qtIbAYI?= =?us-ascii?Q?6GmqqaLoyv5aewqrm0NYCLCy6Qloghny3Pfv7ZAzTA/kwOL15UOUuZTMjayh?= =?us-ascii?Q?SzSYIWGtuNtIxeRVhrJIJd1+nG8TVEPg3X0Z2+STUaza825yOf1aeLzOIP8u?= =?us-ascii?Q?pb3KeT906EbXdcXmkCrfwy/9FfafKBwEork=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR0601MB776; 5:YjBj0h4tlQiMB0Sr9VokHKZowSfKGt0ApEsApWTpzOWqyl5n2edXgbroRdPVQJMsEMzIemO71LPfvqd+qUEJwC0953+oIr13gIZfHkLYvSXUKWGCGrYgwmqdyxzqFgLX9ZlJ9Br3UQbcf23Ja/2M+A==; 24:EZ1slMrcuTqvdnXyNHbdhs9z/na+iYnIaSOvR7KwR7iRxefkC5uuUPJybFE4MHV54yO5SLU6JLD+gpuhhi6HroQcovvDRTr+VYyPjseRckw=; 20:w2DFbyLw6gf+luCvVPDsAhK4FpQZTS9aWahTJxpURBnG8D0IctJTO34pPHPRqmzGD+5x1+JKysbkuAZuCJhsWA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2015 13:18:20.4450 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0601MB776 Archived-At: Cc: Lisandro Zambenedetti Granville , codematch-develop , Henrik Levkowetz , Robert Sparks Subject: Re: [Codematch-develop] DataTracker and CodeMatch access control X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 13:18:48 -0000 --Apple-Mail=_32E448A0-C94B-45C2-BF16-BB7194A16B62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Robert, can you join the call? I wasn=E2=80=99t in Hawaii so I may have missed some discussions. Making = it independent will probably simplify many things and will let us put it = online faster.=20 Anyway, we would like to be "Datatracker complaint=E2=80=9D to simplify = the integration in the future. Christian O'Flaherty - oflaherty@isoc.org Regional Development - Internet Society=20 Skype/Gmail/Yahoo!: christian.oflaherty=20 Phone: +598 98769636 > On Sep 15, 2015, at 10:54 PM, Moriarty, Kathleen = wrote: >=20 > Hi Robert, >=20 > Thank you, here is the call information for tomorrow: >=20 > JOIN WEBEX MEETING > = https://isoc.webex.com/isoc/j.php?MTID=3Dmcf3b8c886b81a58535ea02c3ba3ba940= > Meeting number: 926 480 716 > Meeting password: coder >=20 >=20 > JOIN BY PHONE > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 926 480 716 >=20 > Global call-in numbers: > = https://isoc.webex.com/isoc/globalcallin.php?serviceType=3DMC&ED=3D3220993= 32&tollFree=3D0 >=20 > Best regards, > Kathleen=20 >=20 > Sent from my iPhone >=20 >> On Sep 15, 2015, at 6:39 PM, Robert Sparks = wrote: >>=20 >>=20 >>=20 >>> On 9/15/15 5:33 PM, Robert Sparks wrote: >>> I thought the calls were on Tuesdays - when did that change? >> Ignore that part - I see they've been mostly on Wednesdays for a long = time. >> Please forward the coordinates? (I don't know if I can make tomorrow, = but if I can move a meeting I'll be there). >>=20 >> RjS >> _______________________________________________ >> Codematch-develop mailing list >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop >=20 > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop --Apple-Mail=_32E448A0-C94B-45C2-BF16-BB7194A16B62 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Hi Robert,  can you join the call?

I wasn=E2=80=99t in Hawaii so I may = have missed some discussions. Making it independent will probably = simplify many things and will let us put it online = faster. 

Anyway, we would like to be "Datatracker complaint=E2=80=9D = to simplify the integration in the future.

Christian = O'Flaherty - oflaherty@isoc.org
Regional Development - Internet Society 
Skype/Gmail/Yahoo!:=  christian.oflaherty 
Phone: +598 = 98769636

On Sep 15, 2015, at 10:54 PM, Moriarty, Kathleen <kathleen.moriarty@emc.com> wrote:

Hi Robert,

Thank you, here is the call information for = tomorrow:

JOIN WEBEX MEETING
https://isoc.webex.com/isoc/j.php?MTID=3Dmcf3b8c886b81a58535ea0= 2c3ba3ba940
Meeting number: 926 480 716
Meeting password: coder


JOIN BY PHONE
1-650-479-3208 Call-in toll = number (US/Canada)
Access code: 926 480 716

Global call-in numbers:
https://isoc.webex.com/isoc/globalcallin.php?serviceType=3DMC&a= mp;ED=3D322099332&tollFree=3D0

Best = regards,
Kathleen

Sent from = my iPhone

On Sep 15, 2015, at 6:39 PM, Robert Sparks = <rjsparks@nostrum.com> wrote:



On = 9/15/15 5:33 PM, Robert Sparks wrote:
I thought the calls = were on Tuesdays - when did that change?
Ignore= that part - I see they've been mostly on Wednesdays for a long time.
Please forward the coordinates? (I don't know if I can make = tomorrow, but if I can move a meeting I'll be there).

RjS
_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

= --Apple-Mail=_32E448A0-C94B-45C2-BF16-BB7194A16B62-- From nobody Wed Sep 16 06:23:07 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BB11B384E for ; Wed, 16 Sep 2015 06:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=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 UsqMQQakH0FL for ; Wed, 16 Sep 2015 06:23:04 -0700 (PDT) Received: from mail.lacnic.net.uy (hermes.lacnic.net.uy [IPv6:2001:13c7:7001:4000::8]) by ietfa.amsl.com (Postfix) with ESMTP id 908251B3810 for ; Wed, 16 Sep 2015 06:23:03 -0700 (PDT) Received: from hermes.lacnic.net.uy (localhost [127.0.0.1]) by mail.lacnic.net.uy (Postfix) with ESMTP id A2D5016B40A55 for ; Wed, 16 Sep 2015 10:23:01 -0300 (UYT) X-Virus-Scanned: amavisd-new at lacnic.net.uy Received: from mail.lacnic.net.uy ([127.0.0.1]) by hermes.lacnic.net.uy (mail.lacnic.net.uy [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLCcD4r_lYXX for ; Wed, 16 Sep 2015 10:23:00 -0300 (UYT) Received: from [IPv6:2001:13c7:7001:7128:14b5:bcfd:4819:5427] (unknown [IPv6:2001:13c7:7001:7128:14b5:bcfd:4819:5427]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.lacnic.net.uy (Postfix) with ESMTPSA id D502016B40725 for ; Wed, 16 Sep 2015 10:23:00 -0300 (UYT) Message-ID: <55F96D34.5020608@lacnic.net> Date: Wed, 16 Sep 2015 10:23:00 -0300 From: =?windows-1252?Q?Nicol=E1s?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: codematch-develop@ietf.org References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> <55DE0CB3.8020001@nostrum.com> <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> <55DF0B7B.7020902@levkowetz.com> <9B6DB401-A599-4C19-857C-D64241FC467B@inf.ufrgs.br> <55F89CAB.1060207@nostrum.com> <55F89E0B.7030602@nostrum.com> <8D85CDF3-9C77-46E6-B6B9-4A52EBCC9FC3@isoc.org> In-Reply-To: <8D85CDF3-9C77-46E6-B6B9-4A52EBCC9FC3@isoc.org> Content-Type: multipart/alternative; boundary="------------030105030706080003080004" Archived-At: Subject: Re: [Codematch-develop] DataTracker and CodeMatch access control X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 13:23:06 -0000 This is a multi-part message in MIME format. --------------030105030706080003080004 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sorry, I cannot attend the call today because full of work. I look forward to see the recording in the aft*. Best regards, Nico. El 16/09/15 a las 10:18, Christian O'Flaherty escibi: > Hi Robert, can you join the call? > > I wasnt in Hawaii so I may have missed some discussions. Making it > independent will probably simplify many things and will let us put it > online faster. > > Anyway, we would like to be "Datatracker complaint to simplify the > integration in the future. > > Christian O'Flaherty - oflaherty@isoc.org > Regional Development -Internet Society > Skype/Gmail/Yahoo!: christian.oflaherty > Phone:+598 98769636 > >> On Sep 15, 2015, at 10:54 PM, Moriarty, Kathleen >> > wrote: >> >> Hi Robert, >> >> Thank you, here is the call information for tomorrow: >> >> JOIN WEBEX MEETING >> https://isoc.webex.com/isoc/j.php?MTID=mcf3b8c886b81a58535ea02c3ba3ba940 >> Meeting number: 926 480 716 >> Meeting password: coder >> >> >> JOIN BY PHONE >> 1-650-479-3208 Call-in toll number (US/Canada) >> Access code: 926 480 716 >> >> Global call-in numbers: >> https://isoc.webex.com/isoc/globalcallin.php?serviceType=MC&ED=322099332&tollFree=0 >> >> Best regards, >> Kathleen >> >> Sent from my iPhone >> >>> On Sep 15, 2015, at 6:39 PM, Robert Sparks wrote: >>> >>> >>> >>>> On 9/15/15 5:33 PM, Robert Sparks wrote: >>>> I thought the calls were on Tuesdays - when did that change? >>> Ignore that part - I see they've been mostly on Wednesdays for a >>> long time. >>> Please forward the coordinates? (I don't know if I can make >>> tomorrow, but if I can move a meeting I'll be there). >>> >>> RjS >>> _______________________________________________ >>> Codematch-develop mailing list >>> Codematch-develop@ietf.org >>> https://www.ietf.org/mailman/listinfo/codematch-develop >> >> _______________________________________________ >> Codematch-develop mailing list >> Codematch-develop@ietf.org >> https://www.ietf.org/mailman/listinfo/codematch-develop > > > > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop --------------030105030706080003080004 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Sorry, I cannot attend the call today because full of work.

I look forward to see the recording in the aft*.

Best regards,

Nico.

El 16/09/15 a las 10:18, Christian O'Flaherty escibi:
Hi Robert, can you join the call?

I wasnt in Hawaii so I may have missed some discussions. Making it independent will probably simplify many things and will let us put it online faster.

Anyway, we would like to be "Datatracker complaint to simplify the integration in the future.

Christian O'Flaherty -oflaherty@isoc.org
Regional Development -Internet Society
Skype/Gmail/Yahoo!: christian.oflaherty
Phone:+598 98769636

On Sep 15, 2015, at 10:54 PM, Moriarty, Kathleen <kathleen.moriarty@emc.com> wrote:

Hi Robert,

Thank you, here is the call information for tomorrow:

JOIN WEBEX MEETING
https://isoc.webex.com/isoc/j.php?MTID=mcf3b8c886b81a58535ea02c3ba3ba940
Meeting number: 926 480 716
Meeting password: coder


JOIN BY PHONE
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 926 480 716

Global call-in numbers:
https://isoc.webex.com/isoc/globalcallin.php?serviceType=MC&ED=322099332&tollFree=0

Best regards,
Kathleen

Sent from my iPhone

On Sep 15, 2015, at 6:39 PM, Robert Sparks <rjsparks@nostrum.com> wrote:



On 9/15/15 5:33 PM, Robert Sparks wrote:
I thought the calls were on Tuesdays - when did that change?
Ignore that part - I see they've been mostly on Wednesdays for a long time.
Please forward the coordinates? (I don't know if I can make tomorrow, but if I can move a meeting I'll be there).

RjS
_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop



_______________________________________________
Codematch-develop mailing list
Codematch-develop@ietf.org
https://www.ietf.org/mailman/listinfo/codematch-develop

--------------030105030706080003080004-- From nobody Wed Sep 16 11:13:44 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EFE1A87A6 for ; Wed, 16 Sep 2015 11:13:42 -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 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 xS-XCzTPgnte for ; Wed, 16 Sep 2015 11:13:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB231A1BB9 for ; Wed, 16 Sep 2015 11:13:38 -0700 (PDT) Received: from localhost ([::1]:36660 helo=vigonier.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZcHD1-0000sr-1p; Wed, 16 Sep 2015 11:13:31 -0700 To: Christian O'Flaherty References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> <55DE0CB3.8020001@nostrum.com> <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> <55DF0B7B.7020902@levkowetz.com> <9B6DB401-A599-4C19-857C-D64241FC467B@inf.ufrgs.br> From: Henrik Levkowetz Message-ID: <55F9B0A7.6000508@levkowetz.com> Date: Wed, 16 Sep 2015 20:10:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9tPdsBPlEu2MvtCM2TnQdNcWJ8EnjGIVr" X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik-sent@levkowetz.com, granville@inf.ufrgs.br, rjsparks@nostrum.com, codematch-develop@ietf.org, oflaherty@isoc.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: Lisandro Zambenedetti Granville , codematch-develop , Robert Sparks Subject: Re: [Codematch-develop] DataTracker and CodeMatch access control X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 18:13:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9tPdsBPlEu2MvtCM2TnQdNcWJ8EnjGIVr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Christian, Working through my inbox: On 2015-09-16 00:06, Christian O'Flaherty wrote: > H Henrik,=20 >=20 > I don=E2=80=99t want to be pushy but we will have our codematch call to= morrow and we would like to discuss this part: >=20 >> We will need an assessment soon to check what=E2=80=99s missing to be = =E2=80=9Cappropriate=E2=80=9D and what would be the next steps to be part= of a Datatracker release. >=20 >=20 > Can you help us or join our call tomorrow at 16 UTC ? Umm. The email above landed in my inbox "today" at 6 minutes past midnig= ht. I don't know which "tomorrow" you refer to -- a date would be easier. If= the tomorrow you were thinking of were today, then it's obviously too lat= e. Possibly Robert made it? Sorry, Henrik > Thanks, >=20 > Christian O'Flaherty - oflaherty@isoc.org > Regional Development - Internet Society=20 > Skype/Gmail/Yahoo!: christian.oflaherty=20 > Phone: +598 98769636 >=20 >> On Sep 4, 2015, at 10:57 AM, Christian O'Flaherty = wrote: >>=20 >> Hi Henrik, >>=20 >> We will follow your advise on permissions and roles.=20 >> The Datamodel and readability issues (conventions on variable names an= d class attributes) were also fixed (those that you flagged when we start= ed coding). >>=20 >> We will need an assessment soon to check what=E2=80=99s missing to be = =E2=80=9Cappropriate=E2=80=9D and what would be the next steps to be part= of a Datatracker release. >>=20 >> Can you help us with that?=20 >>=20 >> Christian O'Flaherty - oflaherty@isoc.org >> Regional Development - Internet Society=20 >> Skype/Gmail/Yahoo!: christian.oflaherty=20 >> Phone: +598 98769636 >>=20 >>> On Aug 27, 2015, at 3:30 PM, Lisandro Zambenedetti Granville > wrote: >>>=20 >>> Hello Henrik >>>=20 >>> Thanks for all clarifications. Going to the most important question: >>>=20 >>> "Could we agree on starting an RBAC implementation using has_role(), = and >>> once we have a bit more experience, and only then, consider taking on= >>> the added complexity and technical debt of using 2 different permissi= on >>> handling systems in this non-COTS software?=E2=80=9D >>>=20 >>> Definitely yes. I=E2=80=99m convinced, after reading your arguments, = that having two different permission solutions in the same framework can = be ok for CodeMatch but it wouldn=E2=80=99t be ok for datatracker. An you= r suggestion of concentrating now more on who can/cannot do what should b= e a priority. >>>=20 >>> Best regards, >>>=20 >>> Lisandro >>>=20 >>>> Em 27/08/2015, =C3=A0(s) 10:07, Henrik Levkowetz > escreveu: >>>>=20 >>>> Hi Lisandro, >>>>=20 >>>> Jumping in here with some comments: >>>>=20 >>>> On 2015-08-26 21:38, Lisandro Zambenedetti Granville wrote: >>>>> Hello Robert >>>>>=20 >>>>>>>> You are not necessarily restricted to the Role names that are >>>>>>>> defined now (like "chair"). We could add Role names like=20 >>>>>>>> "codematcher" or "codematch_approver" or whatever other name >>>>>>>> matches the semantic for the permission you're wanting to >>>>>>>> manage. >>>>>>>=20 >>>>>>> That=E2=80=99s great, so that we can expand the current Roles wit= hout >>>>>>> changing the data model. >>>>>>>=20 >>>>>>>> You could then have things like Lisandro Granville is >>>>>>>> codematch_approver in nmrg. >>>>>>>=20 >>>>>>> That is also what we need. >>>>>>=20 >>>>>> Just to be sure - you're saying that's sufficient, and while you'r= e >>>>>> explaining the idea further below, you don't need it right now? >>>>>=20 >>>>> Sorry, I was not clear. Creating new Roles and allowing users being= >>>>> assigned to these new Roles are things that we need in CodeMatch to= o. >>>>> Further below I mention something that we are proposing (i.e., >>>>> has_right) in addition to having new roles. >>>>>=20 >>>>=20 >>>>>>>> Does that address the need? If not, could you walk me though a >>>>>>>> scenario where it makes it harder than it should? >>>>>>>=20 >>>>>>> What you mention above is the link among users, roles, and >>>>>>> groups. There is another link between roles and permissions that >>>>>>> seems to be hardcoded in datatracker. When we say >>>>>>>=20 >>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", "Secreta= riat=E2=80=9D]): >>>>>>> // do things the user with "permission X" can do >>>>>>>=20 >>>>>>> it implies that if we want to grant to, e.g., >>>>>>> =E2=80=9Ccodematch_approver=E2=80=9D the =E2=80=9Cpermission X=E2= =80=9D above, we should go back >>>>>>> to the code and change it to >>>>>>>=20 >>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", >>>>>>> =E2=80=9CSecretariat=E2=80=9D, =E2=80=9Ccodematch_approver"]):...= >>>>>>>=20 >>>>>>> We were then considering the possibility of moving the link >>>>>>> between roles and permission to the data model and implement >>>>>>> has_right (or has_permission) like: >>>>>>>=20 >>>>>>> if has_right(request.user, =E2=80=9Cpermission X=E2=80=9D): >>>>>>> // do things the user with "permission X" can do >>>>>>>=20 >>>>>>> If we want =E2=80=9Cpermission X=E2=80=9D to be granted to other = roles, that >>>>>>> would be a matter of including the proper records in the >>>>>>> database, instead of changing the code. >>>>>>>=20 >>>>>>> Trying not to go too much into details, the summary is that we >>>>>>> want to check if assigning permission to roles is ok to be done >>>>>>> in the database, instead of changing the code. >>>>>>=20 >>>>>> Well, you still have to type has_right(...) in the code, and >>>>>> specify something concrete in that has_right that would have to >>>>>> change, so I don't think we're really talking about avoiding >>>>>> changing code as much as we are about _where_ you model the idea o= f >>>>>> a permission in the database. >>>>>=20 >>>>> I agree. We are talking about modeling the link between roles and >>>>> permission in the database. >>>>=20 >>>> So, the design you propose is elegant and matches the way permission= s >>>> are handled in many contexts, especially in COTS software (and for >>>> that matter, user-configurable FOSS software). >>>>=20 >>>> It is more flexible, but also has an added complexity, and an added >>>> abstraction level (in order to be useful, the permissions need to be= >>>> named with names which express what effect they are having in the co= de, >>>> and this may be non-trivial). >>>>=20 >>>> There is however one point you don't bring up, which I would like to= >>>> bring up here. >>>>=20 >>>> Summarizing the two ways of writing the code, we can either have cod= e >>>> which says >>>>=20 >>>> if has_role(user, ["CodeMatch Approver"]): >>>> # code to be exectuted >>>>=20 >>>> or code which says >>>>=20 >>>> if has_perm(user, ["approve codematch"]): >>>> # code to be exectuted >>>>=20 >>>> For IETF roles, the list of possible roles are very well codified, >>>> while the only way to know which permissions that need to be named >>>> and listed in a role_auth_permission table is to go through the >>>> code and name all the places we check for roles today. Naming those= >>>> permissions, and making clear the correspondence between the names >>>> and the actual effect they will have in code is not necessarily >>>> trivial. >>>>=20 >>>> For the Codematch project, it may be that you have a much better gra= sp >>>> of the named permissions needed, and not so good a grasp of the role= s. >>>>=20 >>>> However, since irrespective of how the correspondence between roles = and >>>> code is handled, whether it is via has_role() or has_perm(), you act= ually >>>> _need_ to be able to describe the roles well, I would suggest that y= ou >>>> probably also have a much better grasp of the roles than of all the >>>> named permissions which may be needed. >>>>=20 >>>> Given that, I would suggest that you start out with the same approac= h >>>> which has been used in the current datatracker code, and once it is >>>> possible to inspect the code and see which actual places need to che= ck >>>> for different roles in order to determine if a given piece of code m= ay >>>> be executed, _and_ you have experience with the tool so that you can= >>>> speak with confidence about which actions a given role should or sho= uld >>>> not have, then _at that point_ we can consider refining things into >>>> roles and permissions, instead of listing roles explicitly in the co= de. >>>>=20 >>>> More below. >>>>=20 >>>>>> I think the real essence of what we're talking about is the >>>>>> difference in how you would implement "Give all the WG chairs >>>>>> codematch-approval rights". >>>>>>=20 >>>>>> With your proposal, you would make a role to permission match to d= o >>>>>> that - one database row change - pretty efficient (*) With what we= >>>>>> have now, you just add a Role of "codematch-approval" to any Perso= n >>>>>> that has a wg chair role. So, I think what you're proposing is an >>>>>> optimization, and it comes with some complexity. We can keep >>>>>> talking about it, but I don't think we're at the point that we nee= d >>>>>> it. >>>>>=20 >>>>> This complexity involves: >>>>>=20 >>>>> a) Creating a new intermediate table =E2=80=9Crole_auth_permission"= composed >>>>> of, at least, two columns: role_id and auth_permission_id; >>>>>=20 >>>>> b) Creating the function "has_right (user, permission_label)" which= >>>>> given the user it retrieves the user=E2=80=99s roles, from roles it= retrieves >>>>> permissions and, among permissions, it checks if permission_label i= s >>>>> present. >>>>>=20 >>>>> Of course, the effort of doing a) and b) would be ours. And these >>>>> implementation would be used in CodeMatch only; it wouldn=E2=80=99t= be >>>>> changing or affecting DataTracker. >>>>=20 >>>> Understood. But for the datatracker, there is the added complexity = of >>>> maintaining code which uses 2 different mechanisms to handle permiss= ions. >>>> And that the technical debt of carrying two different solutions forw= ard >>>> is something you will not have to suffer, but the datatracker projec= t >>>> will have to deal with. >>>>=20 >>>>>> (*) But, it's not really that easy. Right now we have a role of >>>>>> "chair" that is applied to all groups. There's no way to speak >>>>>> differently about WG chairs and RG chairs by simply saying "chair"= >>>>>> - it takes more code. We have chairs of Teams, and _could_ have >>>>>> (but don't currently) chairs of other SDOs in the database. So, th= e >>>>>> apparent simplicity of matching a permission to a role-name isn't >>>>>> as strong as it first appears. >>>>>=20 >>>>> While coding the CodeMatch system, we notice that some portions of >>>>> the system may be or may be not available to different user roles. >>>>> Although we define somes roles now, changes on role-permissions wil= l >>>>> probably happen along the development process. >>>>=20 >>>> Agreed. In which case, doing the necessary has_role() or has_perm()= =20 >>>> code changes will most likely happen along with other code changes. >>>>=20 >>>>> The permissions we want the roles to have define, let me say, the >>>>> policy of CodeMatch. We wanted to decouple that policy from the >>>>> system implementation itself, thus implementing an RBAC model; if t= he >>>>> link between roles and permissions (i.e., the system policy) migrat= es >>>>> to the database, we can tag CodeMatch source code (i.e., define >>>>> permission labels) and redefine which roles are able to access >>>>> different parts of the system. Notice, this is just for CodeMatch, = of >>>>> course. >>>>=20 >>>> RBAC can be implemented both with has_role() and has_perm(); the dif= ference >>>> lies in how easy it is to reconfigure the permissions which are asso= ciated >>>> with a given role. >>>>=20 >>>> For COTS software, where you cannot easily adapt the code itself to = the >>>> customer environment and wishes, other than through data lookup, the= >>>> approach you suggest makes a lot of sense. For our case, where ther= e is >>>> one and only one production system, it is far less important, and it= is >>>> not obvious that the added complexity and technical debt incurred is= >>>> offset by the added flexibility. >>>>=20 >>>> Please also consider the pace with which we release software for the= >>>> datatracker: Formal releases are shown in the page: >>>>=20 >>>> https://datatracker.ietf.org/release/ >>>>=20 >>>> and in addition to that, we often apply patches. As an example, we >>>> have done 10 formal releases within the 6.x.y series, but during the= >>>> same time, we have applied 36 patches, resulting in 20 patch release= >>>> numbers in addition to the formal release numbers. With this releas= e >>>> pace, and with the possibility of applying patches, we are probably= >>>> agile enough to handle the necessary code changes almost as fast as = you >>>> could agree on what needs to be done and change the settings in a=20 >>>> role_auth_permission table. >>>>=20 >>>> Could we agree on starting an RBAC implementation using has_role(), = and >>>> once we have a bit more experience, and only then, consider taking o= n >>>> the added complexity and technical debt of using 2 different permiss= ion >>>> handling systems in this non-COTS software? >>>>=20 >>>>=20 >>>> Best regards, >>>>=20 >>>> Henrik >>>>=20 >>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Lisandro >>>>>=20 >>>>>>> We are of course talking about the CodeMatch code only; we are no= t talking about the datatracker code at all, although examples were inspi= red by has_role, which is used in datatracker. >>>>>>>=20 >>>>>>> Lisandro >>>>>>>=20 >>>>>>>> On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote: >>>>>>>>> Dear All >>>>>>>>>=20 >>>>>>>>> Last week we had our traditional CodeMatch meeting. One of the = questions discussed in the meeting was about role-based access control (R= BAC) in CodeMatch. We would like to propose adding an extra table in the = current data model to support RBAC. However, because we want to be as ali= gned with DataTracker style as possible, we are sending this message to s= tart a discussion, specially with Henrik and Robert. >>>>>>>>>=20 >>>>>>>>> 1) Style of checking users=E2=80=99 permission >>>>>>>>>=20 >>>>>>>>> We observed the DataTracker code and it seems that in general, = permission checking is hardcoded, in the following style (using =E2=80=9C= Area Director=E2=80=9D, =E2=80=9CIAB Chair=E2=80=9D, and =E2=80=9CSecreta= riat" as examples): >>>>>>>>>=20 >>>>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", "Secre= tariat"]): >>>>>>>>> // do something that only area diretor, IAB chair, and secreta= riat could do, like =E2=80=9CCreate CodeRequest" >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> In CodeMatch, we would like to check permissions in the followi= ng way: >>>>>>>>>=20 >>>>>>>>> if has_right(request.user, =E2=80=9CCreate CodeRequest=E2=80=9D= ): >>>>>>>>> // do something that only authorized people should be able to = do, like =E2=80=9CCreate CodeRequest=E2=80=9D >>>>>>>>>=20 >>>>>>>>> The =E2=80=9Chas_right=E2=80=9D function would check the databa= se to retrieve the users=E2=80=99 roles and, for each role, check if it h= as permission to =E2=80=9CCreate CodeRequest=E2=80=9D. In this way, permi= ssions are associated to roles, and roles associated to users. >>>>>>>>>=20 >>>>>>>>> Because permissions and roles in CodeMatch are being defined to= gether with the implementation of the system prototype, the use of =E2=80= =9Chas_right=E2=80=9D would allow us to assign permissions to roles just = changing the database, instead of changing the CodeMatch code if we use =E2= =80=9Chas_role=E2=80=9D instead. >>>>>>>>>=20 >>>>>>>>> 2) Database >>>>>>>>>=20 >>>>>>>>> Today, permissions are listed in table auth_permission. Roles a= re listed in table group_role. We would need a intermediate table linking= permissions to roles, i.e., a table linking author_permissions and group= _role. That would allow us to say, for example, that a mentor (inside gro= up_role) can add documents to a codeRequest (i.e., a permission inside au= th_permission). Adding this intermediate table (let=E2=80=99s call it rol= e_permission for the moment) would not affect today=E2=80=99s database, a= lthough it would expand today=E2=80=99s data model. >>>>>>>>>=20 >>>>>>>>> Do you think doing that is ok? >>>>>>>>>=20 >>>>>>>>> Best regards, >>>>>>>>>=20 >>>>>>>>> Lisandro, Wanderson, Matheus >>>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Codematch-develop mailing list >>>>>>>> Codematch-develop@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>> _______________________________________________ >>> Codematch-develop mailing list >>> Codematch-develop@ietf.org >>> https://www.ietf.org/mailman/listinfo/codematch-develop >>=20 >=20 >=20 --9tPdsBPlEu2MvtCM2TnQdNcWJ8EnjGIVr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJV+bCoAAoJEE6bV0uPuxcahtoQAJ8b46hkl8683hs02/Wmpqw7 TW+RuipDiQFIxVPqYXmiWQBgSljFL/bGR/SixgmuXEXXWViD8JioDj9x841BB69/ tFhLf4Ycyghk/zPYYYjteGmFWZQVv4a8V56x6xN4wskwApwtSBVQSvP72BOxrVbq uA2Zp8txXdzFkucyk6fPBBPlaoopOldd1cfNBTyrAC6tKdFlTrOKrsCJD593UNxT OR89l8K8iNO9jWgy/B/74pmGHe8WPv9hQ1Uo7qLvinhveDmNrrrMiMVabAojVzPb 8p4ukEJd18puv+vKczyuVKjsmXm1I+71yXOZn+AIkRvGoD7t3Y5o8rKDbIgQA+sf S3oJ6T68NsDM8b+BvDG1UhzexSi0DJ1y7P4O1MLHS0t+yWz7/s85C7fR/khzjvmn QeTVAAdtxgP/KnTk/FQ5GvNlF3hkJaNIZd3ualAzMSzHSI49PgxSGI5Vlw9wGzhG LMXUziwmDEyMAYGKtfH9FpN+jHoXOnp7jwFHRAQH1IT6Tmk9cQaP2w5j3Xq6OUBH FcVKeLM/PbJV1KPiqDJIuv9Zf60Ek8/MLBJreeAQP8b7xsgryhPgci0o8obqMk0G 4TS0ocwCEmrFHKr7dToUoZDYdJ//n7CKk6wHjmDe0NWpQP6Dx8iYqNfTif7whaph psIMafGlxTFYPTjp4ops =Hj2I -----END PGP SIGNATURE----- --9tPdsBPlEu2MvtCM2TnQdNcWJ8EnjGIVr-- From nobody Wed Sep 16 11:21:13 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F201A8842 for ; Wed, 16 Sep 2015 11:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 4460f5nbDEqu for ; Wed, 16 Sep 2015 11:21:03 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0681.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:681]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DD41A8840 for ; Wed, 16 Sep 2015 11:21:03 -0700 (PDT) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=oflaherty@isoc.org; Received: from [10.0.1.13] (167.61.109.53) by CO2PR0601MB776.namprd06.prod.outlook.com (10.141.247.140) with Microsoft SMTP Server (TLS) id 15.1.262.15; Wed, 16 Sep 2015 18:20:39 +0000 MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset="utf-8" From: Christian O'Flaherty In-Reply-To: <55F9B0A7.6000508@levkowetz.com> Date: Wed, 16 Sep 2015 15:20:32 -0300 Content-Transfer-Encoding: quoted-printable Message-ID: <3B51404C-4597-4E26-86AC-1EF55DF53F66@isoc.org> References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> <55DE0CB3.8020001@nostrum.com> <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> <55DF0B7B.7020902@levkowetz.com> <9B6DB401-A599-4C19-857C-D64241FC467B@inf.ufrgs.br> <55F9B0A7.6000508@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.2104) X-Originating-IP: [167.61.109.53] X-ClientProxiedBy: SN1PR0701CA0027.namprd07.prod.outlook.com (25.162.96.37) To CO2PR0601MB776.namprd06.prod.outlook.com (10.141.247.140) X-Microsoft-Exchange-Diagnostics: 1; CO2PR0601MB776; 2:jjFsV9wrlXtCK4IFf8lqf+n5Ne8DGFonWw0VPgMCLSVTf6G6k7uND02JLtiwiN1ti+KqQXeE+fIdRfcBqBq5JK+qzvyOL5F+Yh+6FC27/rTJZqHIxJhicGGFHvXDwsFE78Q8y/3eBK+9xb5946ElcM4rmU1BiBZh1O6QXSjqU50=; 3:kfE29d64O9icBafZbs3S/6gaGio0QltpqfbYi5AD++p1gC0UG1EKLqSc3O8qaKoNi85sx0g+roiFdckVylJW3vyN38lt2TJbFzHaQm2IXUY76romoqackOz2OfMEiv5pkRnTCZnP8/14pFqvsOBCuQ==; 25:zJRmVB/77Yrl/hvLbNpKWgpagylDA4Hn3NJ6msN0z2yU8WSj2uxTGNHCpyHjLN+xz4y/qum8qyA61GahP78EfNJfvL2MC6/do/N9VUrSDVWgBsT14ZkQgD9G5k5SgueC+lkMLDJ28SJeW7wA6AMxb/4Yly2JYzZeMTEv7on4sFjVf+dHeZWovmg25jYyCgo+Y60TuSKEWBugD+fAVrw5a6PwxDBQ8UhDAsDH26/1O7+TbtgIFDhxmN3WIbGcjWQ/F3DWib9NCGKeI5IjF7INyQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR0601MB776; X-Microsoft-Exchange-Diagnostics: 1; CO2PR0601MB776; 20:9aLYi4Sc8Hiyrti2JGYIoQ4RhGmVSrNz774MPdP12n81wvXsNaSxwwU1CkiURJpEpM36PZi7L/iJTbe/xDYmRvhMmbzKVCsIXkAk6n+/wNOMYWfjEv3WgJuFGNpu04lB7bVle3h6N9/hRwU79ZueoucDu6TYbHmwD5ag5yHiuSvQ2NpaP4L9BI7I6WicFlRALadq1PGru6CFGYjSoIVFllwcwuBRIXzUAHmN6c5/g23rannIrQqz0C3KEbRNDTB72IumyF+D8IcVGDq10lgWXqEctnhqdp1NLPUF+4VH2/xQPPbR9YZ+gBBSdppx9TKNg6kmt5GjuaaOq2T9W1ElCD3M/QqIQZO/8qjd1ySwLGDhGB5gmvjjpsFIA1qMzxwCCff19Mo/eSDzvPh8rwomqLj9W2kWYRstl+s3OKiXQPePgfaFwJt+uWfmxg/GTWnBrwcJzmH11e/TOILqc4sPsPWRgSn6Qi5gyNuDPhwoTVpYPsBoHyKcfOu5ex03QThM; 4:+5avnVcvMGgwES0/ILi63B7MvzIZr8MqaSE6z6PmUmLEkAXH9l9at2cnsYCsZ5QwUlN/VFJjphKYl9dHgABhSiln7JQKhhY/dDR/t3qelYBFDPynrKh1bFUNAILnfx/c4qmE4YjGPRdR9IohxJKAz/OoFvi9fH7aRS5VI/IbnTDKZ8j/l5a6Nuqf2rg9PjQ3sA76mO+6fiFhGFY19IwfkxMRLRkMrc3KrtD0HFC1kzM1zucUtAuvJREvw5saS5s89obEqbV+A5lflKQ5eES5WAfRWbXSMtA90aKFWD8kXnxyYha+0s6eb6QO7Tv/fNCK3cTVkmnRxQ4/ImE6RCiKdBj5eOGJLt6tUq6e5csAnSS6REgiFChWUtMm/Ww6Nppw X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520075)(520078)(520058)(8121501046)(3002001); SRVR:CO2PR0601MB776; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0601MB776; X-Forefront-PRVS: 07013D7479 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(6049001)(377424004)(189002)(199003)(479174004)(377454003)(164054003)(24454002)(69224002)(92566002)(5001960100002)(110136002)(40100003)(5001830100001)(105586002)(42186005)(33656002)(122386002)(50466002)(561944003)(5001860100001)(36756003)(86362001)(106356001)(77156002)(97736004)(4001540100001)(19580405001)(62966003)(15975445007)(5007970100001)(81156007)(189998001)(64706001)(19580395003)(57306001)(2950100001)(77096005)(23676002)(50986999)(47776003)(66066001)(68736005)(5004730100002)(101416001)(46102003)(83716003)(76176999)(50226001)(93886004)(87976001)(82746002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR0601MB776; H:[10.0.1.13]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjA2MDFNQjc3NjsyMzpXU2xhTzJWNm95MXVoQ2p1MFkrUlE2enZj?= =?utf-8?B?V0E5U3N5ZzFEM0VqbnlhL3M5L2J1WjVhblRneDluUDV0cmtpT3A1REd0U01z?= =?utf-8?B?TmlpMnM3Y0R5dERtQlRya1pZQjUxUEpRTEFKMHJzbVZSTDE3TmY2VHFmWlZU?= =?utf-8?B?QnI2UEp4RnVEM3M0WW5ySTg1M0NRMXpQTUo2VU1jUTI4WnNuc2JISC9ZVTdH?= =?utf-8?B?NWI3UmIzZU5kRE5waWllbllpSkJhZzZsUGFUUVl0aDdyS3lqSWEzUDZWWE1W?= =?utf-8?B?aWhhRVQ1NmVHK3A4L2s0TjF3NGFyd2w0MnphYWI2OE5aUXR0Q00yVVJLNThp?= =?utf-8?B?Z2lDZzQwOUJnT29Cbzk1TWxXMG9MOWY0WkhIZ1VLMlNWVllBNmFJU2REM09S?= =?utf-8?B?SVlMUXErcXFKZXJIZE5pSDBBYlQ4TnRGdWxhT0NlcHVuVXJzZGtOTjRVNlBY?= =?utf-8?B?VVlaY2Nyb3JnYVg5RDU0NENqZ0hFaGxHak92dnZsS1hIVVZEcVVhYWp1Z2pW?= =?utf-8?B?d0I5OFE0N1BBVXQrWERrbVBZR2o2NzBrd1hlRzRRYjRVQUpYQkVJOUFKQk9t?= =?utf-8?B?VEliYjBKTDdmWmtqbVI5RFcwSndJTEJ2Z1NPMjZNRkhSajgzOFNzU1JRWFcx?= =?utf-8?B?UkY5ZUYxOWcxK0NVZGF3R2RuVWZFVnVydDdud3JjL1B5UkNybXNmTmNKL1Y4?= =?utf-8?B?SDQ4RFNPTmVzREhtaWoxb3kyNHEzbFNlODRaU0hSaWw1bUVVNXNVVFlBSFVw?= =?utf-8?B?R245V0o3Vk5vTER3M3FNSTZOWWZMOW9Ba1RlV1dFQXhnYVBsa3pGbVlCNy9X?= =?utf-8?B?c2d0VDZQaFR4QUpPMm5WL1VjMFF2MllYbDlPeEh1S3cxRGNvOXhSMm43UnJt?= =?utf-8?B?WnJKd1d1RnF3M1EvMmpmK1dSMzBGS1lveTdGYWt3ZU1OZGJjbDM5a3hOaTVL?= =?utf-8?B?RUFTdGdldWRDSEd2ZHhNaThKejVqTnh0ZVEzalUyeitKL2N6NndZQjQ2OEls?= =?utf-8?B?VHBxaEhqci82cnh5MTRRTDFIWkJ5d0xMVnZ2eEdsTXVqZTJlcjFZcFl0TEhM?= =?utf-8?B?cmQ3T0JiWmN4SHFKd1NwKzBVdzQyZTlveHNGL1czZlQwTjcyb0ZtR2RLL3g5?= =?utf-8?B?UDBLOFZrdys4M2ozS1BnL2htNmY3Ukt3SWdrdVd5RklTTmxqRnRHMmdLeTRu?= =?utf-8?B?bjVkcE1Nb0ZZSThuOGQ1TXJYTjdpc2szKzBtZ3NNRFNORTVoOWQxMVBsNlNV?= =?utf-8?B?OUtQeGVmbUV1d3BmT292dXZwbGdXWkxnanN1eEZkN0xOckExSGhPWlIyeUtB?= =?utf-8?B?S1dlOGJNMGl0amRsVmkzb1JmOHMrSUhPL2V2SXZMcVNOMTVxeUNvOTErbnpN?= =?utf-8?B?MzYzSFRRN1UzQ21mTm8xQmRoSmxuOGRabHE5U2NEajNLRC9BOFd6STRjREJP?= =?utf-8?B?ek5HTk9xTE44MDdXbzVodFlmRDZNVkRaSysxTjVUNUhwaDhPUUxkUlcyMXRP?= =?utf-8?B?ejZLV1NmVUFQSDcxM2tGc0RVMXRiRVhJZVFKaHBhd3ZlNkFiV0NJRGNPVHpV?= =?utf-8?B?dWxNQlhaUVA2N1ZGV0F1bm9Qc2w4enQ0MzdGd2JvY3B6UXpsbTd5YTFud3dm?= =?utf-8?B?TlYza29GWWpmaEpvazJ0Uy9ockwraUN1QmdwaGpDK094dCt6NUlVVHVnM0lY?= =?utf-8?B?Y0QwZXdKSGdoZzluNmRSSjNGbC9IU1FKK1ViSWlXVjJXemxHZ0RMbXpScWNx?= =?utf-8?B?dnpEeVczR0FKMVJPYUNuejRUZmZlOFp1U3BJbitrSWR3WUQ2dW1VcExvVUcz?= =?utf-8?B?U2tqWDBwdTM1eDZ1RElZYzhXbkgyTUxUd2tMS014VGRtUXIrYXVvVEYyd2hG?= =?utf-8?B?SXdUd0RoQ0JDUy9QVHdnVTVRY05lM1hGU0ZTNjdybXpLaGorNVVscmliQXhM?= =?utf-8?B?ZnhpelBMM2N2Zz09?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR0601MB776; 5:boPIfox2NqZJvYaljnina2xF8YiH2ZGhqZkLZgqsPEXrcVMMiD204V1stn8dkDDEkcJ7jtvgIMYIAtSjeHLE0czpx9WY+cG3CgEqs+jSzm5LDnBssChNtsKJsSi0VsCMzVXXtmGx4oOuEeVbVtW6yA==; 24:rkqbiWj1wLv2xFboRvqJ2Dpbu/CnEC6JJU8jxHv4gMYK/cCfFuPGSN2BvKY4QNSxdas916UOWY7r4in9pY+bhcTWi7J5jrWlEemd2gORVNg=; 20:cBiIWq9VAUSxroJLpwKxM8PGglSU8i2mfeJEoTS7ezK/F1wWE2WDNHk1ACL6j3I7Aq1t7ulvwZRxfT6TC6rtlw== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2015 18:20:39.7833 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0601MB776 Archived-At: Cc: Lisandro Zambenedetti Granville , codematch-develop , Robert Sparks Subject: Re: [Codematch-develop] DataTracker and CodeMatch access control X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 18:21:09 -0000 >>=20 >> Can you help us or join our call tomorrow at 16 UTC ? >=20 > Umm. The email above landed in my inbox "today" at 6 minutes past = midnight. >=20 > I don't know which "tomorrow" you refer to -- a date would be easier. = If > the tomorrow you were thinking of were today, then it's obviously too = late. >=20 > Possibly Robert made it? Yes, he made it and it was very helpful.=20 I=E2=80=99m learning about using multiple databases with a read-only = access to Datatracker.=20 Some questions coming soon :-) Christian >=20 > Sorry, >=20 > Henrik >=20 >> Thanks, >>=20 >> Christian O'Flaherty - oflaherty@isoc.org >> Regional Development - Internet Society=20 >> Skype/Gmail/Yahoo!: christian.oflaherty=20 >> Phone: +598 98769636 >>=20 >>> On Sep 4, 2015, at 10:57 AM, Christian O'Flaherty = wrote: >>>=20 >>> Hi Henrik, >>>=20 >>> We will follow your advise on permissions and roles.=20 >>> The Datamodel and readability issues (conventions on variable names = and class attributes) were also fixed (those that you flagged when we = started coding). >>>=20 >>> We will need an assessment soon to check what=E2=80=99s missing to = be =E2=80=9Cappropriate=E2=80=9D and what would be the next steps to be = part of a Datatracker release. >>>=20 >>> Can you help us with that?=20 >>>=20 >>> Christian O'Flaherty - oflaherty@isoc.org = >>> Regional Development - Internet Society=20 >>> Skype/Gmail/Yahoo!: christian.oflaherty=20 >>> Phone: +598 98769636 >>>=20 >>>> On Aug 27, 2015, at 3:30 PM, Lisandro Zambenedetti Granville = > wrote: >>>>=20 >>>> Hello Henrik >>>>=20 >>>> Thanks for all clarifications. Going to the most important = question: >>>>=20 >>>> "Could we agree on starting an RBAC implementation using = has_role(), and >>>> once we have a bit more experience, and only then, consider taking = on >>>> the added complexity and technical debt of using 2 different = permission >>>> handling systems in this non-COTS software?=E2=80=9D >>>>=20 >>>> Definitely yes. I=E2=80=99m convinced, after reading your = arguments, that having two different permission solutions in the same = framework can be ok for CodeMatch but it wouldn=E2=80=99t be ok for = datatracker. An your suggestion of concentrating now more on who = can/cannot do what should be a priority. >>>>=20 >>>> Best regards, >>>>=20 >>>> Lisandro >>>>=20 >>>>> Em 27/08/2015, =C3=A0(s) 10:07, Henrik Levkowetz = > escreveu: >>>>>=20 >>>>> Hi Lisandro, >>>>>=20 >>>>> Jumping in here with some comments: >>>>>=20 >>>>> On 2015-08-26 21:38, Lisandro Zambenedetti Granville wrote: >>>>>> Hello Robert >>>>>>=20 >>>>>>>>> You are not necessarily restricted to the Role names that are >>>>>>>>> defined now (like "chair"). We could add Role names like=20 >>>>>>>>> "codematcher" or "codematch_approver" or whatever other name >>>>>>>>> matches the semantic for the permission you're wanting to >>>>>>>>> manage. >>>>>>>>=20 >>>>>>>> That=E2=80=99s great, so that we can expand the current Roles = without >>>>>>>> changing the data model. >>>>>>>>=20 >>>>>>>>> You could then have things like Lisandro Granville is >>>>>>>>> codematch_approver in nmrg. >>>>>>>>=20 >>>>>>>> That is also what we need. >>>>>>>=20 >>>>>>> Just to be sure - you're saying that's sufficient, and while = you're >>>>>>> explaining the idea further below, you don't need it right now? >>>>>>=20 >>>>>> Sorry, I was not clear. Creating new Roles and allowing users = being >>>>>> assigned to these new Roles are things that we need in CodeMatch = too. >>>>>> Further below I mention something that we are proposing (i.e., >>>>>> has_right) in addition to having new roles. >>>>>>=20 >>>>>=20 >>>>>>>>> Does that address the need? If not, could you walk me though a >>>>>>>>> scenario where it makes it harder than it should? >>>>>>>>=20 >>>>>>>> What you mention above is the link among users, roles, and >>>>>>>> groups. There is another link between roles and permissions = that >>>>>>>> seems to be hardcoded in datatracker. When we say >>>>>>>>=20 >>>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", = "Secretariat=E2=80=9D]): >>>>>>>> // do things the user with "permission X" can do >>>>>>>>=20 >>>>>>>> it implies that if we want to grant to, e.g., >>>>>>>> =E2=80=9Ccodematch_approver=E2=80=9D the =E2=80=9Cpermission = X=E2=80=9D above, we should go back >>>>>>>> to the code and change it to >>>>>>>>=20 >>>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", >>>>>>>> =E2=80=9CSecretariat=E2=80=9D, =E2=80=9Ccodematch_approver"]):...= >>>>>>>>=20 >>>>>>>> We were then considering the possibility of moving the link >>>>>>>> between roles and permission to the data model and implement >>>>>>>> has_right (or has_permission) like: >>>>>>>>=20 >>>>>>>> if has_right(request.user, =E2=80=9Cpermission X=E2=80=9D): >>>>>>>> // do things the user with "permission X" can do >>>>>>>>=20 >>>>>>>> If we want =E2=80=9Cpermission X=E2=80=9D to be granted to = other roles, that >>>>>>>> would be a matter of including the proper records in the >>>>>>>> database, instead of changing the code. >>>>>>>>=20 >>>>>>>> Trying not to go too much into details, the summary is that we >>>>>>>> want to check if assigning permission to roles is ok to be done >>>>>>>> in the database, instead of changing the code. >>>>>>>=20 >>>>>>> Well, you still have to type has_right(...) in the code, and >>>>>>> specify something concrete in that has_right that would have to >>>>>>> change, so I don't think we're really talking about avoiding >>>>>>> changing code as much as we are about _where_ you model the idea = of >>>>>>> a permission in the database. >>>>>>=20 >>>>>> I agree. We are talking about modeling the link between roles and >>>>>> permission in the database. >>>>>=20 >>>>> So, the design you propose is elegant and matches the way = permissions >>>>> are handled in many contexts, especially in COTS software (and for >>>>> that matter, user-configurable FOSS software). >>>>>=20 >>>>> It is more flexible, but also has an added complexity, and an = added >>>>> abstraction level (in order to be useful, the permissions need to = be >>>>> named with names which express what effect they are having in the = code, >>>>> and this may be non-trivial). >>>>>=20 >>>>> There is however one point you don't bring up, which I would like = to >>>>> bring up here. >>>>>=20 >>>>> Summarizing the two ways of writing the code, we can either have = code >>>>> which says >>>>>=20 >>>>> if has_role(user, ["CodeMatch Approver"]): >>>>> # code to be exectuted >>>>>=20 >>>>> or code which says >>>>>=20 >>>>> if has_perm(user, ["approve codematch"]): >>>>> # code to be exectuted >>>>>=20 >>>>> For IETF roles, the list of possible roles are very well codified, >>>>> while the only way to know which permissions that need to be named >>>>> and listed in a role_auth_permission table is to go through the >>>>> code and name all the places we check for roles today. Naming = those >>>>> permissions, and making clear the correspondence between the names >>>>> and the actual effect they will have in code is not necessarily >>>>> trivial. >>>>>=20 >>>>> For the Codematch project, it may be that you have a much better = grasp >>>>> of the named permissions needed, and not so good a grasp of the = roles. >>>>>=20 >>>>> However, since irrespective of how the correspondence between = roles and >>>>> code is handled, whether it is via has_role() or has_perm(), you = actually >>>>> _need_ to be able to describe the roles well, I would suggest that = you >>>>> probably also have a much better grasp of the roles than of all = the >>>>> named permissions which may be needed. >>>>>=20 >>>>> Given that, I would suggest that you start out with the same = approach >>>>> which has been used in the current datatracker code, and once it = is >>>>> possible to inspect the code and see which actual places need to = check >>>>> for different roles in order to determine if a given piece of code = may >>>>> be executed, _and_ you have experience with the tool so that you = can >>>>> speak with confidence about which actions a given role should or = should >>>>> not have, then _at that point_ we can consider refining things = into >>>>> roles and permissions, instead of listing roles explicitly in the = code. >>>>>=20 >>>>> More below. >>>>>=20 >>>>>>> I think the real essence of what we're talking about is the >>>>>>> difference in how you would implement "Give all the WG chairs >>>>>>> codematch-approval rights". >>>>>>>=20 >>>>>>> With your proposal, you would make a role to permission match to = do >>>>>>> that - one database row change - pretty efficient (*) With what = we >>>>>>> have now, you just add a Role of "codematch-approval" to any = Person >>>>>>> that has a wg chair role. So, I think what you're proposing is = an >>>>>>> optimization, and it comes with some complexity. We can keep >>>>>>> talking about it, but I don't think we're at the point that we = need >>>>>>> it. >>>>>>=20 >>>>>> This complexity involves: >>>>>>=20 >>>>>> a) Creating a new intermediate table =E2=80=9Crole_auth_permission"= composed >>>>>> of, at least, two columns: role_id and auth_permission_id; >>>>>>=20 >>>>>> b) Creating the function "has_right (user, permission_label)" = which >>>>>> given the user it retrieves the user=E2=80=99s roles, from roles = it retrieves >>>>>> permissions and, among permissions, it checks if permission_label = is >>>>>> present. >>>>>>=20 >>>>>> Of course, the effort of doing a) and b) would be ours. And these >>>>>> implementation would be used in CodeMatch only; it wouldn=E2=80=99t= be >>>>>> changing or affecting DataTracker. >>>>>=20 >>>>> Understood. But for the datatracker, there is the added = complexity of >>>>> maintaining code which uses 2 different mechanisms to handle = permissions. >>>>> And that the technical debt of carrying two different solutions = forward >>>>> is something you will not have to suffer, but the datatracker = project >>>>> will have to deal with. >>>>>=20 >>>>>>> (*) But, it's not really that easy. Right now we have a role of >>>>>>> "chair" that is applied to all groups. There's no way to speak >>>>>>> differently about WG chairs and RG chairs by simply saying = "chair" >>>>>>> - it takes more code. We have chairs of Teams, and _could_ have >>>>>>> (but don't currently) chairs of other SDOs in the database. So, = the >>>>>>> apparent simplicity of matching a permission to a role-name = isn't >>>>>>> as strong as it first appears. >>>>>>=20 >>>>>> While coding the CodeMatch system, we notice that some portions = of >>>>>> the system may be or may be not available to different user = roles. >>>>>> Although we define somes roles now, changes on role-permissions = will >>>>>> probably happen along the development process. >>>>>=20 >>>>> Agreed. In which case, doing the necessary has_role() or = has_perm()=20 >>>>> code changes will most likely happen along with other code = changes. >>>>>=20 >>>>>> The permissions we want the roles to have define, let me say, the >>>>>> policy of CodeMatch. We wanted to decouple that policy from the >>>>>> system implementation itself, thus implementing an RBAC model; if = the >>>>>> link between roles and permissions (i.e., the system policy) = migrates >>>>>> to the database, we can tag CodeMatch source code (i.e., define >>>>>> permission labels) and redefine which roles are able to access >>>>>> different parts of the system. Notice, this is just for = CodeMatch, of >>>>>> course. >>>>>=20 >>>>> RBAC can be implemented both with has_role() and has_perm(); the = difference >>>>> lies in how easy it is to reconfigure the permissions which are = associated >>>>> with a given role. >>>>>=20 >>>>> For COTS software, where you cannot easily adapt the code itself = to the >>>>> customer environment and wishes, other than through data lookup, = the >>>>> approach you suggest makes a lot of sense. For our case, where = there is >>>>> one and only one production system, it is far less important, and = it is >>>>> not obvious that the added complexity and technical debt incurred = is >>>>> offset by the added flexibility. >>>>>=20 >>>>> Please also consider the pace with which we release software for = the >>>>> datatracker: Formal releases are shown in the page: >>>>>=20 >>>>> https://datatracker.ietf.org/release/ = >>>>>=20 >>>>> and in addition to that, we often apply patches. As an example, = we >>>>> have done 10 formal releases within the 6.x.y series, but during = the >>>>> same time, we have applied 36 patches, resulting in 20 patch = release >>>>> numbers in addition to the formal release numbers. With this = release >>>>> pace, and with the possibility of applying patches, we are = probably >>>>> agile enough to handle the necessary code changes almost as fast = as you >>>>> could agree on what needs to be done and change the settings in a=20= >>>>> role_auth_permission table. >>>>>=20 >>>>> Could we agree on starting an RBAC implementation using = has_role(), and >>>>> once we have a bit more experience, and only then, consider taking = on >>>>> the added complexity and technical debt of using 2 different = permission >>>>> handling systems in this non-COTS software? >>>>>=20 >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Henrik >>>>>=20 >>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Lisandro >>>>>>=20 >>>>>>>> We are of course talking about the CodeMatch code only; we are = not talking about the datatracker code at all, although examples were = inspired by has_role, which is used in datatracker. >>>>>>>>=20 >>>>>>>> Lisandro >>>>>>>>=20 >>>>>>>>> On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote: >>>>>>>>>> Dear All >>>>>>>>>>=20 >>>>>>>>>> Last week we had our traditional CodeMatch meeting. One of = the questions discussed in the meeting was about role-based access = control (RBAC) in CodeMatch. We would like to propose adding an extra = table in the current data model to support RBAC. However, because we = want to be as aligned with DataTracker style as possible, we are sending = this message to start a discussion, specially with Henrik and Robert. >>>>>>>>>>=20 >>>>>>>>>> 1) Style of checking users=E2=80=99 permission >>>>>>>>>>=20 >>>>>>>>>> We observed the DataTracker code and it seems that in = general, permission checking is hardcoded, in the following style (using = =E2=80=9CArea Director=E2=80=9D, =E2=80=9CIAB Chair=E2=80=9D, and = =E2=80=9CSecretariat" as examples): >>>>>>>>>>=20 >>>>>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", = "Secretariat"]): >>>>>>>>>> // do something that only area diretor, IAB chair, and = secretariat could do, like =E2=80=9CCreate CodeRequest" >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> In CodeMatch, we would like to check permissions in the = following way: >>>>>>>>>>=20 >>>>>>>>>> if has_right(request.user, =E2=80=9CCreate CodeRequest=E2=80=9D= ): >>>>>>>>>> // do something that only authorized people should be = able to do, like =E2=80=9CCreate CodeRequest=E2=80=9D >>>>>>>>>>=20 >>>>>>>>>> The =E2=80=9Chas_right=E2=80=9D function would check the = database to retrieve the users=E2=80=99 roles and, for each role, check = if it has permission to =E2=80=9CCreate CodeRequest=E2=80=9D. In this = way, permissions are associated to roles, and roles associated to users. >>>>>>>>>>=20 >>>>>>>>>> Because permissions and roles in CodeMatch are being defined = together with the implementation of the system prototype, the use of = =E2=80=9Chas_right=E2=80=9D would allow us to assign permissions to = roles just changing the database, instead of changing the CodeMatch code = if we use =E2=80=9Chas_role=E2=80=9D instead. >>>>>>>>>>=20 >>>>>>>>>> 2) Database >>>>>>>>>>=20 >>>>>>>>>> Today, permissions are listed in table auth_permission. Roles = are listed in table group_role. We would need a intermediate table = linking permissions to roles, i.e., a table linking author_permissions = and group_role. That would allow us to say, for example, that a mentor = (inside group_role) can add documents to a codeRequest (i.e., a = permission inside auth_permission). Adding this intermediate table = (let=E2=80=99s call it role_permission for the moment) would not affect = today=E2=80=99s database, although it would expand today=E2=80=99s data = model. >>>>>>>>>>=20 >>>>>>>>>> Do you think doing that is ok? >>>>>>>>>>=20 >>>>>>>>>> Best regards, >>>>>>>>>>=20 >>>>>>>>>> Lisandro, Wanderson, Matheus >>>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> Codematch-develop mailing list >>>>>>>>> Codematch-develop@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Codematch-develop mailing list >>>> Codematch-develop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>=20 >>=20 >>=20 >=20 From nobody Wed Sep 16 11:21:47 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6371A8837 for ; Wed, 16 Sep 2015 11:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 DVQiMwaNsaCw for ; Wed, 16 Sep 2015 11:21:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083CC1A87EB for ; Wed, 16 Sep 2015 11:21:33 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8GILWcc055426 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 16 Sep 2015 13:21:32 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local To: Henrik Levkowetz , "Christian O'Flaherty" References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> <55DE0CB3.8020001@nostrum.com> <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> <55DF0B7B.7020902@levkowetz.com> <9B6DB401-A599-4C19-857C-D64241FC467B@inf.ufrgs.br> <55F9B0A7.6000508@levkowetz.com> From: Robert Sparks Message-ID: <55F9B327.8010708@nostrum.com> Date: Wed, 16 Sep 2015 13:21:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55F9B0A7.6000508@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Lisandro Zambenedetti Granville , codematch-develop Subject: Re: [Codematch-develop] DataTracker and CodeMatch access control X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 18:21:40 -0000 On 9/16/15 1:10 PM, Henrik Levkowetz wrote: > Hi Christian, > > Working through my inbox: > > On 2015-09-16 00:06, Christian O'Flaherty wrote: >> H Henrik, >> >> I don’t want to be pushy but we will have our codematch call tomorrow and we would like to discuss this part: >> >>> We will need an assessment soon to check what’s missing to be “appropriate” and what would be the next steps to be part of a Datatracker release. >> >> Can you help us or join our call tomorrow at 16 UTC ? > Umm. The email above landed in my inbox "today" at 6 minutes past midnight. > > I don't know which "tomorrow" you refer to -- a date would be easier. If > the tomorrow you were thinking of were today, then it's obviously too late. > > Possibly Robert made it? I did - I'll find you on IM and talk through the call. Kathleen also recorded it I believe. > > Sorry, > > Henrik > >> Thanks, >> >> Christian O'Flaherty - oflaherty@isoc.org >> Regional Development - Internet Society >> Skype/Gmail/Yahoo!: christian.oflaherty >> Phone: +598 98769636 >> >>> On Sep 4, 2015, at 10:57 AM, Christian O'Flaherty wrote: >>> >>> Hi Henrik, >>> >>> We will follow your advise on permissions and roles. >>> The Datamodel and readability issues (conventions on variable names and class attributes) were also fixed (those that you flagged when we started coding). >>> >>> We will need an assessment soon to check what’s missing to be “appropriate” and what would be the next steps to be part of a Datatracker release. >>> >>> Can you help us with that? >>> >>> Christian O'Flaherty - oflaherty@isoc.org >>> Regional Development - Internet Society >>> Skype/Gmail/Yahoo!: christian.oflaherty >>> Phone: +598 98769636 >>> >>>> On Aug 27, 2015, at 3:30 PM, Lisandro Zambenedetti Granville > wrote: >>>> >>>> Hello Henrik >>>> >>>> Thanks for all clarifications. Going to the most important question: >>>> >>>> "Could we agree on starting an RBAC implementation using has_role(), and >>>> once we have a bit more experience, and only then, consider taking on >>>> the added complexity and technical debt of using 2 different permission >>>> handling systems in this non-COTS software?” >>>> >>>> Definitely yes. I’m convinced, after reading your arguments, that having two different permission solutions in the same framework can be ok for CodeMatch but it wouldn’t be ok for datatracker. An your suggestion of concentrating now more on who can/cannot do what should be a priority. >>>> >>>> Best regards, >>>> >>>> Lisandro >>>> >>>>> Em 27/08/2015, à(s) 10:07, Henrik Levkowetz > escreveu: >>>>> >>>>> Hi Lisandro, >>>>> >>>>> Jumping in here with some comments: >>>>> >>>>> On 2015-08-26 21:38, Lisandro Zambenedetti Granville wrote: >>>>>> Hello Robert >>>>>> >>>>>>>>> You are not necessarily restricted to the Role names that are >>>>>>>>> defined now (like "chair"). We could add Role names like >>>>>>>>> "codematcher" or "codematch_approver" or whatever other name >>>>>>>>> matches the semantic for the permission you're wanting to >>>>>>>>> manage. >>>>>>>> That’s great, so that we can expand the current Roles without >>>>>>>> changing the data model. >>>>>>>> >>>>>>>>> You could then have things like Lisandro Granville is >>>>>>>>> codematch_approver in nmrg. >>>>>>>> That is also what we need. >>>>>>> Just to be sure - you're saying that's sufficient, and while you're >>>>>>> explaining the idea further below, you don't need it right now? >>>>>> Sorry, I was not clear. Creating new Roles and allowing users being >>>>>> assigned to these new Roles are things that we need in CodeMatch too. >>>>>> Further below I mention something that we are proposing (i.e., >>>>>> has_right) in addition to having new roles. >>>>>> >>>>>>>>> Does that address the need? If not, could you walk me though a >>>>>>>>> scenario where it makes it harder than it should? >>>>>>>> What you mention above is the link among users, roles, and >>>>>>>> groups. There is another link between roles and permissions that >>>>>>>> seems to be hardcoded in datatracker. When we say >>>>>>>> >>>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", "Secretariat”]): >>>>>>>> // do things the user with "permission X" can do >>>>>>>> >>>>>>>> it implies that if we want to grant to, e.g., >>>>>>>> “codematch_approver” the “permission X” above, we should go back >>>>>>>> to the code and change it to >>>>>>>> >>>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", >>>>>>>> “Secretariat”, “codematch_approver"]):... >>>>>>>> >>>>>>>> We were then considering the possibility of moving the link >>>>>>>> between roles and permission to the data model and implement >>>>>>>> has_right (or has_permission) like: >>>>>>>> >>>>>>>> if has_right(request.user, “permission X”): >>>>>>>> // do things the user with "permission X" can do >>>>>>>> >>>>>>>> If we want “permission X” to be granted to other roles, that >>>>>>>> would be a matter of including the proper records in the >>>>>>>> database, instead of changing the code. >>>>>>>> >>>>>>>> Trying not to go too much into details, the summary is that we >>>>>>>> want to check if assigning permission to roles is ok to be done >>>>>>>> in the database, instead of changing the code. >>>>>>> Well, you still have to type has_right(...) in the code, and >>>>>>> specify something concrete in that has_right that would have to >>>>>>> change, so I don't think we're really talking about avoiding >>>>>>> changing code as much as we are about _where_ you model the idea of >>>>>>> a permission in the database. >>>>>> I agree. We are talking about modeling the link between roles and >>>>>> permission in the database. >>>>> So, the design you propose is elegant and matches the way permissions >>>>> are handled in many contexts, especially in COTS software (and for >>>>> that matter, user-configurable FOSS software). >>>>> >>>>> It is more flexible, but also has an added complexity, and an added >>>>> abstraction level (in order to be useful, the permissions need to be >>>>> named with names which express what effect they are having in the code, >>>>> and this may be non-trivial). >>>>> >>>>> There is however one point you don't bring up, which I would like to >>>>> bring up here. >>>>> >>>>> Summarizing the two ways of writing the code, we can either have code >>>>> which says >>>>> >>>>> if has_role(user, ["CodeMatch Approver"]): >>>>> # code to be exectuted >>>>> >>>>> or code which says >>>>> >>>>> if has_perm(user, ["approve codematch"]): >>>>> # code to be exectuted >>>>> >>>>> For IETF roles, the list of possible roles are very well codified, >>>>> while the only way to know which permissions that need to be named >>>>> and listed in a role_auth_permission table is to go through the >>>>> code and name all the places we check for roles today. Naming those >>>>> permissions, and making clear the correspondence between the names >>>>> and the actual effect they will have in code is not necessarily >>>>> trivial. >>>>> >>>>> For the Codematch project, it may be that you have a much better grasp >>>>> of the named permissions needed, and not so good a grasp of the roles. >>>>> >>>>> However, since irrespective of how the correspondence between roles and >>>>> code is handled, whether it is via has_role() or has_perm(), you actually >>>>> _need_ to be able to describe the roles well, I would suggest that you >>>>> probably also have a much better grasp of the roles than of all the >>>>> named permissions which may be needed. >>>>> >>>>> Given that, I would suggest that you start out with the same approach >>>>> which has been used in the current datatracker code, and once it is >>>>> possible to inspect the code and see which actual places need to check >>>>> for different roles in order to determine if a given piece of code may >>>>> be executed, _and_ you have experience with the tool so that you can >>>>> speak with confidence about which actions a given role should or should >>>>> not have, then _at that point_ we can consider refining things into >>>>> roles and permissions, instead of listing roles explicitly in the code. >>>>> >>>>> More below. >>>>> >>>>>>> I think the real essence of what we're talking about is the >>>>>>> difference in how you would implement "Give all the WG chairs >>>>>>> codematch-approval rights". >>>>>>> >>>>>>> With your proposal, you would make a role to permission match to do >>>>>>> that - one database row change - pretty efficient (*) With what we >>>>>>> have now, you just add a Role of "codematch-approval" to any Person >>>>>>> that has a wg chair role. So, I think what you're proposing is an >>>>>>> optimization, and it comes with some complexity. We can keep >>>>>>> talking about it, but I don't think we're at the point that we need >>>>>>> it. >>>>>> This complexity involves: >>>>>> >>>>>> a) Creating a new intermediate table “role_auth_permission" composed >>>>>> of, at least, two columns: role_id and auth_permission_id; >>>>>> >>>>>> b) Creating the function "has_right (user, permission_label)" which >>>>>> given the user it retrieves the user’s roles, from roles it retrieves >>>>>> permissions and, among permissions, it checks if permission_label is >>>>>> present. >>>>>> >>>>>> Of course, the effort of doing a) and b) would be ours. And these >>>>>> implementation would be used in CodeMatch only; it wouldn’t be >>>>>> changing or affecting DataTracker. >>>>> Understood. But for the datatracker, there is the added complexity of >>>>> maintaining code which uses 2 different mechanisms to handle permissions. >>>>> And that the technical debt of carrying two different solutions forward >>>>> is something you will not have to suffer, but the datatracker project >>>>> will have to deal with. >>>>> >>>>>>> (*) But, it's not really that easy. Right now we have a role of >>>>>>> "chair" that is applied to all groups. There's no way to speak >>>>>>> differently about WG chairs and RG chairs by simply saying "chair" >>>>>>> - it takes more code. We have chairs of Teams, and _could_ have >>>>>>> (but don't currently) chairs of other SDOs in the database. So, the >>>>>>> apparent simplicity of matching a permission to a role-name isn't >>>>>>> as strong as it first appears. >>>>>> While coding the CodeMatch system, we notice that some portions of >>>>>> the system may be or may be not available to different user roles. >>>>>> Although we define somes roles now, changes on role-permissions will >>>>>> probably happen along the development process. >>>>> Agreed. In which case, doing the necessary has_role() or has_perm() >>>>> code changes will most likely happen along with other code changes. >>>>> >>>>>> The permissions we want the roles to have define, let me say, the >>>>>> policy of CodeMatch. We wanted to decouple that policy from the >>>>>> system implementation itself, thus implementing an RBAC model; if the >>>>>> link between roles and permissions (i.e., the system policy) migrates >>>>>> to the database, we can tag CodeMatch source code (i.e., define >>>>>> permission labels) and redefine which roles are able to access >>>>>> different parts of the system. Notice, this is just for CodeMatch, of >>>>>> course. >>>>> RBAC can be implemented both with has_role() and has_perm(); the difference >>>>> lies in how easy it is to reconfigure the permissions which are associated >>>>> with a given role. >>>>> >>>>> For COTS software, where you cannot easily adapt the code itself to the >>>>> customer environment and wishes, other than through data lookup, the >>>>> approach you suggest makes a lot of sense. For our case, where there is >>>>> one and only one production system, it is far less important, and it is >>>>> not obvious that the added complexity and technical debt incurred is >>>>> offset by the added flexibility. >>>>> >>>>> Please also consider the pace with which we release software for the >>>>> datatracker: Formal releases are shown in the page: >>>>> >>>>> https://datatracker.ietf.org/release/ >>>>> >>>>> and in addition to that, we often apply patches. As an example, we >>>>> have done 10 formal releases within the 6.x.y series, but during the >>>>> same time, we have applied 36 patches, resulting in 20 patch release >>>>> numbers in addition to the formal release numbers. With this release >>>>> pace, and with the possibility of applying patches, we are probably >>>>> agile enough to handle the necessary code changes almost as fast as you >>>>> could agree on what needs to be done and change the settings in a >>>>> role_auth_permission table. >>>>> >>>>> Could we agree on starting an RBAC implementation using has_role(), and >>>>> once we have a bit more experience, and only then, consider taking on >>>>> the added complexity and technical debt of using 2 different permission >>>>> handling systems in this non-COTS software? >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Henrik >>>>> >>>>> >>>>>> Thanks, >>>>>> >>>>>> Lisandro >>>>>> >>>>>>>> We are of course talking about the CodeMatch code only; we are not talking about the datatracker code at all, although examples were inspired by has_role, which is used in datatracker. >>>>>>>> >>>>>>>> Lisandro >>>>>>>> >>>>>>>>> On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote: >>>>>>>>>> Dear All >>>>>>>>>> >>>>>>>>>> Last week we had our traditional CodeMatch meeting. One of the questions discussed in the meeting was about role-based access control (RBAC) in CodeMatch. We would like to propose adding an extra table in the current data model to support RBAC. However, because we want to be as aligned with DataTracker style as possible, we are sending this message to start a discussion, specially with Henrik and Robert. >>>>>>>>>> >>>>>>>>>> 1) Style of checking users’ permission >>>>>>>>>> >>>>>>>>>> We observed the DataTracker code and it seems that in general, permission checking is hardcoded, in the following style (using “Area Director”, “IAB Chair”, and “Secretariat" as examples): >>>>>>>>>> >>>>>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", "Secretariat"]): >>>>>>>>>> // do something that only area diretor, IAB chair, and secretariat could do, like “Create CodeRequest" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> In CodeMatch, we would like to check permissions in the following way: >>>>>>>>>> >>>>>>>>>> if has_right(request.user, “Create CodeRequest”): >>>>>>>>>> // do something that only authorized people should be able to do, like “Create CodeRequest” >>>>>>>>>> >>>>>>>>>> The “has_right” function would check the database to retrieve the users’ roles and, for each role, check if it has permission to “Create CodeRequest”. In this way, permissions are associated to roles, and roles associated to users. >>>>>>>>>> >>>>>>>>>> Because permissions and roles in CodeMatch are being defined together with the implementation of the system prototype, the use of “has_right” would allow us to assign permissions to roles just changing the database, instead of changing the CodeMatch code if we use “has_role” instead. >>>>>>>>>> >>>>>>>>>> 2) Database >>>>>>>>>> >>>>>>>>>> Today, permissions are listed in table auth_permission. Roles are listed in table group_role. We would need a intermediate table linking permissions to roles, i.e., a table linking author_permissions and group_role. That would allow us to say, for example, that a mentor (inside group_role) can add documents to a codeRequest (i.e., a permission inside auth_permission). Adding this intermediate table (let’s call it role_permission for the moment) would not affect today’s database, although it would expand today’s data model. >>>>>>>>>> >>>>>>>>>> Do you think doing that is ok? >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> >>>>>>>>>> Lisandro, Wanderson, Matheus >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Codematch-develop mailing list >>>>>>>>> Codematch-develop@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>>>> >>>> _______________________________________________ >>>> Codematch-develop mailing list >>>> Codematch-develop@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codematch-develop >> From nobody Wed Sep 16 11:24:51 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560951A8840 for ; Wed, 16 Sep 2015 11:24:50 -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 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 45cnGsRebn13 for ; Wed, 16 Sep 2015 11:24:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8420C1A8837 for ; Wed, 16 Sep 2015 11:24:46 -0700 (PDT) Received: from localhost ([::1]:37263 helo=vigonier.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZcHNp-0004hU-UW; Wed, 16 Sep 2015 11:24:42 -0700 To: Christian O'Flaherty References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> <55DE0CB3.8020001@nostrum.com> <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> <55DF0B7B.7020902@levkowetz.com> <9B6DB401-A599-4C19-857C-D64241FC467B@inf.ufrgs.br> <55F9B0A7.6000508@levkowetz.com> <3B51404C-4597-4E26-86AC-1EF55DF53F66@isoc.org> From: Henrik Levkowetz Message-ID: <55F9B346.7080306@levkowetz.com> Date: Wed, 16 Sep 2015 20:21:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <3B51404C-4597-4E26-86AC-1EF55DF53F66@isoc.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j2hsw4i2OJ9GWOAmcWeSG3avrKUMngtJD" X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik-sent@levkowetz.com, granville@inf.ufrgs.br, rjsparks@nostrum.com, codematch-develop@ietf.org, oflaherty@isoc.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: Lisandro Zambenedetti Granville , codematch-develop , Robert Sparks Subject: Re: [Codematch-develop] DataTracker and CodeMatch access control X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 18:24:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j2hsw4i2OJ9GWOAmcWeSG3avrKUMngtJD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Christian, On 2015-09-16 20:20, Christian O'Flaherty wrote: >=20 >>>=20 >>> Can you help us or join our call tomorrow at 16 UTC ? >>=20 >> Umm. The email above landed in my inbox "today" at 6 minutes past mid= night. >>=20 >> I don't know which "tomorrow" you refer to -- a date would be easier. = If >> the tomorrow you were thinking of were today, then it's obviously too = late. >>=20 >> Possibly Robert made it? >=20 > Yes, he made it and it was very helpful.=20 >=20 > I=E2=80=99m learning about using multiple databases with a read-only ac= cess to Datatracker.=20 > Some questions coming soon :-) Aha. Splendid. Best regards, Henrik > Christian >=20 >>=20 >> Sorry, >>=20 >> Henrik >>=20 >>> Thanks, >>>=20 >>> Christian O'Flaherty - oflaherty@isoc.org = >>> Regional Development - Internet Society=20 >>> Skype/Gmail/Yahoo!: christian.oflaherty=20 >>> Phone: +598 98769636 >>>=20 >>>> On Sep 4, 2015, at 10:57 AM, Christian O'Flaherty wrote: >>>>=20 >>>> Hi Henrik, >>>>=20 >>>> We will follow your advise on permissions and roles.=20 >>>> The Datamodel and readability issues (conventions on variable names = and class attributes) were also fixed (those that you flagged when we sta= rted coding). >>>>=20 >>>> We will need an assessment soon to check what=E2=80=99s missing to b= e =E2=80=9Cappropriate=E2=80=9D and what would be the next steps to be pa= rt of a Datatracker release. >>>>=20 >>>> Can you help us with that?=20 >>>>=20 >>>> Christian O'Flaherty - oflaherty@isoc.org >>>> Regional Development - Internet Society=20 >>>> Skype/Gmail/Yahoo!: christian.oflaherty=20 >>>> Phone: +598 98769636 >>>>=20 >>>>> On Aug 27, 2015, at 3:30 PM, Lisandro Zambenedetti Granville > wrote: >>>>>=20 >>>>> Hello Henrik >>>>>=20 >>>>> Thanks for all clarifications. Going to the most important question= : >>>>>=20 >>>>> "Could we agree on starting an RBAC implementation using has_role()= , and >>>>> once we have a bit more experience, and only then, consider taking = on >>>>> the added complexity and technical debt of using 2 different permis= sion >>>>> handling systems in this non-COTS software?=E2=80=9D >>>>>=20 >>>>> Definitely yes. I=E2=80=99m convinced, after reading your arguments= , that having two different permission solutions in the same framework ca= n be ok for CodeMatch but it wouldn=E2=80=99t be ok for datatracker. An y= our suggestion of concentrating now more on who can/cannot do what should= be a priority. >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Lisandro >>>>>=20 >>>>>> Em 27/08/2015, =C3=A0(s) 10:07, Henrik Levkowetz > escreveu: >>>>>>=20 >>>>>> Hi Lisandro, >>>>>>=20 >>>>>> Jumping in here with some comments: >>>>>>=20 >>>>>> On 2015-08-26 21:38, Lisandro Zambenedetti Granville wrote: >>>>>>> Hello Robert >>>>>>>=20 >>>>>>>>>> You are not necessarily restricted to the Role names that are >>>>>>>>>> defined now (like "chair"). We could add Role names like=20 >>>>>>>>>> "codematcher" or "codematch_approver" or whatever other name >>>>>>>>>> matches the semantic for the permission you're wanting to >>>>>>>>>> manage. >>>>>>>>>=20 >>>>>>>>> That=E2=80=99s great, so that we can expand the current Roles w= ithout >>>>>>>>> changing the data model. >>>>>>>>>=20 >>>>>>>>>> You could then have things like Lisandro Granville is >>>>>>>>>> codematch_approver in nmrg. >>>>>>>>>=20 >>>>>>>>> That is also what we need. >>>>>>>>=20 >>>>>>>> Just to be sure - you're saying that's sufficient, and while you= 're >>>>>>>> explaining the idea further below, you don't need it right now? >>>>>>>=20 >>>>>>> Sorry, I was not clear. Creating new Roles and allowing users bei= ng >>>>>>> assigned to these new Roles are things that we need in CodeMatch = too. >>>>>>> Further below I mention something that we are proposing (i.e., >>>>>>> has_right) in addition to having new roles. >>>>>>>=20 >>>>>>=20 >>>>>>>>>> Does that address the need? If not, could you walk me though a= >>>>>>>>>> scenario where it makes it harder than it should? >>>>>>>>>=20 >>>>>>>>> What you mention above is the link among users, roles, and >>>>>>>>> groups. There is another link between roles and permissions tha= t >>>>>>>>> seems to be hardcoded in datatracker. When we say >>>>>>>>>=20 >>>>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", "Secre= tariat=E2=80=9D]): >>>>>>>>> // do things the user with "permission X" can do >>>>>>>>>=20 >>>>>>>>> it implies that if we want to grant to, e.g., >>>>>>>>> =E2=80=9Ccodematch_approver=E2=80=9D the =E2=80=9Cpermission X=E2= =80=9D above, we should go back >>>>>>>>> to the code and change it to >>>>>>>>>=20 >>>>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", >>>>>>>>> =E2=80=9CSecretariat=E2=80=9D, =E2=80=9Ccodematch_approver"]):.= =2E. >>>>>>>>>=20 >>>>>>>>> We were then considering the possibility of moving the link >>>>>>>>> between roles and permission to the data model and implement >>>>>>>>> has_right (or has_permission) like: >>>>>>>>>=20 >>>>>>>>> if has_right(request.user, =E2=80=9Cpermission X=E2=80=9D): >>>>>>>>> // do things the user with "permission X" can do >>>>>>>>>=20 >>>>>>>>> If we want =E2=80=9Cpermission X=E2=80=9D to be granted to othe= r roles, that >>>>>>>>> would be a matter of including the proper records in the >>>>>>>>> database, instead of changing the code. >>>>>>>>>=20 >>>>>>>>> Trying not to go too much into details, the summary is that we >>>>>>>>> want to check if assigning permission to roles is ok to be done= >>>>>>>>> in the database, instead of changing the code. >>>>>>>>=20 >>>>>>>> Well, you still have to type has_right(...) in the code, and >>>>>>>> specify something concrete in that has_right that would have to >>>>>>>> change, so I don't think we're really talking about avoiding >>>>>>>> changing code as much as we are about _where_ you model the idea= of >>>>>>>> a permission in the database. >>>>>>>=20 >>>>>>> I agree. We are talking about modeling the link between roles and= >>>>>>> permission in the database. >>>>>>=20 >>>>>> So, the design you propose is elegant and matches the way permissi= ons >>>>>> are handled in many contexts, especially in COTS software (and for= >>>>>> that matter, user-configurable FOSS software). >>>>>>=20 >>>>>> It is more flexible, but also has an added complexity, and an adde= d >>>>>> abstraction level (in order to be useful, the permissions need to = be >>>>>> named with names which express what effect they are having in the = code, >>>>>> and this may be non-trivial). >>>>>>=20 >>>>>> There is however one point you don't bring up, which I would like = to >>>>>> bring up here. >>>>>>=20 >>>>>> Summarizing the two ways of writing the code, we can either have c= ode >>>>>> which says >>>>>>=20 >>>>>> if has_role(user, ["CodeMatch Approver"]): >>>>>> # code to be exectuted >>>>>>=20 >>>>>> or code which says >>>>>>=20 >>>>>> if has_perm(user, ["approve codematch"]): >>>>>> # code to be exectuted >>>>>>=20 >>>>>> For IETF roles, the list of possible roles are very well codified,= >>>>>> while the only way to know which permissions that need to be named= >>>>>> and listed in a role_auth_permission table is to go through the >>>>>> code and name all the places we check for roles today. Naming tho= se >>>>>> permissions, and making clear the correspondence between the names= >>>>>> and the actual effect they will have in code is not necessarily >>>>>> trivial. >>>>>>=20 >>>>>> For the Codematch project, it may be that you have a much better g= rasp >>>>>> of the named permissions needed, and not so good a grasp of the ro= les. >>>>>>=20 >>>>>> However, since irrespective of how the correspondence between role= s and >>>>>> code is handled, whether it is via has_role() or has_perm(), you a= ctually >>>>>> _need_ to be able to describe the roles well, I would suggest that= you >>>>>> probably also have a much better grasp of the roles than of all th= e >>>>>> named permissions which may be needed. >>>>>>=20 >>>>>> Given that, I would suggest that you start out with the same appro= ach >>>>>> which has been used in the current datatracker code, and once it i= s >>>>>> possible to inspect the code and see which actual places need to c= heck >>>>>> for different roles in order to determine if a given piece of code= may >>>>>> be executed, _and_ you have experience with the tool so that you c= an >>>>>> speak with confidence about which actions a given role should or s= hould >>>>>> not have, then _at that point_ we can consider refining things int= o >>>>>> roles and permissions, instead of listing roles explicitly in the = code. >>>>>>=20 >>>>>> More below. >>>>>>=20 >>>>>>>> I think the real essence of what we're talking about is the >>>>>>>> difference in how you would implement "Give all the WG chairs >>>>>>>> codematch-approval rights". >>>>>>>>=20 >>>>>>>> With your proposal, you would make a role to permission match to= do >>>>>>>> that - one database row change - pretty efficient (*) With what = we >>>>>>>> have now, you just add a Role of "codematch-approval" to any Per= son >>>>>>>> that has a wg chair role. So, I think what you're proposing is a= n >>>>>>>> optimization, and it comes with some complexity. We can keep >>>>>>>> talking about it, but I don't think we're at the point that we n= eed >>>>>>>> it. >>>>>>>=20 >>>>>>> This complexity involves: >>>>>>>=20 >>>>>>> a) Creating a new intermediate table =E2=80=9Crole_auth_permissio= n" composed >>>>>>> of, at least, two columns: role_id and auth_permission_id; >>>>>>>=20 >>>>>>> b) Creating the function "has_right (user, permission_label)" whi= ch >>>>>>> given the user it retrieves the user=E2=80=99s roles, from roles = it retrieves >>>>>>> permissions and, among permissions, it checks if permission_label= is >>>>>>> present. >>>>>>>=20 >>>>>>> Of course, the effort of doing a) and b) would be ours. And these= >>>>>>> implementation would be used in CodeMatch only; it wouldn=E2=80=99= t be >>>>>>> changing or affecting DataTracker. >>>>>>=20 >>>>>> Understood. But for the datatracker, there is the added complexit= y of >>>>>> maintaining code which uses 2 different mechanisms to handle permi= ssions. >>>>>> And that the technical debt of carrying two different solutions fo= rward >>>>>> is something you will not have to suffer, but the datatracker proj= ect >>>>>> will have to deal with. >>>>>>=20 >>>>>>>> (*) But, it's not really that easy. Right now we have a role of >>>>>>>> "chair" that is applied to all groups. There's no way to speak >>>>>>>> differently about WG chairs and RG chairs by simply saying "chai= r" >>>>>>>> - it takes more code. We have chairs of Teams, and _could_ have >>>>>>>> (but don't currently) chairs of other SDOs in the database. So, = the >>>>>>>> apparent simplicity of matching a permission to a role-name isn'= t >>>>>>>> as strong as it first appears. >>>>>>>=20 >>>>>>> While coding the CodeMatch system, we notice that some portions o= f >>>>>>> the system may be or may be not available to different user roles= =2E >>>>>>> Although we define somes roles now, changes on role-permissions w= ill >>>>>>> probably happen along the development process. >>>>>>=20 >>>>>> Agreed. In which case, doing the necessary has_role() or has_perm= ()=20 >>>>>> code changes will most likely happen along with other code changes= =2E >>>>>>=20 >>>>>>> The permissions we want the roles to have define, let me say, the= >>>>>>> policy of CodeMatch. We wanted to decouple that policy from the >>>>>>> system implementation itself, thus implementing an RBAC model; if= the >>>>>>> link between roles and permissions (i.e., the system policy) migr= ates >>>>>>> to the database, we can tag CodeMatch source code (i.e., define >>>>>>> permission labels) and redefine which roles are able to access >>>>>>> different parts of the system. Notice, this is just for CodeMatch= , of >>>>>>> course. >>>>>>=20 >>>>>> RBAC can be implemented both with has_role() and has_perm(); the d= ifference >>>>>> lies in how easy it is to reconfigure the permissions which are as= sociated >>>>>> with a given role. >>>>>>=20 >>>>>> For COTS software, where you cannot easily adapt the code itself t= o the >>>>>> customer environment and wishes, other than through data lookup, t= he >>>>>> approach you suggest makes a lot of sense. For our case, where th= ere is >>>>>> one and only one production system, it is far less important, and = it is >>>>>> not obvious that the added complexity and technical debt incurred = is >>>>>> offset by the added flexibility. >>>>>>=20 >>>>>> Please also consider the pace with which we release software for t= he >>>>>> datatracker: Formal releases are shown in the page: >>>>>>=20 >>>>>> https://datatracker.ietf.org/release/ >>>>>>=20 >>>>>> and in addition to that, we often apply patches. As an example, w= e >>>>>> have done 10 formal releases within the 6.x.y series, but during t= he >>>>>> same time, we have applied 36 patches, resulting in 20 patch relea= se >>>>>> numbers in addition to the formal release numbers. With this rele= ase >>>>>> pace, and with the possibility of applying patches, we are probab= ly >>>>>> agile enough to handle the necessary code changes almost as fast a= s you >>>>>> could agree on what needs to be done and change the settings in a = >>>>>> role_auth_permission table. >>>>>>=20 >>>>>> Could we agree on starting an RBAC implementation using has_role()= , and >>>>>> once we have a bit more experience, and only then, consider taking= on >>>>>> the added complexity and technical debt of using 2 different permi= ssion >>>>>> handling systems in this non-COTS software? >>>>>>=20 >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Henrik >>>>>>=20 >>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> Lisandro >>>>>>>=20 >>>>>>>>> We are of course talking about the CodeMatch code only; we are = not talking about the datatracker code at all, although examples were ins= pired by has_role, which is used in datatracker. >>>>>>>>>=20 >>>>>>>>> Lisandro >>>>>>>>>=20 >>>>>>>>>> On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote: >>>>>>>>>>> Dear All >>>>>>>>>>>=20 >>>>>>>>>>> Last week we had our traditional CodeMatch meeting. One of th= e questions discussed in the meeting was about role-based access control = (RBAC) in CodeMatch. We would like to propose adding an extra table in th= e current data model to support RBAC. However, because we want to be as a= ligned with DataTracker style as possible, we are sending this message to= start a discussion, specially with Henrik and Robert. >>>>>>>>>>>=20 >>>>>>>>>>> 1) Style of checking users=E2=80=99 permission >>>>>>>>>>>=20 >>>>>>>>>>> We observed the DataTracker code and it seems that in general= , permission checking is hardcoded, in the following style (using =E2=80=9C= Area Director=E2=80=9D, =E2=80=9CIAB Chair=E2=80=9D, and =E2=80=9CSecreta= riat" as examples): >>>>>>>>>>>=20 >>>>>>>>>>> if has_role(request.user, ["Area Director", "IAB Chair", "Sec= retariat"]): >>>>>>>>>>> // do something that only area diretor, IAB chair, and secre= tariat could do, like =E2=80=9CCreate CodeRequest" >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> In CodeMatch, we would like to check permissions in the follo= wing way: >>>>>>>>>>>=20 >>>>>>>>>>> if has_right(request.user, =E2=80=9CCreate CodeRequest=E2=80=9D= ): >>>>>>>>>>> // do something that only authorized people should be able t= o do, like =E2=80=9CCreate CodeRequest=E2=80=9D >>>>>>>>>>>=20 >>>>>>>>>>> The =E2=80=9Chas_right=E2=80=9D function would check the data= base to retrieve the users=E2=80=99 roles and, for each role, check if it= has permission to =E2=80=9CCreate CodeRequest=E2=80=9D. In this way, per= missions are associated to roles, and roles associated to users. >>>>>>>>>>>=20 >>>>>>>>>>> Because permissions and roles in CodeMatch are being defined = together with the implementation of the system prototype, the use of =E2=80= =9Chas_right=E2=80=9D would allow us to assign permissions to roles just = changing the database, instead of changing the CodeMatch code if we use =E2= =80=9Chas_role=E2=80=9D instead. >>>>>>>>>>>=20 >>>>>>>>>>> 2) Database >>>>>>>>>>>=20 >>>>>>>>>>> Today, permissions are listed in table auth_permission. Roles= are listed in table group_role. We would need a intermediate table linki= ng permissions to roles, i.e., a table linking author_permissions and gro= up_role. That would allow us to say, for example, that a mentor (inside g= roup_role) can add documents to a codeRequest (i.e., a permission inside = auth_permission). Adding this intermediate table (let=E2=80=99s call it r= ole_permission for the moment) would not affect today=E2=80=99s database,= although it would expand today=E2=80=99s data model. >>>>>>>>>>>=20 >>>>>>>>>>> Do you think doing that is ok? >>>>>>>>>>>=20 >>>>>>>>>>> Best regards, >>>>>>>>>>>=20 >>>>>>>>>>> Lisandro, Wanderson, Matheus >>>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> Codematch-develop mailing list >>>>>>>>>> Codematch-develop@ietf.org = >>>>>>>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Codematch-develop mailing list >>>>> Codematch-develop@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/codematch-develop >>>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 --j2hsw4i2OJ9GWOAmcWeSG3avrKUMngtJD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJV+bNGAAoJEE6bV0uPuxcaHvcQAJToqDlbB8N9FNvh5YWIA6+C KNJOMVGlZnA1OTaSextDrTNG/B4COcdZXbpKR1HRHTCHkBrWIuQR51PMyj4qFlbT IhLTfGEyGQ41yb4wveMtW9M2sc5WASJCOZES+d5+hi3pW3oitMBCxqvVA62gsD4K Hso7fHRP37z/VM5LfAQ0XC+DFEhrPKgpEdaaOMmixpF7aQu7/dgnJurHXdCFuYHP c6EVXlK+IzMJKmxazGM/1yyTJAuUSgrqYTCNcSJ1iONkDhPQadG8+jQOfRV7pITz r9PF8KbM4D3DJKc3SkfUua+rPEf7py9cq6yAwjv4ynW7872NWuHVeD9WSw7gaIWR JmUKDGk/xgWEW6w+MSQRW37kkqfema83jHB8p95gLZEajdRyxNRS2rhFN+vmYjYI K44kRSqviMLrkeL7p4h1YoTsT82jTkSq89dOr5IQ76qTyJomgW2kAidYpt7oB36E DGBGyHNTWHP+lMdOtkJjbDmvOCvUb6jfpRjAMl07RfQrdL4W9DiND8ALdKAhmM8M iYsAhzh8T2Wl1AcWX4vrW9Hqm92WFrHJGCaiQVnelOg5Dsno+mRWsZh5djyhVphU SipAxa8bVaSE059vnG810p/4797TCfVImYIac2oVwk4oOJ08bljOTEEaJW38Sv3F NnUTPFp68LvUfJNFDTXd =tqlV -----END PGP SIGNATURE----- --j2hsw4i2OJ9GWOAmcWeSG3avrKUMngtJD-- From nobody Wed Sep 16 11:25:31 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BAF1A8863 for ; Wed, 16 Sep 2015 11:25:29 -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 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 7P2grfHyvJsH for ; Wed, 16 Sep 2015 11:25:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9AE1A884D for ; Wed, 16 Sep 2015 11:25:28 -0700 (PDT) Received: from localhost ([::1]:37301 helo=vigonier.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZcHOa-0007ry-7Q; Wed, 16 Sep 2015 11:25:28 -0700 To: Robert Sparks , Christian O'Flaherty References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> <55DE0CB3.8020001@nostrum.com> <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> <55DF0B7B.7020902@levkowetz.com> <9B6DB401-A599-4C19-857C-D64241FC467B@inf.ufrgs.br> <55F9B0A7.6000508@levkowetz.com> <55F9B327.8010708@nostrum.com> From: Henrik Levkowetz Message-ID: <55F9B374.3000405@levkowetz.com> Date: Wed, 16 Sep 2015 20:22:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55F9B327.8010708@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KML5gHgF24VE3HEIHB8jibsLJRunpnHNc" X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik-sent@levkowetz.com, granville@inf.ufrgs.br, codematch-develop@ietf.org, oflaherty@isoc.org, rjsparks@nostrum.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: Lisandro Zambenedetti Granville , codematch-develop Subject: Re: [Codematch-develop] DataTracker and CodeMatch access control X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 18:25:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KML5gHgF24VE3HEIHB8jibsLJRunpnHNc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2015-09-16 20:21, Robert Sparks wrote: >> > Possibly Robert made it? > I did - I'll find you on IM and talk through the call. Ok, good. Ttys. Henrik --KML5gHgF24VE3HEIHB8jibsLJRunpnHNc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJV+bN0AAoJEE6bV0uPuxcaLcwP/RamXMB+KoKQSmv7YknR9Csp c5IjlK8tulOv6iXtC03mQ7nHvsUvBeUIQZKltFUULkl8gMUTYHrgcog0QnRz+W8j T0T6wOUonTexNF+KVGudxLMlge1zNAxV/D+dBFqKihyOIp8vlExQhubz+333/lFN hAbRuRCVD5MnUa/8JEORllfAxkuVZQZdgeSijFCQVKmaRW0y/xeQW5G99tdfnaCY M8DtxnuS39qXOzK6Ky/cSdDKXUL1bLkjWKBFaqa4er2Ok6LMUSZOLsT+3NfqrTTb L8JANr0gabIoclSPSyks1dcRnO5TX7nbyqzQJ//1r0wTWpAU/N1hriy9ZYtw8ZBz UG9GYu81QR328/FUgvhP9YLZXCk2a8r8i2+QzkKC69cr+hceLa6aRWpY/AEwF03m 1WnoEV6dviZkjapAFo0PGrjsufZv9P1lHrTtjyfNix0a7rXEv+wRhjxvS309aXJ0 0pv9N+FjF5XT2huUArD8gpXE6UxSsZ9HyHcb/16PzloM5Ost8LF4xw1KJj6LwxZc 1JV4Z9yFdYF5H4Y++LfmAV01GzSsGQ35v9sfyC7UQbt7ZmI898qIgcWF1dMVBIAB TtL4bVN9RqEIIZH07R5fukRsFWmnmMA9OQJV2t+JEUINyESaswphLD4cZPbEJzYz EKqIGW4psGhr0/gk7SZT =wkTq -----END PGP SIGNATURE----- --KML5gHgF24VE3HEIHB8jibsLJRunpnHNc-- From nobody Wed Sep 16 11:31:27 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB32F1A8894 for ; Wed, 16 Sep 2015 11:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ZNgCRaA28kVa for ; Wed, 16 Sep 2015 11:31:24 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1DB1A887E for ; Wed, 16 Sep 2015 11:31:24 -0700 (PDT) Received: by wicge5 with SMTP id ge5so86977703wic.0 for ; Wed, 16 Sep 2015 11:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ipYUTpiiX0JkXVuWG5b6vsNgfbqi1KiZOkjlh2Wmdso=; b=ord7WaJXqyym2c1xJLYinedA32iL8gsgN9qvGX3Gp+LT4ayLmSWMxBdg/S4EYCuSjj IS4jNvFgh6tY1Vso4OM4g/3kX+npNRo+G5R+A7QTfzmKL3OxgIFsw7hMHOz0vB5zawKj ew4ZeeC8Mzdtvy79reBWQZD0kgzItWNcKWL/1Kvl7cBJXCLFOTKEcd301pXOsTiLAZGG rH2ZAizPanpY9n5vEqsCPNkWUuFBXz7v2UJxM7vTLsz0+oVIEDS5uqaB2t4x1QE9hxG0 Bz8DmHjFuIJIVcFFW7cPVZgYMR6l3G8dSlGSeUqjjKitaFtl5erONEojWe0CwvBX+kLt XHxg== MIME-Version: 1.0 X-Received: by 10.180.89.99 with SMTP id bn3mr20705553wib.61.1442428282559; Wed, 16 Sep 2015 11:31:22 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Wed, 16 Sep 2015 11:31:22 -0700 (PDT) In-Reply-To: <55F9B374.3000405@levkowetz.com> References: <0EDC30A8-DD35-4153-B8F1-9AE27CB06E09@inf.ufrgs.br> <55DDD328.6020709@nostrum.com> <5A1D82C2-B60B-4A85-A4B2-E8B524C885D6@inf.ufrgs.br> <55DE0CB3.8020001@nostrum.com> <567B5A53-7A2E-4D1B-A486-37B824D986B0@inf.ufrgs.br> <55DF0B7B.7020902@levkowetz.com> <9B6DB401-A599-4C19-857C-D64241FC467B@inf.ufrgs.br> <55F9B0A7.6000508@levkowetz.com> <55F9B327.8010708@nostrum.com> <55F9B374.3000405@levkowetz.com> Date: Wed, 16 Sep 2015 14:31:22 -0400 Message-ID: From: Kathleen Moriarty To: Henrik Levkowetz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Lisandro Zambenedetti Granville , codematch-develop , Christian O'Flaherty , Robert Sparks Subject: Re: [Codematch-develop] DataTracker and CodeMatch access control X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 18:31:25 -0000 Hello, Yes, the call was recorded and ISOC can provide the link as they provide the Webex access for us. Thank you, Kathleen On Wed, Sep 16, 2015 at 2:22 PM, Henrik Levkowetz wrote: > > On 2015-09-16 20:21, Robert Sparks wrote: >>> > Possibly Robert made it? >> I did - I'll find you on IM and talk through the call. > > Ok, good. Ttys. > > > Henrik > > > _______________________________________________ > Codematch-develop mailing list > Codematch-develop@ietf.org > https://www.ietf.org/mailman/listinfo/codematch-develop > -- Best regards, Kathleen From nobody Fri Sep 18 14:00:29 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289EB1A8A8B for ; Fri, 18 Sep 2015 14:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.04 X-Spam-Level: *** X-Spam-Status: No, score=3.04 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 l9-N6aj7ESI0 for ; Fri, 18 Sep 2015 14:00:26 -0700 (PDT) Received: from mail-mxhero-01.rnp.br (mail-mxhero-01.rnp.br [200.130.35.121]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD691B35A7 for ; Fri, 18 Sep 2015 14:00:24 -0700 (PDT) Received: from mail-mxhero-01.rnp.br (localhost [127.0.0.1]) by mail-mxhero-01.rnp.br (Postfix) with ESMTP id C6E3C401522 for ; Fri, 18 Sep 2015 21:00:28 +0000 (UTC) Received: from mail-mtaout-proxy-01.rnp.br (mail-mtaout-proxy-01.rnp.br [200.130.35.126]) by mail-mxhero-01.rnp.br (Postfix) with ESMTPS; Fri, 18 Sep 2015 21:00:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail-mtaout-proxy-01.rnp.br (Postfix) with ESMTP id 43F04100B1B; Fri, 18 Sep 2015 18:00:29 -0300 (BRT) Received: from mail-mtaout-proxy-01.rnp.br ([127.0.0.1]) by localhost (mail-mtaout-proxy-01.rnp.br [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1ZHvqDFc6G1z; Fri, 18 Sep 2015 18:00:29 -0300 (BRT) Received: from CTICBSBPC02 (dhcp125.na-df.rnp.br [200.130.78.125]) by mail-mtaout-proxy-01.rnp.br (Postfix) with ESMTPSA id 2FED5100731; Fri, 18 Sep 2015 18:00:29 -0300 (BRT) From: "Wanderson Paim" To: Date: Fri, 18 Sep 2015 18:00:21 -0300 Message-ID: <01be01d0f255$08edd290$1ac977b0$@rnp.br> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BF_01D0F23B.E3A10FC0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdDyU5Y1hrVEzDweTQq4jStmIheRbQ== Content-Language: pt-br x-mxHero-Origin-Ip: /127.0.0.1:54727 Sender: wanderson.jesus@rnp.br Archived-At: Cc: codematch-develop Subject: [Codematch-develop] CodeMatch Source Code X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 21:00:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01BF_01D0F23B.E3A10FC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Robert, In the last meeting, you asked where is the CodeMatch source code. Currently, we have a repository in github with two branches, one for stable code (master), and another one for developing (dev). Follow the links: https://github.com/wpjesus/codematch https://github.com/wpjesus/codematch/tree/master https://github.com/wpjesus/codematch/tree/dev I created these repositories by myself, but if the IETF have a standard repository where we could host the CodeMatch code, I see no problem in migrating to there. Best Regards, Wanderson ------=_NextPart_000_01BF_01D0F23B.E3A10FC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Robert,

 

In the last meeting, you asked where is the CodeMatch = source code.

Currently, we have a repository in github with two = branches, one for stable code (master), and another one for developing = (dev). Follow the links:

 

https://github.com/wpjesus/= codematch

 

https://github.= com/wpjesus/codematch/tree/master

https://github.com= /wpjesus/codematch/tree/dev

 

I created these repositories by = myself, but if the IETF have a standard repository where we could host = the CodeMatch code, I see no problem in migrating to = there.

 

Best Regards,

 

Wanderson

<= /html> ------=_NextPart_000_01BF_01D0F23B.E3A10FC0-- From nobody Sat Sep 26 15:02:34 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBE81A8715 for ; Sat, 26 Sep 2015 15:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.04 X-Spam-Level: *** X-Spam-Status: No, score=3.04 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 1piGSWO02FkW for ; Sat, 26 Sep 2015 15:02:29 -0700 (PDT) Received: from mail-mxhero-01.rnp.br (mail-mxhero-01.rnp.br [200.130.35.121]) by ietfa.amsl.com (Postfix) with ESMTP id 784471A8718 for ; Sat, 26 Sep 2015 15:02:26 -0700 (PDT) Received: from mail-mxhero-01.rnp.br (localhost [127.0.0.1]) by mail-mxhero-01.rnp.br (Postfix) with ESMTP id 003DA40142A for ; Sat, 26 Sep 2015 22:02:29 +0000 (UTC) Received: from mail-mtaout-proxy-01.rnp.br (mail-mtaout-proxy-01.rnp.br [200.130.35.126]) by mail-mxhero-01.rnp.br (Postfix) with ESMTPS for ; Sat, 26 Sep 2015 22:02:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail-mtaout-proxy-01.rnp.br (Postfix) with ESMTP id 9EC4C10089D for ; Sat, 26 Sep 2015 19:02:33 -0300 (BRT) Received: from mail-mtaout-proxy-01.rnp.br ([127.0.0.1]) by localhost (mail-mtaout-proxy-01.rnp.br [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CYk_dmeruxXZ for ; Sat, 26 Sep 2015 19:02:33 -0300 (BRT) Received: from mail-mbox-03.rnp.br (gti-idc-fw-35.rnp.br [200.130.35.1]) by mail-mtaout-proxy-01.rnp.br (Postfix) with ESMTP id 89804100731 for ; Sat, 26 Sep 2015 19:02:33 -0300 (BRT) Date: Sat, 26 Sep 2015 19:02:48 -0300 (BRT) From: Wanderson Paim de Jesus To: codematch-develop Message-ID: <1584729413.6637767.1443304968423.JavaMail.zimbra@rnp.br> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6637766_936796951.1443304968422" X-Mailer: Zimbra 8.6.0_GA_1178 (ZimbraWebClient - SAF8 (Mac)/8.6.0_GA_1178) Thread-Topic: CodeMatch Version 1.0.0 release Thread-Index: xQO4DPDLHKCWksKzC/K67XiTrAxqFg== x-mxHero-Origin-Ip: /127.0.0.1:49360 Sender: wanderson.jesus@rnp.br Archived-At: Subject: [Codematch-develop] CodeMatch Version 1.0.0 release X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 22:02:33 -0000 ------=_Part_6637766_936796951.1443304968422 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello everyone, Since the beginning of CodeMatch development, we are trying to follow the standards and best practices of django and python. Nevertheless, the source code is open and any contribution towards the improvement of quality is welcome. There is also an effort to be compliant with coding practices and testing recommendations listed in IETF Wiki. As pointed by Robert during the web meeting. In the last week we started to control the CodeMatch versions. The first version, 1.0.0, was created and its features are described in the RELEASE_NOTES file, which is stored in the GitHub along with the source code. So, anyone in the community could check if the features of the release are working appropriately. The release notes of the first version are found in this link: https://github.com/wpjesus/codematch/blob/dev/RELEASE_NOTES We also use the feature list in Google Drive to track features and deadlines. https://docs.google.com/spreadsheets/d/1wuKbYaYQ4fBd9sfGjL2NOFTAsL2jDOmjsZx2g1-8hGA/edit?usp=sharing The last stable version is available at: http://codematch.inf.ufrgs.br/codematch-master/codematch/ * To login use your DataTracker username and the word "password" as password. Fell free to check it out. Best regards, Wanderson ------=_Part_6637766_936796951.1443304968422 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hel= lo everyone,

Since the beginning of CodeMatch development, we are t= rying to follow the standards and best practices of django and python. Neve= rtheless, the source code is open and any contribution towards the improvem= ent of quality is welcome. There is also an effort to be compliant with cod= ing practices and testing recommendations listed in IETF Wiki. As pointed b= y Robert during the web meeting.

In the last week we started to control the CodeMatch versions. The = first version, 1.0.0, was created and its features are described in the REL= EASE_NOTES file, which is stored in the GitHub along with the source c= ode. So, anyone in the community could check if the features of the re= lease are working appropriately.

The release notes of the first vers= ion are found in this link:
https://github.com/wpjesus/codematch/= blob/dev/RELEASE_NOTES

We= also use the feature list in Google Drive to track features and deadlines.=
https://docs.google.com/spreadsheets/d/1wuKbYaYQ4fBd9sfGjL2NOFTA= sL2jDOmjsZx2g1-8hGA/edit?usp=3Dsharing

<= /div>
The last stable version is available at:
http://codemat= ch.inf.ufrgs.br/codematch-master/codematch/

* To login use your DataTracker username and the word "= password" as password.

Fell free to check it out. 
Best regards,

Wanderson
------=_Part_6637766_936796951.1443304968422-- From nobody Wed Sep 30 09:05:30 2015 Return-Path: X-Original-To: codematch-develop@ietfa.amsl.com Delivered-To: codematch-develop@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1391B464A for ; Wed, 30 Sep 2015 09:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 QG_WiUXN1Jul for ; Wed, 30 Sep 2015 09:05:27 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 464301B44A3 for ; Wed, 30 Sep 2015 09:05:27 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so205882042wic.0 for ; Wed, 30 Sep 2015 09:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=hYvEasvhlFfjmCoGlMn6hoK6Tn9WzJTqxJeApPHbwjI=; b=XEgebXtjDmvPFpqbhaHfWviivWrUn4HdEnSF+am2MMC016+vVfPJaWQ4sXAdT0MuXo NYHvDmUtAQH5brocsq1Skuwr2eFW46qDRFubIwQ7MkIsJili0PQZPS0gDYKxflnV03zy 1usnWEPDsc3Ljad7tiR5Dn8PBBaaXjwIvlV9AxeFHoEVimM2UICQ97XV9jdvjRoKYpHv CeTxJw/00FXnMOQT7SDMXvhBURoemuGCKnzq2qPKLIle7I+NNHhSYMQcSgzNlBX1Lxfc S0EEs54LakOLBW9vm5BcZmwjUwLMPW10N80t0wWfbgEHQbaKGJhJnvfAaU5QIeePbNFP dBvA== MIME-Version: 1.0 X-Received: by 10.180.75.38 with SMTP id z6mr30533320wiv.36.1443629125785; Wed, 30 Sep 2015 09:05:25 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Wed, 30 Sep 2015 09:05:25 -0700 (PDT) Date: Wed, 30 Sep 2015 12:05:25 -0400 Message-ID: From: Kathleen Moriarty To: "codematch-develop@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Codematch-develop] Today's call X-BeenThere: codematch-develop@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 16:05:28 -0000 Hello, I am assuming LACNOG is int he way as I'm the only one in the webex. I'll drop in a minute and we can resume next week. Thanks. -- Best regards, Kathleen