Hi, Luis Thanks a lot for sharing your viewpoints!
Yes, it is possible that the user/device could be defined as pertaining to more than one group, depending on the current context. The example that has been given in the draft is that, the user group R&D Regular and R&D BYOD may share the same set of users that belong to the R&D organization, and differ only in the type of clients (firm-issued vs. users' personal ones). By declaring a group with common ACLs, are you suggesting to define some kind of hierarchical group that bind different subgroups which share common ACLs together? That sounds interesting, actually the authors now are considering the change the type of the endpoint group ID from uint32 to string (see this PR prepared by Med: https://github.com/boucadair/policy-based-network-acl/pull/20/files), I think that make it possible for us to declare some hierarchy among different groups and indicated by the group-id string. Best Regards, Qiufang From: OPSAWG [mailto:[email protected]] On Behalf Of LUIS MIGUEL CONTRERAS MURILLO Sent: Friday, September 22, 2023 10:37 PM To: [email protected]; 'Tianran Zhou' <[email protected]>; [email protected] Cc: [email protected] Subject: Re: [OPSAWG] Working group adoption call for draft-ma-opsawg-ucl-acl-03 Hi all, Apologies for being late on expressing my view. I support the adoption of the draft. After reading it, some question coming to my mind is if the users / devices could be defined as pertaining to more than one group. I was thinking on that assuming that different groups could have some common ACLs, so if maybe could be something interesting to declare a group with common ACLs plus another type of group with the differential ACLs. This could be beneficial for instance at the time of updating the ACLs which are common (so avoiding to update multiple groups instead of only one). Thanks and apologies again for the delay on answering the poll. Best regards Luis De: OPSAWG <[email protected]<mailto:[email protected]>> En nombre de Adrian Farrel Enviado el: lunes, 11 de septiembre de 2023 22:33 Para: 'Tianran Zhou' <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> CC: [email protected]<mailto:[email protected]> Asunto: Re: [OPSAWG] Working group adoption call for draft-ma-opsawg-ucl-acl-03 Hi Tianran, I think this is a timely piece of work that should be adopted. I commit to further reviews if it is adopted. A few minor comments on this version, below. Nothing that needs to be fixed before adoption. There is a meta-question: should the schedule model be moved out into a separate document? It isn't necessary at this point in time (we can continue to work on everything in one document), but given the intended wider applicability it might be convenient to hold it in a separate document. Cheers, Adrian === It would be good if the document title indicated (as the Abstract does) what the document contains. Something like... Management Tools for Policy-based Access Control --- The abbreviation "UCL" is fine, but I don't like the expansion you give in Section 2 * User group based ACL (UCL): A YANG data model for policy-based network access control that specifies an extension to the IETF ACL model defined in [RFC8519]. 1. It is weird to say that the UCL is a YANG model (when the ACL is clearly not a YANG model in its own right). 2. It is hard to make "User group based ACL" into UCL. 3. I am currently going through pain with the IESG objecting to calling something "the IETF foo" because "what if another one comes along?" How about... * User group based Control List (UCL) model: A YANG data model for policy-based network access control that specifies an extension to the ACL YANG model defined in [RFC8519]. --- I think you might move the definition of NACL to Section 2 (especially given the name of the document and its short title. --- In section 2, the definition of endpoint includes "end user". I find that term confusing: is "a user" a person, an application, or a device? Actually, probably you mean "end-user", not a the user of an end :-) --- Section 3 has... NACL policies may need to vary over time. For example, companies may restrict (or grant) employees access to specific internal or external resources during work hours, while another policy is adopted during off-hours and weekends. Pedantically, the example you give here is of use of different policies over time, not actually varying the policies themselves. --- 4.1 should expand "SDN". A reference would be useful, too. References for NAS and AAA on their first use would also be useful. --- While this is obviously in the purview of this working group, it is going to need some serious security review. The chairs need to make provision for that, possibly by approaching SAAG to get a security reviewer assigned. From: OPSAWG <[email protected]<mailto:[email protected]>> On Behalf Of Tianran Zhou Sent: Tuesday, September 5, 2023 2:13 AM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: [OPSAWG] Working group adoption call for draft-ma-opsawg-ucl-acl-03 Hi WG, This mail starts a two weeks working group adoption call for draft-ma-opsawg-ucl-acl-03 https://datatracker.ietf.org/doc/draft-ma-opsawg-ucl-acl/ Please send over your objections or supports to the mailing list. If you object the adoption, please also give the reason, so that the authors can improve. We will conclude this adoption call on Sep 20, 2023. All your comments are welcome. Best, Tianran ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição ________________________________ Le informamos de que el responsable del tratamiento de sus datos es la entidad del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el contacto profesional y gestionar la relación establecida con el destinatario o con la entidad a la que está vinculado. Puede contactar con el responsable del tratamiento y ejercitar sus derechos escribiendo a [email protected]<mailto:[email protected]>. Puede consultar información adicional sobre el tratamiento de sus datos en nuestra Política de Privacidad<https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>. We inform you that the data controller is the Telefónica Group entity linked to the sender, for the purpose of maintaining professional contact and managing the relationship established with the recipient or with the entity to which it is linked. You may contact the data controller and exercise your rights by writing to [email protected]<mailto:[email protected]>. You may consult additional information on the processing of your data in our Privacy Policy<https://www.telefonica.com/en/wp-content/uploads/sites/5/2022/12/Telefonica-Third-data-subjects-Privacy-Policy.pdf>. Informamos que o responsável pelo tratamento dos seus dados é a entidade do Grupo Telefónica vinculada ao remetente, a fim de manter o contato professional e administrar a relação estabelecida com o destinatário ou com a entidade à qual esteja vinculado. Você pode entrar em contato com o responsável do tratamento de dados e exercer os seus direitos escrevendo a [email protected]<mailto:[email protected]>. Você pode consultar informação adicional sobre o tratamento do seus dados na nossa Política de Privacidade<https://www.telefonica.com/es/politica-de-privacidade-de-terceiros/>.
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
