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
