...

There will be a creation_response for each creation in the CreateAclsRequest.  The responses will appear in the same order which the requests appeared.  For creations which completed successfully, error_code will be 0 and error_message will be null.  If there was an error, the error_code will be non-zero and the error_message will give a detailed error message describing why the creation could not be performed.

Because the arguments to CreateAclsRequest are concrete ACLs and not filters, they should not contain ANY or null fields.  They also should not contain UNKNOWN fields.

DeleteAclsRequest and DeleteAclsResponse

...

Filter responses will be appear in the same order which the filters appeared.  If the filter_response has a non-zero error_code, that means that the filter could not be applied by the server, and the match array will be empty.  Otherwise, the match array contains a list of all the ACLs that matched the filter.  Each match will have a non-zero error code and error message if it could not be removed.  When a filters fails to match an ACLs, it is not an error.  This will simply result in getting back a filter_response with an empty match list.

The arguments to DeleteAclsRequest should not contain UNKNOWN fields.  The UNKNOWN enum type is intended to represent a server response that can't be fully understood by the client, not a request which the client sends.  However, in a filter, ANY or null fields will match UNKNOWN fields.  So it is possible to construct a filter that will delete all ACLs attached to a particular topic, even when some of those ACLs contain UNKNOWNs.

If the client is newer than the broker, some of the fields may show up as UNKNOWN on the broker side.  In this case, the filter will get an UnsupportedVersionException and the filter will not be applied.

New AdminClient APIs

ResourceType, AclOperation, AclPermissionType

...