Re: [precis] [Gen-art] Gen-art last call review of draft-ietf-precis-7613bis-07

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 <linda.dunbar@huawei.com> 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:peter@filament.com] 
> Sent: Monday, June 26, 2017 8:41 PM
> To: Peter Saint-Andre - Filament <peter@filament.com>; Linda Dunbar <linda.dunbar@huawei.com>; gen-art@ietf.org
> Cc: precis@ietf.org; ietf@ietf.org; draft-ietf-precis-7613bis@ietf.org
> 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
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art