Linda, thanks for your review. Peter, thanks for addressing Linda’s comment. I have entered a No Objection ballot position.
Alissa > On Jun 27, 2017, at 4:22 PM, Linda Dunbar <[email protected]> wrote: > > Peter, > > Thank you very much for the explanation and the revised wording. Your new > wording is much clearer and help people to understand why to postpone the > checking. > > Thank you. > > Linda Dunbar > > -----Original Message----- > From: Peter Saint-Andre - Filament [mailto:[email protected]] > Sent: Monday, June 26, 2017 8:41 PM > To: Peter Saint-Andre - Filament <[email protected]>; Linda Dunbar > <[email protected]>; [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: Re: [precis] Gen-art last call review of draft-ietf-precis-7613bis-07 > > On 6/26/17 5:48 PM, Peter Saint-Andre - Filament wrote: >> Hi Linda, >> >> Thanks for your review. Comments inline. >> >> On 6/26/17 4:53 PM, Linda Dunbar wrote: >>> >>> Reviewer: Linda Dunbar >>> Review result: Ready >>> >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed by >>> the IESG for the IETF Chair. Please treat these comments just like >>> any other last call comments. >>> >>> For more information, please see the FAQ at >>> >>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >>> >>> Document: draft-ietf-precis-7613bis >>> Reviewer: Linda Dunbar >>> Review Date: 2017-06-25 >>> IETF LC End Date: 2017-06-27 >>> IESG Telechat date: 2017-07-06 >>> >>> Summary: >>> The document is written very clear. Even for a person who is not >>> familiar with the App area, I can follow through the description. The >>> document is ready for publication as standard track document Major issues: >>> >>> One Minor issue: >>> >>> Page 6 last paragraph has: >>> /SASL mechanisms SHOULD delay any case////mapping to the last >>> possible moment, such as when doing a lookup////by username, >>> performing username comparisons, or generating a////cryptographic >>> salt from a username (if the last possible moment////happens on the >>> server, then decisions about case mapping can be a////matter of >>> deployment policy). In keeping with [RFC4422], SASL////mechanisms are >>> not to apply this or any other profile to////authorization >>> identifiers, only to authentication identifiers./ >>> >>> What does "last possible moment" mean? When I read it, I thought it >>> meant wait until you got all the characters. But the next sentence >>> mentions "..happens on the server". How is the "server" related to >>> the entity that check the user name & password? >> >> Many authentication decisions happen on an application server to which >> a user-oriented client connects (think of an email client connecting >> to an email server). By "last possible moment" we're referring to >> processing within the application server or an authentication module >> thereof - for instance, instead of performing case mapping on first >> receiving data from the client (thus implying that the case >> information is lost through most of the processing stages), it's >> better to lose that information only at the very end. Do you feel it >> would it help to add a more detailed description of the reasoning here? > > Here is a proposed adjustment to the text: > > OLD > > SASL mechanisms SHOULD delay any case > mapping to the last possible moment, such as when doing a lookup > by username... > > NEW > > Because case mapping results in > information loss, in order to retain that information for as long > as possible during processing, implementations SHOULD delay any > case mapping to the last possible moment, such as when doing a > lookup by username... > > Peter > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
