Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.
None. The test results and variant calculations seem to be doing the right thing, I found no issues.
Two comments that should be viewed as minor:
1. I'm not sure I fully agree with the addition of the two ASCII code points U+0069 and U+006F as variants, or, for that matter, with why these particular two were selected. I've considered the rationale under "Changes from LGR-4". Clearly, one might see "i" and "o" as potential homoglyphs to Hebrew code points; however (a) following the same line of thinking, there are others - small L (U+006C) is but one example - and (b) ASCII code points are not allowed by LGR in Hebrew labels anyway.
In essenece, I wonder as to why variant sets 1 and 2 are needed.
2. This observation is from Mr. Matitiahu Allouche, a distinguished expert and a member of the Hebrew Script GP: In file “labels_variants_rz-lgr-5-hebrew-script-24mar22-en-v10.xlsx”, when a label is invalid due to the Bidi rule in RFC5893 and ends with a Latin letter, the display of the diagnostic is flawed because the last letter is glued to the Latin text on the left side while the label itself is on the right side (as being the first word of the sentence and inducing a RTL base direction). See for instance rows 156, 158-162 etc.
RZ-LGR 5 seems to be doing the right thing wrt the Hebrew script. No major issue - great job! Thanks for all the good work.
Two minor comments were provided, nothing that should be considered critical or delay the process.