-08 now includes all your changes. However, for: "-- 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."
I wanted to keep the three RFCs in the list since they had been identified as to be reviewed during our stringprep customers review process. (so that we show the coverage we made). So I rewrote as: iSCSI Stringprep Profile: RFC3722 (and RFC3721, RFC3720). hope this is acceptable to you. Marc. Le 2012-08-03 à 09:04, <[email protected]> a écrit : > 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
