NFS also contains some stringprep profiles:
- NFSv4: RFC 3530, Section 11
- NFSv4.1: RFC 5661, Section 14
There are also concerns that the stringprep approach doesn't work well for
NFSv4.
See section 12 of draft-ietf-nfsv4-rfc3530bis-18.txt for some current thinking
on this topic.
Thanks,
--David
> -----Original Message-----
> From: Black, David
> Sent: Friday, August 03, 2012 12:05 PM
> To: [email protected]
> Cc: Black, David
> Subject: Late comments on problem-statement-06
>
> I've finally been able to take a look at the problem-statement-06 draft,
> primarily to check the iSCSI material, but I also took a look at the main
> portion of the draft. I have a few comments, and greatly appreciate the
> patience of the authors and WG chairs in being willing to look at these
> after WG Last Call. Everything I found here is minor.
>
> -- Section 2:
>
> A single Unicode code point in this memo is denoted by "U+" followed
> by four to six hexadecimal digits. Compare to [Unicode61], Appendix
> A.
>
> I don't understand what is intended by "Compare". Is this representation
> the same as, similar to or different from the cited reference?
>
> -- Section 3
>
> During IETF 77, a BOF discussed the current state of the protocols
> that have defined Stringprep profiles [NEWPREP].
>
> I'd suggest adding the month and year of IETF 77 in parens after the 77.
>
> o Stringprep is bound to version 3.2 of Unicode. Stringprep has not
> been updated to new versions of Unicode. Therefore, the protocols
> using Stringprep are stuck to Unicode 3.2.
>
> o The protocols need to be updated to support new versions of
> Unicode. The protocols would like to not be bound to a specific
> version of Unicode, but rather have better Unicode agility in the
> way of IDNA2008. This is important partly because it is usually
> impossible for an application to require Unicode 3.2; the
> application gets whatever version of Unicode is available on the
> host.
>
> I suggest merging first sentence of second bullet into the first bullet
> so that the second bullet focuses on Unicode version agility. The last
> sentence of the first bullet could then be:
>
> Therefore, the protocols using Stringprep are stuck at Unicode 3.2,
> and their specifications need to be updated to support newer versions
> of Unicode.
>
> Also, "Unicode agility" -> "Unicode version agility".
>
> The following iSCSI bullet is incorrect:
>
> o iSCSI uses a Stringprep profile for the IQN, which is very similar
> to (often is) a DNS domain name.
>
> with
>
> o iSCSI uses a Stringprep profile for the names of protocol participants
> (called initiators and targets). The IQN format of iSCSI names contains
> a reversed DNS domain name.
>
> -- Appendix A
>
> The User entry for RFC 3722 (iSCSI) should be "b", not "a". The iSCSI name
> strings are part of host and storage system configuration; these strings
> are entered by and are visible to administrators.
>
> -- Appendix B.1 iSCSI Stringprep Profiles: RFC3722, RFC3721, RFC3720
>
> There is one profile, and it's specified by RFC 3722. The other two RFCs
> describe the naming design and how the strings are used. It may not b
> appropriate to list the other two RFCs in the section name.
>
> Description: An iSCSI session consists of an Initiator (i.e., host
> or server that uses storage) communicating with a target (i.e., a
> storage array or other system that provides storage). Both the
> iSCSI initiator and target are named by iSCSI Names. The iSCSI
> stringprep profile is used for iSCSI names.
>
> Initiator -> initiator in first line.
>
> What is the impact if the comparison results in a false positive?
> Potential access to the wrong storage. - If the initiator has no
> access to the wrong storage, an authentication failure is the
> probable result. - If the initiator has access to the worng
> storage, the resulting mis-identificaiton could result in use of
> the wrong data and possible corruption of stored data.
>
> Correct two spelling errors:
> - worng -> wrong
> - identificaiton -> identification.
>
> What are the security impacts? iSCSI names are often used as the
> authentication identities for storage systems. Comparison
> problems could result in authentication problems, although note
> that authentication failure ameliorates some of the false positive
> cases.
>
> Change "are often used" to "may be used" in the first line.
>
> How much tolerance for change from existing stringprep approach?
> Good tolerance; the community would prefer that
> internationalization experts solve internationalization problems
> ;-).
>
> Remove the smiley.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA 01748
> +1 (508) 293-7953 FAX: +1 (508) 293-7786
> [email protected] Mobile: +1 (978) 394-7754
> ----------------------------------------------------
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
