I'd just mention the existence of these stringprep profiles to the list in Section 1. I would not go into their details, particularly given the text in 3530bis that moves away from use of stringprep.
Thanks, --David > -----Original Message----- > From: Marc Blanchet [mailto:[email protected]] > Sent: Friday, August 03, 2012 1:50 PM > To: Black, David > Cc: [email protected] > Subject: Re: [precis] Late comments on problem-statement-06 [NFSv4] > > > 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
