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
