[SSSD] memberUID corruption handling

I've noticed lately on a couple of LDAP environments (all of which having been converted at some point in the past from NIS) that there is a tendency for bad conversion scripts to sometimes leave around groups with improperly formatted memberUID values. For example: dn: cn=groupA,ou=Groups,dc=example,dc=com objectClass: posixGroup ... memberUID: user1,user2,user3 Now, the standards-compliant approach here would be to just treat 'user1,user2,user3' as a single group entry (that except on the most psychotic of systems would never match an actual username). However, it's well within our power in SSSD to handle this more gracefully, by parsing the commas ourselves. My question is, is this something we should do, or should we continue treating this as useless data and use it to encourage admins to fix their systems? This *has* caused negative behavior in the SSSD in the past (specifically, there was a bug in some older versions of LDB that caused it to be unable to perform a reindex on DNs that contained an escaped comma, thus rendering SSSD incapable of safely upgrading to newer versions).