Early Review of draft-ietf-nfsv4-internationalization-06
review-ietf-nfsv4-internationalization-06-artart-early-gulbrandsen-2023-10-25-00

Hi,

first off, let me say how impressed I am with gathering all that and 
writing it up. The length was a problem for reviewing, I imagine collecting 
the substance was a bigger problem.

I like the draft; it offers useful information for implementers of an IETF 
standard. It's extremely long, which I imagine will be a problem for 
would-be readers, but I don't see how it could really be much shorter 
without damaging interoperation.

It could be organised differently, say split into two RFCs, but I don't see 
any way to make the length easier to handle. There quite simply is a lot 
that implementers of NFS clients/servers need to know in order to get good 
interoperation with different implementations of different versions of NFS. 
So although the length is an issue, I don't think it's one that can be 
solved. History is that complicated.

The same reason also persuades me that the draft's overall approach makes 
sense: It describes what existing code does and the possible ways new code 
can interoperate with it and support i18n usefully. It would be possible to 
write something more like a typical RFC, describing rules rather than 
advising on types of existing implementations, but the draft as it stands 
seems more helpful to NFS implementers.

I read the draft from the standpoint of someone who knows a lot about 
internationalisation and IDNA, and a lot about unix, but practically 
nothing about netapps and that kind of gadgetry.

For someone like me, the introduction could usefully have described the 
different documents. The middle of page 4 didn't make much sense ("With 
regard to NFSv4.1 [RFC8881]" and the rest of the paragraph), but I suppose 
actual implementers don't need that crutch. They know what 8881 said and 
its implications. I don't ask for elaboration, unless the author feels that 
people like myself are part of the audience.

There are a fair number of typos and other things the RFC editor will fox. 
Nomalization for example (no r). Relavant, nit for not, bein. I skip those. 
Frankly I'm a worse typist myself.

Page 14 and some later pages made me wonder whether "implementations" 
refers to servers, clients or both. I'd appreciate it if the author would 
look at each instance of the word "implementations" in the document and 
qualify it where necessary.

Page 14 contains the first of the elephant sentences that I think I 
understand, but wow! "While RFC7630 has gone so far" etc. I think the 
document is useful, but some of those long sentences... I'd be happier with 
that entire paragraph just rewritten. The last sentence is okay.

The last sentence on the page seems as if it would be happer if split in 
two. Replacing "while" with a full stop would make it all easier to read. 
That's not the only sentence in this draft that could be split.

On page 19, the last paragraph says code MUST do this or that, and it's the 
only two possibilities. Eh. I MUST have my cake or eat it, what's the MUST 
in that? If you're going to use MUST, I advise saying that people MUSTY use 
UTF-8 (this is based on my work on other protocols where xn-- also occurs). 
If you don't want to tell people want to do, then please avoid uppercase 
MUST.

I wrote "4.1" on the top paragraph of page 20, but have no idea why I did 
so. Sorry.

The bottom lines of page 20 contains the words "will need to normalize the 
various UTF-8 encoded strings within the protocol before"... should that be 
within the NFSv4 server/client implementation?

On page 21, I'd prefer to strike ", whether upper case or lower case" and 
perhaps the "can" in the same sentence should be MAY?

I think there's been a mistake while typing the sentence containing "give 
rise" on page 23. Give rise to what? The next sentence explains the 
problem, maybe the first sentence would more informative if it were 
shorter.

Page 24, second paragraph, says something is not allowed. By what?

Page 24, the last sentence, I can't read it. The two occurences of "as" may 
be the thing that makes the sentence too hard for me.

Page 32, the top paragraph may need rewriting. Not sure. I see an orphaned 
clause at the end of the paragraph and am not sure what was intended.

The second paragraph uses the word MUST about an example, and the example 
is dominant but it's hardly a MUST. Please fix.

Page 35, top paragraph, the elephant sentence containing "as is the 
question" is unclear to me. I don't get what the question is.

Page 40, top paragraph, what is an "reserved LDH label"?

Page 40, I suggest replacing "changes of case SHOULD NOT be done and MUST 
NOT be done for strings that contain multi-bute Unicode characters" with 
"changes of case SHOULD NOT be done at all and MUST not be done for strings 
that contain Unicode codebpoints outside the ASCII range".

Page 44, top paragraph, I'm curious. Why the limitation to 16 bits?

Page 56, third reason. I had to think about that, so perhaps this warrants 
an example, e.g. a letter, a combining accent above and a combining accent 
below.

Page 62, top paragraph, rewrite needed, particularly the last sentence, 
which I completely failed to understand.

I also made a note on that page saying, basically, awesome. Someone who 
knows a lot of the dustier corners of unicode has thought hard about how to 
provide fast, well-working, interoperable comparison. There are tyypos in 
three of the paragraphs, but also considerable knowledge.

Page 63 has more typos, I think "immediate following" should be 
"immediately follow"? 64 has another inscrutable passage, surrounding 
"arbitrarily id designated".

The last sentence in the draft lacks a full stop, perhaps the author wants 
to surprise the readers with some unexpected brevity?

Arnt