Indeed they have been - missed that, sorry, --David > -----Original Message----- > From: Marc Blanchet [mailto:[email protected]] > Sent: Friday, August 03, 2012 2:58 PM > To: Black, David > Cc: [email protected] > Subject: Re: [precis] Late comments on problem-statement-06 [NFSv4] > > > Le 2012-08-03 à 11:49, <[email protected]> a écrit : > > > I'd just mention the existence of these stringprep profiles to the list in > Section 1. > > they have been since the first version of the draft, aren't they? > > <extract> > 1. Introduction > > Internationalizing Domain Names in Applications (here called > IDNA2003) [RFC3490], [RFC3491], [RFC3492], [RFC3454] describes a > mechanism for encoding Unicode labels making up Internationalized > Domain Names (IDNs) as standard DNS labels. The labels were > processed using a method called Nameprep [RFC3491] and Punycode > [RFC3492]. That method was specific to IDNA2003, but is generalized > as Stringprep [RFC3454]. The general mechanism is used by other > protocols with similar needs, but with different constraints than > IDNA2003. > > Stringprep defines a framework within which protocols define their > Stringprep profiles. Known IETF specifications using Stringprep are > listed below: > o The Nameprep profile [RFC3490] for use in Internationalized Domain > Names (IDNs); > o NFSv4 [RFC3530] and NFSv4.1 [RFC5661]; > > </extract> > > Marc. > > > > > 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
