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(_at_)filament(_dot_)com]
Sent: Monday, June 26, 2017 8:41 PM
To: Peter Saint-Andre - Filament <peter(_at_)filament(_dot_)com>; Linda Dunbar
<linda(_dot_)dunbar(_at_)huawei(_dot_)com>; gen-art(_at_)ietf(_dot_)org
Cc: precis(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
draft-ietf-precis-7613bis(_at_)ietf(_dot_)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