That works for me, Thanks, --David > -----Original Message----- > From: Marc Blanchet [mailto:[email protected]] > Sent: Friday, August 03, 2012 1:49 PM > To: Black, David > Cc: [email protected] > Subject: Re: [precis] Late comments on problem-statement-06 > > -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
