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

Alissa Cooper <alissa@cooperw.in> Wed, 05 July 2017 13:52 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CB7129B64; Wed, 5 Jul 2017 06:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=KmibRpWz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Cm1lTCNm
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1l_xs004K7Ud; Wed, 5 Jul 2017 06:52:32 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193E1131D12; Wed, 5 Jul 2017 06:52:32 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7F1FE207FE; Wed, 5 Jul 2017 09:52:31 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 05 Jul 2017 09:52:31 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=ws0KqdvFH3XwtXp5R3 fFs/7uB8dKBgNgbbf0sLlqWSQ=; b=KmibRpWz/2i6dSkYm7kE6lcNoArMVLDtAo p0VLvzSaHD5DeC6wdCv9zUYoK+MDEHyRE+PVZMKxX3+pv/ZgYB4KDxCJcYErbmvh bIDUZBsy9u7+WXdKNWiihP10qRCbC4JoFb8K3MGXUPMjg7F9gW1dDpb7Lscw7RTa yg+Hh+3kFQ5UcW3KYTAWjY7ag0AdDAxjXMF75d9H4bq78ykThhz3cvAmTZ76f+AP rL/RFbaw1LVJ4XIyyFIDBjvc4j4ZPARBwmmXGZmV0MM3e9nWJ4Lda+Z7oBOtXzAJ DNorZvzxlGX6RMjNZDiRL8xjDbZGs0MyUf7LpFiwVyIvUqMjCQUQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=ws0KqdvFH3XwtXp5R3fFs/7uB8dKBgNgbbf0sLlqWSQ=; b=Cm1lTCNm H1GTV87bZAQA3nZp3CCnKN4VnXkopdVobY8ibGCFtlwuyTI6CMZc9TW7fGR0hlQo 48vAGzWoTQb1uHDaKPouUsTJKzea3Of+z4qfR6leTRUjMrI7cHNS779zV88WI39l DM/nUTEsif5qI+20H+HkG1O7V07271JplmDY3k+mn4xATo5bswzj55y+IEL1x0a0 ZWBNb0bBsXCH+7/cSku3MMat0H6zeEAABGWNc9xISGjXy/AYE9dTWg5TjgSRfBXv C/TTRQXxz4AtTihHG/vbn501sIpvznaG3WZUx7a4xWRDChmASkjxWLB+v/cgTC2h lwNaNSnJHB3lGg==
X-ME-Sender: <xms:H-9cWbXvZB1DF_XtpYaCEFFG6uahm1-XSG8Zy0zM9fGfHPY5K30kNw>
X-Sasl-enc: 2t0e/nKKqHM4CUqp7D3ywBI+yN7ZcfZ9/7N6LNGKtsy4 1499262751
Received: from sjc-alcoop-8814.cisco.com (unknown [128.107.241.163]) by mail.messagingengine.com (Postfix) with ESMTPA id 5E07A7E6F1; Wed, 5 Jul 2017 09:52:30 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6593D9AA6@SJCEML702-CHM.china.huawei.com>
Date: Wed, 5 Jul 2017 09:52:28 -0400
Cc: Peter Saint-Andre - Filament <peter@filament.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-precis-7613bis@ietf.org" <draft-ietf-precis-7613bis@ietf.org>, "precis@ietf.org" <precis@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A991225C-AD24-41B3-B77A-630839B6594D@cooperw.in>
References: <4A95BA014132FF49AE685FAB4B9F17F6593D94F9@SJCEML702-CHM.china.huawei.com> <3feb4084-d038-9253-fc48-e739d846102f@filament.com> <f070d840-792d-8447-4e2a-f919019adff1@filament.com> <4A95BA014132FF49AE685FAB4B9F17F6593D9AA6@SJCEML702-CHM.china.huawei.com>
To: Linda Dunbar <linda.dunbar@huawei.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/4QltmpjaSgX9iQpemywElsd_cRQ>
Subject: Re: [precis] [Gen-art] Gen-art last call review of draft-ietf-precis-7613bis-07
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <precis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/precis>, <mailto:precis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/precis/>
List-Post: <mailto:precis@ietf.org>
List-Help: <mailto:precis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/precis>, <mailto:precis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jul 2017 13:52:39 -0000

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