Le 2012-08-03 à 09:42, <[email protected]> a écrit : > 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.
ok. but I'm not sure what to do or include into the problem statement. Do you want to sketch something? Marc. > > 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 _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
