From nobody Mon Jun 5 13:51:39 2017 Return-Path: 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 7584D129409 for ; Mon, 5 Jun 2017 13:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=filament-com.20150623.gappssmtp.com 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 QeJdd7BCHzSe for ; Mon, 5 Jun 2017 13:51:23 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974E71293EB for ; Mon, 5 Jun 2017 13:51:23 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id m47so74738401iti.1 for ; Mon, 05 Jun 2017 13:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Fyf29xjVdadQ/A1qPiRvpJSTIExvLYJK2lb+FCzTP4M=; b=AOcbW9/YfTO/KmrL4qFTZdgsHSpkpmnHQYSERdsupGrLvb++AVYXvM6a12yN3CYJ81 9IQOJfKYNN1q87FrYzN5YEN8WYP8Ve9XOCs9yFGeeMF4j95yzzx1F1oWHjXxJfi6b+mU fEWHR4Gh9psTUfJK/EXFKOOT8xdNZGzgHyJQzNlDh3/qknd55WQpL8o+DmFNLDFzrdKu nqEokQ6QDj4bXOL3llE887+ptIVNa2oagBWfAvC8jiJOlpNtE3oidN0s6b12EmVWwmnU baIHSe3m+L8fN1N9knDt/xt2AOrWyyE9NFF+KNyaPSW0UJAScGgUoMZhkGprRwBvr/tC F4gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Fyf29xjVdadQ/A1qPiRvpJSTIExvLYJK2lb+FCzTP4M=; b=PHzAfVlC2U40UXqoEuqlsBjZIF6v7XY3k1juZkT6dndP5zUqYA1zC748aDQR9AZJX9 T9HWa2QL5C6MnHwmedxe5hqyltwq523u2yQjOaAyB7zss5gqcEUGMF4x6oMJBhAXwuyu mAnoirGe1bS2cjGehR3VtDvPh9gihMe8Qjeo9nEIGmcoWjqlHyKi0QcIWfiM/Xjr3qOg mF5px/LkjemSBXUwTUcI+poAuHEw/lX3phXCGu9FY9yHaa6kra98lmtmMsHx1E+WQUBW GXphsT5PbczoB7LfJi0zunAndg+NluXC42I6QhKH9TuHVv1w8iq9NTd6V1/Uz523izd8 /88w== X-Gm-Message-State: AODbwcCNbSmo4Vu5GKd5SrpBnYY8QcR7Fg95wIowsJDA0LI0vKQXcUhU fhnlNN9MVMSSlfbo X-Received: by 10.107.147.86 with SMTP id v83mr23927796iod.233.1496695883000; Mon, 05 Jun 2017 13:51:23 -0700 (PDT) Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net. [98.245.40.52]) by smtp.gmail.com with ESMTPSA id e73sm2168056ioj.17.2017.06.05.13.51.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jun 2017 13:51:22 -0700 (PDT) To: Russ Housley , gen-art@ietf.org References: <149626145570.19916.16628797750334932421@ietfa.amsl.com> Cc: precis@ietf.org, ietf@ietf.org, draft-ietf-precis-7700bis.all@ietf.org From: Peter Saint-Andre - Filament Message-ID: <322a3c4f-24d7-f971-663e-50d4e64eb25d@filament.com> Date: Mon, 5 Jun 2017 14:51:20 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149626145570.19916.16628797750334932421@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] Genart last call review of draft-ietf-precis-7700bis-07 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 20:51:26 -0000 Hi Russ, thanks for your review and my apologies for the delayed reply. On 5/31/17 2:10 PM, Russ Housley wrote: > Reviewer: Russ Housley > 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 wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > . > > Document: draft-ietf-precis-7700bis-07 > Reviewer: Russ Housley > Review Date: 2017-05-31 > IETF LC End Date: 2017-06-13 > IESG Telechat date: 2017-07-06 > > Summary: Ready > > Major Concerns: None > > Minor Concerns: None > > Nits: > > Section 2.3 includes this note: > > Note: An entity SHOULD NOT apply the Case Mapping Rule during > enforcement, because typically it is appropriate only during > comparison. > > I question the inclusion of "typically" in this note. Can you simply > say that the Case Mapping Rule SHOULD only be used during comparison? That seems better, yes! Peter From nobody Tue Jun 13 08:13:45 2017 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4396C131C04; Tue, 13 Jun 2017 08:13:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: Cc: draft-ietf-precis-7564bis.all@ietf.org, ietf@ietf.org, precis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149736681626.7439.2555177998557552719@ietfa.amsl.com> Date: Tue, 13 Jun 2017 08:13:36 -0700 Archived-At: Subject: [precis] Secdir last call review of draft-ietf-precis-7564bis-07 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 15:13:36 -0000 Reviewer: Matthew Miller Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Document: draft-ietf-precis-7564bis-07 Reviewer: Matthew A. Miller Review Date: 2017-06-13 IETF LC End Date: 2017-06-13 IESG Telechat date: 2017-07-06 Summary: This document is ready to be published as a Standards Track document. This document defines a framework application protocols use to prepare, compare, and enforce conformance of internationalized strings. It obsoletes RFC 7564. This document is well written, and reinforces the security concerns discussed in Section 12 with references in the most relevant sections throughout the document. While much of it essentially proclaims "be aware herein be dragons", the arguments for not proscribing more are well laid out. Major Issues: NONE Minor Issues: NONE Nits: NONE From nobody Tue Jun 13 15:07:40 2017 Return-Path: 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 6C70612EB55; Tue, 13 Jun 2017 15:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 yJSakdwghrbm; Tue, 13 Jun 2017 15:07:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A47129AAD; Tue, 13 Jun 2017 15:07:34 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v5DM7XhO005725 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 13 Jun 2017 17:07:33 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] From: Ben Campbell Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <219DBC10-0046-4429-B170-1B075484CA91@nostrum.com> Date: Tue, 13 Jun 2017 17:07:32 -0500 Cc: precis@ietf.org To: draft-ietf-precis-7613bis.all@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [precis] AD Evaluation 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 22:07:38 -0000 Hi, This is my AD evaluation of draft-ietf-precis-7613bis-07. I think this draft is ready for IETF last call, which I will request = shortly. I have a few comments, all about references, that I think can = be handled along with any last call comments. Thanks! Ben. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 - Should the references to RFC 7613 in the IANA considerations be = updated to point to this document? (Some _say_ =E2=80=9Cthis = document=E2=80=9D). - There are some citations to RFC 4013 and 3545 that seem to be = overtaken by events. For example, there is a statement that 4013 is = obsoleted by this document, when in fact it was obsoleted by 7613. = Please check to make sure that any such citations (and their surrounding = context) will still make sense when this draft is published as an RFC. From nobody Tue Jun 13 15:16:19 2017 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8710612871F; Tue, 13 Jun 2017 15:16:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk CC: ben@nostrum.com, Marc Blanchet , precis@ietf.org, Marc.Blanchet@viagenie.ca, precis-chairs@ietf.org, draft-ietf-precis-7613bis@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149739217746.7597.6612165397719020325.idtracker@ietfa.amsl.com> Date: Tue, 13 Jun 2017 15:16:17 -0700 Archived-At: Subject: [precis] Last Call: (Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords) to Proposed Standard X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 22:16:18 -0000 The IESG has received a request from the Preparation and Comparison of Internationalized Strings WG (precis) to consider the following document: - 'Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-06-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The preparation, enforcement, and comparison of internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC 3454, and this document obsoletes RFC 7613. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-precis-7613bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-precis-7613bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Jun 13 16:02:45 2017 Return-Path: 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 9084C1293FF; Tue, 13 Jun 2017 16:02:32 -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=stpeter.im header.b=i6v+q1k6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LRiZ4i3H 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 D0y0x0B6-TiA; Tue, 13 Jun 2017 16:02:30 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655E1126D85; Tue, 13 Jun 2017 16:02:30 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D4DE020779; Tue, 13 Jun 2017 19:02:29 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 13 Jun 2017 19:02:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; 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=hYpJEJxhfVVoKbe4O9 FJfQCUGyOkOZtXIGVtx8SZlK4=; b=i6v+q1k6/3RkDdyRWdbVjaKk52EJbu9vBG S1ZCp9vy8bvDPu4MjFGYEU26QLhcBr+D88COd7cbIhLEGy8eOCbgvvDpsg1Zrv12 BvwwpPEJ0dTzMzCCBEbKBAvEFPgxg6XjEhcIGE6TKiS6miSiOLaVUxJ2R92vjybS 8N64tHDp9QZYYys6FzQ95yq7KL7g8m4BhAnaFoeTRXLaibxPAHiVHfhDdfBXdilY X3/igy/HJ/5hnF772sPxcfRkwB2fw0+smNnNI/JD4RaBbl52o2zVqIPH70/O+eCS Ul4X0BkVWkijuLoRnCmtr52dQz9NCYEwaK0FQaAWo1ZougjnJcwQ== 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=hYpJEJxhfVVoKbe4O9FJfQCUGyOkOZtXIGVtx8SZlK4=; b=LRiZ4i3H Y+t0L4SqQhDd5ky1syaUs/W1PWVGW74C+Ox/+xXemYFQxSyK2TXxsLDfy8YdvgBb 61HtmKw1RVV1cC25vkvpwGpg98D10LTA26xdS1VsVbLuhmCBIIZoz6PhTFo8CWnB QAN2i+Tv9K8EocfEQOplPwvtaoLKZwEXiupJvLeVt9lnq/prppaVan4O0vSoLw01 zaCvzCrTSjDSzjLF2ZA3n6Y4orSehQAkCaCWSBYhnOcQW0nRhUnOSu97w7LDFrtZ 4fmPaWjpE95PN0Vw+KoIajctdpRx12dyc55F8HDWedHobAFu3lDz6KenNyBRA427 rWLa3Ibjw641pA== X-ME-Sender: X-Sasl-enc: e0uQ2UhIxT09nbCV9NHeq4i1ouZ7RDKecz5XaNtGaO5W 1497394949 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 2ACD47E7A3; Tue, 13 Jun 2017 19:02:29 -0400 (EDT) To: Matthew Miller , secdir@ietf.org References: <149736681626.7439.2555177998557552719@ietfa.amsl.com> Cc: draft-ietf-precis-7564bis.all@ietf.org, ietf@ietf.org, precis@ietf.org From: Peter Saint-Andre Message-ID: <8ea90b99-3005-0afb-da93-63cd1abfc905@stpeter.im> Date: Tue, 13 Jun 2017 17:02:28 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149736681626.7439.2555177998557552719@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [precis] Secdir last call review of draft-ietf-precis-7564bis-07 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 23:02:33 -0000 Hi Matt, thanks for the review - it's much appreciated. Just so you know: through discussion of Daniel Migualt's secdir review of 7700bis (we're progressing them all together this time!), I realized that it might be help to add another example of visually confusing characters to 7564bis, so I plan to mention CYRILLIC SMALL LETTER A U+0430 vs. LATIN SMALL LETTER A U+0061 (which will be more familiar to readers than the Cherokee characters already in the document). Peter On 6/13/17 9:13 AM, Matthew Miller wrote: > Reviewer: Matthew Miller > Review result: Ready > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should > treat these comments just like any other last call comments. > > Document: draft-ietf-precis-7564bis-07 > Reviewer: Matthew A. Miller > Review Date: 2017-06-13 > IETF LC End Date: 2017-06-13 > IESG Telechat date: 2017-07-06 > > Summary: > > This document is ready to be published as a Standards Track document. > > This document defines a framework application protocols use to > prepare, compare, and enforce conformance of internationalized strings. > It obsoletes RFC 7564. > > This document is well written, and reinforces the security concerns > discussed in Section 12 with references in the most relevant sections > throughout the document. While much of it essentially proclaims > "be aware herein be dragons", the arguments for not proscribing more > are well laid out. > > Major Issues: NONE > > Minor Issues: NONE > > Nits: NONE > > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > From nobody Tue Jun 13 16:07:03 2017 Return-Path: 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 C39671293FF; Tue, 13 Jun 2017 16:07:01 -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=stpeter.im header.b=T/lkOs0q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XGVWALfp 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 xBhQteNAjcsd; Tue, 13 Jun 2017 16:07:00 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542C8126DFF; Tue, 13 Jun 2017 16:07:00 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 95A58206EF; Tue, 13 Jun 2017 19:06:59 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 13 Jun 2017 19:06:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; 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=hB4uaFt2wfOw2mDpYL +dCR4nQSEwdI7BF3/NVOgXihk=; b=T/lkOs0q86keMoM3gu8pTOHMweJzMdBXTu 3ZzrGHM0VnmNdhOOzLxlkFIOUJ5ouiK2qiEyr0bxi0bG+iEsznhQOmPA7OafGV/k H34TyQWNX8MAnK8xOQ/OV+5hZKnXzIL/7w/NuTkZf+2o1d6S8y9MaNQ4AtFOnlrt DVNpDSoToZcdEJ8/CKEcufjh6p2hzq7Vqx/xnL/GjY00fk4NFr9MZ8L8Dr8g7vir 3T5YXvKtnvPRGKnXgaZ9Yi3XtsUhP3VSLY1F9nENrHoUxErPFn0JmmQrUK+2rImB LNkC7XOYq2lf8Y/ccKDXk6ubLszkVuR80uTczhCrtsyl7MoK4W/A== 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=hB4uaFt2wfOw2mDpYL+dCR4nQSEwdI7BF3/NVOgXihk=; b=XGVWALfp LgJjuPBnBL4uWX9N6564baN+R4m1ZQwaD8jecFtwzw36f+w6JhFbyjkltYrCgGUF 0MKhdHmAKIV7VACEmCVWV8+JmeXCGhHVnT+yY6wA/1Au58G6YULV9q+Et0XAHfvE wGYFTW1UZSm2IeI3Jy3onzFQWfYCagcJDizDHhLgWZ60TFnqU+6IMSAcr2qlDseZ 2Ud/e9SFZg7x5vo58KeiThNsfyh4nDprpcQd/IW+4mZfNN1U6EgiMk7B7aVBkkyS MK5BfPOdien5sPIfa664gQ8CzCVkRZrmORy2ORor/KL6TweN5c8Zt/lkCmkJCTV0 i0d1O69OZqFPdA== X-ME-Sender: X-Sasl-enc: NgOQrhrbjtz3rLRwypQ+D1eoK3K/0xQwCFs6IwCeSCY9 1497395219 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 0AF1C7E865; Tue, 13 Jun 2017 19:06:58 -0400 (EDT) To: Ben Campbell , draft-ietf-precis-7613bis.all@ietf.org References: <219DBC10-0046-4429-B170-1B075484CA91@nostrum.com> Cc: precis@ietf.org From: Peter Saint-Andre Message-ID: Date: Tue, 13 Jun 2017 17:06:57 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <219DBC10-0046-4429-B170-1B075484CA91@nostrum.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [precis] AD Evaluation 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 23:07:02 -0000 On 6/13/17 4:07 PM, Ben Campbell wrote: > Hi, > > This is my AD evaluation of draft-ietf-precis-7613bis-07. > > I think this draft is ready for IETF last call, which I will request > shortly. I have a few comments, all about references, that I think > can be handled along with any last call comments. > > Thanks! > > Ben. ——————— > > - Should the references to RFC 7613 in the IANA considerations be > updated to point to this document? (Some _say_ “this document”). Yes, they should. I actually made that change the other day, along with cross-references to 7564bis instead of RFC 7564 (etc.)... https://github.com/stpeter/precis-framework/commit/58e4b072f9838fe4cc454594bff2e6e64daaf73b#diff-3956fe36c870ed54d75e6a05394dd92f > - There are some citations to RFC 4013 and 3545 that seem to be > overtaken by events. For example, there is a statement that 4013 is > obsoleted by this document, when in fact it was obsoleted by 7613. > Please check to make sure that any such citations (and their > surrounding context) will still make sense when this draft is > published as an RFC. Good catch - we'll clean that up. (The references to the older specs might be appropriate where we're trying to show the historical continuity of thinking on these issues, but not when we're talking about which documents this one obsoletes.) Peter From nobody Tue Jun 13 17:47:37 2017 Return-Path: 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 0B26712EB80; Tue, 13 Jun 2017 17:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 U8jWToYXHTyF; Tue, 13 Jun 2017 17:47:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39061129AD2; Tue, 13 Jun 2017 17:47:34 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v5E0lWf7031590 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 13 Jun 2017 19:47:33 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Tue, 13 Jun 2017 19:47:33 -0500 Cc: draft-ietf-precis-7613bis.all@ietf.org, precis@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <04E8BF73-876F-4EEF-B36A-F08180D61727@nostrum.com> References: <219DBC10-0046-4429-B170-1B075484CA91@nostrum.com> To: Peter Saint-Andre X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [precis] AD Evaluation 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 00:47:36 -0000 > On Jun 13, 2017, at 6:06 PM, Peter Saint-Andre = wrote: >=20 > On 6/13/17 4:07 PM, Ben Campbell wrote: >> Hi, >>=20 >> This is my AD evaluation of draft-ietf-precis-7613bis-07. >>=20 >> I think this draft is ready for IETF last call, which I will request >> shortly. I have a few comments, all about references, that I think >> can be handled along with any last call comments. >>=20 >> Thanks! >>=20 >> Ben. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>=20 >> - Should the references to RFC 7613 in the IANA considerations be >> updated to point to this document? (Some _say_ =E2=80=9Cthis = document=E2=80=9D). >=20 > Yes, they should. I actually made that change the other day, along = with > cross-references to 7564bis instead of RFC 7564 (etc.)... >=20 > = https://github.com/stpeter/precis-framework/commit/58e4b072f9838fe4cc45459= 4bff2e6e64daaf73b#diff-3956fe36c870ed54d75e6a05394dd92f Excellent. Hopefully you=E2=80=99ve already fixed any comments that = might come up in IETF last call or IESG review, too :-) >=20 >> - There are some citations to RFC 4013 and 3545 that seem to be >> overtaken by events. For example, there is a statement that 4013 is >> obsoleted by this document, when in fact it was obsoleted by 7613. >> Please check to make sure that any such citations (and their >> surrounding context) will still make sense when this draft is >> published as an RFC. >=20 > Good catch - we'll clean that up. (The references to the older specs > might be appropriate where we're trying to show the historical > continuity of thinking on these issues, but not when we're talking = about > which documents this one obsoletes.) >=20 Perfect, thanks! Ben. From nobody Tue Jun 13 18:02:33 2017 Return-Path: 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 49977129423; Tue, 13 Jun 2017 18:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 RSYQUWUkPIAz; Tue, 13 Jun 2017 18:02:30 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B061252BA; Tue, 13 Jun 2017 18:02:30 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dKwhX-000MWa-2U; Tue, 13 Jun 2017 21:02:27 -0400 Date: Tue, 13 Jun 2017 21:02:22 -0400 From: John C Klensin To: Peter Saint-Andre , Matthew Miller , secdir@ietf.org cc: draft-ietf-precis-7564bis.all@ietf.org, ietf@ietf.org, precis@ietf.org Message-ID: In-Reply-To: <8ea90b99-3005-0afb-da93-63cd1abfc905@stpeter.im> References: <149736681626.7439.2555177998557552719@ietfa.amsl.com> <8ea90b99-3005-0afb-da93-63cd1abfc905@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [precis] Secdir last call review of draft-ietf-precis-7564bis-07 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 01:02:32 -0000 --On Tuesday, June 13, 2017 17:02 -0600 Peter Saint-Andre wrote: > Hi Matt, thanks for the review - it's much appreciated. > > Just so you know: through discussion of Daniel Migualt's > secdir review of 7700bis (we're progressing them all together > this time!), I realized that it might be help to add another > example of visually confusing characters to 7564bis, so I plan > to mention CYRILLIC SMALL LETTER A U+0430 vs. LATIN SMALL > LETTER A U+0061 (which will be more familiar to readers than > the Cherokee characters already in the document). Peter, I don't want to throw the proverbial spanner in the works, but, just as things changes just as the original PRECIS documents were being published, I wonder if some other things that appear to be in process now could do it to us again. For example, consider draft-freytag-troublesome-characters. Despite having contributed to it and expecting to continue to do so, I've got some misgivings about the document and proposed registry as IETF work but, if it were to be adopted, it seems to me that it would be useful for the PRECIS documents to normatively reference it, especially for Identifier Class. To some extent, that draft is a remedy for some of the issues raised in the long-stalled draft-klensin-idna-5892upd-unicode70, but it doesn't make those issues, and the lack of comprehensiveness of normalization, go away. Probably less important, but it might be advantageous to incorporate some of the "whatever decisions you make, people will probably hold you accountable if there are problems" tone of draft-klensin-idna-rfc5891bis into the PRECIS documents. It might even be that RFC 7940, possibly supplemented by draft-freytag-lager-variant-rules, would be a better, or at least useful alternative, way to present some or all of the PEECIS rule sets than the current approach. On a somewhat different topic, the Greek, Latin, and Cyrillic scripts are so closely related that finding examples of pairs of similar-looking characters is in the low-lying fruit category because the similarities are not coincidences but the result of derivation and extensive borrowing (something of the same thing can be said for the Latin-Cherokee relationship, at least in printed, rather than cureive, forms). The examples that may be more scary, just because there is no evolutionary theory to predict were to look, would be things like the resemblances among the Latin U+006F, the Lao U+0ED0, the Ethiopic U+12D0, the New Tai Lue U+19D0, and of course the ASCII/European digit U+0030 and probably many more, with the group perhaps best described as "open circle graphemes" or something like that. best, john From nobody Fri Jun 23 13:25:43 2017 Return-Path: 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 B44111293D9; Fri, 23 Jun 2017 13:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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=stpeter.im header.b=XuMrT1Iu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nXsYfYp4 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 G-YA7y4yUOSt; Fri, 23 Jun 2017 13:25:32 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988D112943C; Fri, 23 Jun 2017 13:25:32 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D9F4C20D2C; Fri, 23 Jun 2017 16:25:31 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 23 Jun 2017 16:25:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; 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=m89Z2sg84W5HEJcRce fmSyCTT/Yym/7rkqtq+2c79JE=; b=XuMrT1IuuJjVAmI3g/XVqcK1dJ6G5JnsdI WaCz1Ya6Hj2InSYP6kankNOznKD/pzojBtwYPRWlggbJYuOzY1e+AonBsixGyqYZ oLQ5hkJ0Xugh0HPCn2S67SnT2T8mcLc7IwoJC3QzsJMOBZ+19+KAs34psMmzHA8R 0fu21ClK5oSpVekNyzqJUlYcqoYmZM44bdsEYghvXkHgbv7UvziVLPssrXha8lyp wyugjYye4xQc8/MQFyLnieWjAYUZRAzjdHQ0K8bGeLI634/a0ywxrELA87B8DNDa dCuNC0aHhLXSdCwvZPhRKNUgz5iDw65AVvabkk2TTHYx7sKJBpmg== 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=m89Z2sg84W5HEJcRcefmSyCTT/Yym/7rkqtq+2c79JE=; b=nXsYfYp4 9YsJWx8jYfdeU4l4tTzjZv/QfeCOUzWZkqAy+YJmzg72UgdNq4cwmq++7tCmz2FX EDeMO3b/BmLsddiguFVBSKLaE7ZdPNzgyaPfYdjyQJRQgYqaiFcmYIfYhj0bJ2XJ O7W10j6lLUdQIEe2MbRCpgrYh5tipARf8EABDQelZzeTbasBCsYdp0KJUNXwXKIF CIoZRX2l4c5GDc5ssmV5hDsyC4U19Pin/UZRTBZsjIvTEPuuz6niCt5hUF4g36mh NICE3zK70qzNHyftF/nxkkCtQe7iJj25iZpY+GOtQIKJSVAbMR5cNta3NTu4EPtI nkWOh93YvjDQdA== X-ME-Sender: X-Sasl-enc: AvkEJi7ALSA9VHw+2BZ4ozCZ+qc/arQAlXavjCIJO6Ap 1498249531 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 0C24E24009; Fri, 23 Jun 2017 16:25:30 -0400 (EDT) To: John C Klensin , Matthew Miller , secdir@ietf.org References: <149736681626.7439.2555177998557552719@ietfa.amsl.com> <8ea90b99-3005-0afb-da93-63cd1abfc905@stpeter.im> Cc: draft-ietf-precis-7564bis.all@ietf.org, ietf@ietf.org, precis@ietf.org From: Peter Saint-Andre Message-ID: <74ad8473-6036-2965-6833-7d59b0f9b038@stpeter.im> Date: Fri, 23 Jun 2017 14:25:29 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [precis] Secdir last call review of draft-ietf-precis-7564bis-07 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 20:25:35 -0000 Hi John, Thanks for your note, and my apologies for the slow reply. Comments inline. On 6/13/17 7:02 PM, John C Klensin wrote: > > > --On Tuesday, June 13, 2017 17:02 -0600 Peter Saint-Andre > wrote: > >> Hi Matt, thanks for the review - it's much appreciated. >> >> Just so you know: through discussion of Daniel Migualt's >> secdir review of 7700bis (we're progressing them all together >> this time!), I realized that it might be help to add another >> example of visually confusing characters to 7564bis, so I plan >> to mention CYRILLIC SMALL LETTER A U+0430 vs. LATIN SMALL >> LETTER A U+0061 (which will be more familiar to readers than >> the Cherokee characters already in the document). > > Peter, > > I don't want to throw the proverbial spanner in the works, but, > just as things changes just as the original PRECIS documents > were being published, I wonder if some other things that appear > to be in process now could do it to us again. > > For example, consider draft-freytag-troublesome-characters. > Despite having contributed to it and expecting to continue to do > so, I've got some misgivings about the document and proposed > registry as IETF work but, if it were to be adopted, it seems to > me that it would be useful for the PRECIS documents to > normatively reference it, especially for Identifier Class. Given that we're dealing with a seemingly tenuous hypothetical, the best approach might be for that I-D (if eventually published as an RFC) to update the relevant PRECIS and IDNA RFCs? We'll need to do that for the IDNA RFCs anyway because they're not currently under revision, as the PRECIS RFCs are. > To > some extent, that draft is a remedy for some of the issues > raised in the long-stalled draft-klensin-idna-5892upd-unicode70, > but it doesn't make those issues, and the lack of > comprehensiveness of normalization, go away. I'm not sure that anything could make those issues go away. > Probably less important, but it might be advantageous to > incorporate some of the "whatever decisions you make, people > will probably hold you accountable if there are problems" tone > of draft-klensin-idna-rfc5891bis into the PRECIS documents. It > might even be that RFC 7940, possibly supplemented by > draft-freytag-lager-variant-rules, would be a better, or at > least useful alternative, way to present some or all of the > PEECIS rule sets than the current approach. One question in my mind is whether an approach such as that of RFC 7940 is so much better that it's worth scrapping / rewriting the PRECIS bis I-Ds along those lines. Right now it's not even clear what criteria we'd use to judge "better" or "useful" here - presumably specification clarity and precision, algorithmic completeness, and reduced error rates in code implementations might factor into the decision. But I don't sense that we have a good handle on making these decisions yet. Another tradeoff here is making the relatively small fixes to the PRECIS RFCs in a relatively short amount of time (measured in IETF years) vs. making a larger overhaul in a longer amount of time (and whether there is sufficient energy to do so). Given our track record in internationalization, I'd prefer to get these PRECIS fixes done now and then look at a larger effort. > On a somewhat different topic, the Greek, Latin, and Cyrillic > scripts are so closely related that finding examples of pairs of > similar-looking characters is in the low-lying fruit category > because the similarities are not coincidences but the result of > derivation and extensive borrowing (something of the same thing > can be said for the Latin-Cherokee relationship, at least in > printed, rather than cureive, forms). Indeed. > The examples that may be > more scary, just because there is no evolutionary theory to > predict were to look, would be things like the resemblances > among the Latin U+006F, the Lao U+0ED0, the Ethiopic U+12D0, the > New Tai Lue U+19D0, and of course the ASCII/European digit > U+0030 and probably many more, with the group perhaps best > described as "open circle graphemes" or something like that. Well, circles are common enough, so it's reasonable that they'd show up in many different contexts as both letters and numbers (which is why we have confusion between the letter "O" and the number zero even in the basic Latin repertoire) and even as punctuation marks and symbols. But I like the examples you've mentioned and will add them to 7564bis to further illustrate the problem, all the while understanding full well that a complete list of examples or an explanation of why such examples are problematic is outside the scope of this specification (which is why we point to UTR36 and UTS39). Peter From nobody Sun Jun 25 22:50:17 2017 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCC6127058; Sun, 25 Jun 2017 22:50:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey To: Cc: draft-ietf-precis-7613bis.all@ietf.org, iesg@ietf.org, precis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149845620057.31750.11952736688634266964@ietfa.amsl.com> Date: Sun, 25 Jun 2017 22:50:00 -0700 Archived-At: Subject: [precis] Secdir last call review of draft-ietf-precis-7613bis-07 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 05:50:01 -0000 Reviewer: Joseph Salowey Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is document is ready with nits. This document is an update to RFC 7613. A few Minor comments: 1. I think it would be good to show the zero-length password is not allowed in table 4 (18 | <> | zero-length password). There are lots of cases where allowing zero-length passwords has led to problems. Disallowing zero-length passwords is helpful. 2. Comparisons of passwords is a touchy subject. I can't think of a case where it would be preferable to do a direct password comparison. In most cases the comparison will be done against a salted-hashed transform of the password or involve some other cryptographic operation. I think it would be good to discuss this briefly in the security considerations section, sample text below "Password Comparison Verification of passwords during authentication will not use the comparison defined in section 4.2.3. Instead cryptographic calculations are performed to verify the password. In most cases the password will be prepared as in section 4.2.1 and meet the rules enforced in section 4.2.2 before the calculations are performed." From nobody Mon Jun 26 10:40:17 2017 Return-Path: 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 7DE1812EB23; Mon, 26 Jun 2017 10:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=bZcLCKc7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CcSscp/j 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 xm6fGjvlM8pN; Mon, 26 Jun 2017 10:40:11 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7C112EB1C; Mon, 26 Jun 2017 10:40:11 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C0550209CE; Mon, 26 Jun 2017 13:40:10 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 26 Jun 2017 13:40:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; 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=vQIIuXe5RL6q2vFTsY PaX/mPzkv0XUl1x6nMryZ8xT8=; b=bZcLCKc7xbLeYzWWv9GPEtv2vXkB3JiDk5 KGzpY5fbk7x2N6Epl7g5xPAeAbHkvXCSuavi+EtrqD3fPlYaJBLNLSgakQ82zEFt d/b2UczV/JEBYysQJ69iM8cPv/ifltGV7WmEkVV2Xg2gyTRS1vavMrhQa3lnYm/y emA1ZrwYYTri0TkY+JLzdZZyIWBimssDR7Gl9BiX6sdWpkEZKC9Ohp5dtKxdWVu+ qWHGJPsEydToxluFez3UZ6fNDdqSflqkVkNx9R/xAyazHsjv9ZIP3i60SgUffxjB RlKPI356wkhx8ScG1nY2FmTlvKvGVmURIW2CLnek3Z+aPdzgy8DA== 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=vQIIuXe5RL6q2vFTsYPaX/mPzkv0XUl1x6nMryZ8xT8=; b=CcSscp/j AXtO09Tlzji5eypBWld9ee+0V8Tkd9EkMtxf6/LT4RW4l+sgHSa8+9RoFGu2g13n xmKwS6T2GFHrwta4k3VDskieWjKAIndNx3g3NpoG+o18UCM8my+YXELWyG5/Q9XA 6avhSfZ68eacX3wCXtU6VTYK0fCp4JKdcZTAimwFhlqqpJvhO42pPX1lsG1ZUO6+ famef+AGFW2+LqrQ5S62DD4bk6wWx5RGc432ow4rnPjEAIy9qDO0GTMfUSXrXMLt SDSaUKu2GhUuDAqZ6XTUlVkVRb5uF772pml5FkKsMxyg6/QW2MwTK3tagQ/dR2Fg R3DbTkHAI3m24A== X-ME-Sender: X-Sasl-enc: 0xAl+sTZiWwGlOBv3TGYng8gKq6Gc1Cq0dD58WG0syVo 1498498810 Received: from aither.local (c-98-245-40-52.hsd1.co.comcast.net [98.245.40.52]) by mail.messagingengine.com (Postfix) with ESMTPA id 10BC87E760; Mon, 26 Jun 2017 13:40:09 -0400 (EDT) To: Joseph Salowey , secdir@ietf.org References: <149845620057.31750.11952736688634266964@ietfa.amsl.com> Cc: draft-ietf-precis-7613bis.all@ietf.org, iesg@ietf.org, precis@ietf.org From: Peter Saint-Andre Message-ID: <18393d54-4882-e3f3-a0b0-7af814d51f65@stpeter.im> Date: Mon, 26 Jun 2017 11:40:08 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149845620057.31750.11952736688634266964@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] Secdir 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 17:40:13 -0000 Hi Joe, thanks for the review. Comments inline. On 6/25/17 11:50 PM, Joseph Salowey wrote: > Reviewer: Joseph Salowey > Review result: Has Nits > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is document is ready with nits. > > This document is an update to RFC 7613. A few Minor comments: > > 1. I think it would be good to show the zero-length password is not allowed in > table 4 (18 | <> | zero-length password). There are lots of cases where > allowing zero-length passwords has led to problems. Disallowing zero-length > passwords is helpful. Good point - we'll add that. > 2. Comparisons of passwords is a touchy subject. I can't think of a case > where it would be preferable to do a direct password comparison. In most > cases the comparison will be done against a salted-hashed transform of the > password or involve some other cryptographic operation. I think it would be > good to discuss this briefly in the security considerations section, sample > text below > > "Password Comparison > > Verification of passwords during authentication will not use the comparison > defined in section 4.2.3. Instead cryptographic calculations are performed to > verify the password. In most cases the password will be prepared as in > section 4.2.1 and meet the rules enforced in section 4.2.2 before the > calculations are performed." That's helpful - thanks for the suggested test. A forward pointer from Section 4.2.3 also seems desirable. Peter From nobody Mon Jun 26 16:48:53 2017 Return-Path: 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 698F812EB7D for ; Mon, 26 Jun 2017 16:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=filament-com.20150623.gappssmtp.com 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 BIDxFBmXOtlm for ; Mon, 26 Jun 2017 16:48:38 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D3812EB88 for ; Mon, 26 Jun 2017 16:48:36 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id m84so7361152ita.0 for ; Mon, 26 Jun 2017 16:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ctWzBz5Sa/qA5u2SfM2HjW4lPHM1PoJajvbDEgvqcRc=; b=ZF4U9AMSxJ05zRAhHbXNJbCgil7KJjrLKy1h0iYd23LM5/YvmLUl1eAg8vT2bFFXhC moEH4EoPvZvu8ktviT5vIva+7rupEI9m7cuIt1bcTIfMdB+35WGGsRVwxb1bygbPSinA Wy68BVcghl9RKXj4z2bQKQIIkhsP1QK2uWfFu8ImOpKjZyZi4Uv8SqyXcuF/efGNdJ0k cW/b3VoxNTyGYiMV1SffAV35widaGx5V2ermrKfx7GKWRFzD+nemBiuN7VS9+5NLyHtz P0C9OonU+dy6unYiBWNFU9UjfRnZ1FRlrjnjvlGxdwrI9I7YT5Rz/vLshCPtRzmjZ4c7 kphA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ctWzBz5Sa/qA5u2SfM2HjW4lPHM1PoJajvbDEgvqcRc=; b=BcqDkS8eWqfHNF/ftnUW9tNJKTPV2a8oaMxU0yry2OHTZApMx0QQYAylfmwlkIcCa0 kV8dgtQ5XMaXcDNZH0wWhuBhiDKNIS0QZu28YDeze90Z1JZdF166ZEiqtzU6GMWZ9Gis BakLcPh2HcY7075dHZd4LYQCtVsPe71s+X7WLHrlqXJHaalh754684QJvqY3zBtUC70k tR/6zk75DGBsJjH+5OJnY/4EewC/QHtG7dDX/bM3el4HzCwEPy1m4rNdvo3DSY0n5QVu bWbzTNuNdeTXTgpOk2G33D2+fMcCrhol9vTFfKEb++12fUQPElZI2IRRMT0j1Unn3434 GwBw== X-Gm-Message-State: AKS2vOz3AEfQEpwWIasT19iK46MAWOm9HWvlbgq1hFZ17uGi4ri3tZ+q HkUS9OL8SCZTsktw X-Received: by 10.36.88.196 with SMTP id f187mr196964itb.86.1498520915867; Mon, 26 Jun 2017 16:48:35 -0700 (PDT) Received: from aither.local ([2601:282:4202:67d3:50b:8144:6d4:65e9]) by smtp.gmail.com with ESMTPSA id e34sm796098ioj.62.2017.06.26.16.48.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jun 2017 16:48:35 -0700 (PDT) To: Linda Dunbar , "gen-art@ietf.org" References: <4A95BA014132FF49AE685FAB4B9F17F6593D94F9@SJCEML702-CHM.china.huawei.com> Cc: "ietf@ietf.org" , "draft-ietf-precis-7613bis@ietf.org" , "precis@ietf.org" From: Peter Saint-Andre - Filament Message-ID: <3feb4084-d038-9253-fc48-e739d846102f@filament.com> Date: Mon, 26 Jun 2017 17:48:34 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6593D94F9@SJCEML702-CHM.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [precis] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 23:48:40 -0000 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 > > . > > 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? Peter -- Peter Saint-Andre https://filament.com/ From nobody Mon Jun 26 18:41:20 2017 Return-Path: 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 0F7E812EB9A for ; Mon, 26 Jun 2017 18:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=filament-com.20150623.gappssmtp.com 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 0C-ERk14xyl7 for ; Mon, 26 Jun 2017 18:41:16 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7621286CA for ; Mon, 26 Jun 2017 18:41:15 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id h134so10364427iof.2 for ; Mon, 26 Jun 2017 18:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dFD9Zk6KlY8UN368gfze5cwKU3iepFsuuBSNkFkZ6yU=; b=xMxx7oNdR0r2xNgCiGkCcOTTkfebjJYmN76oDjxWkjcqAolT9Ke1bP71ZyxocgpVSI jRSMecL/fig2aN5WTZrtJgWN4V2HGcybxVwP0aYrDCO5mkUwu2WY44mjskC5pJ21rJCQ j7yZ0R9yimlQpBVDtOoBxRIfzycfLtfjucNBmX8c8BkHh6SFH4bTF5BFJVU9j6vFK4up FWZb55Zlq0JHJn0HOfDppMJGBHaq3VdUyINL2LWhcCgfFkh732qD5n/DE7YOSrUS5co7 6T4yXvJi/RD4EcfFR9wTE3JN+UzRnWADyXbm3dQS/2fbNvHQvYDgijUI+9mjjqAqttPR jlVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dFD9Zk6KlY8UN368gfze5cwKU3iepFsuuBSNkFkZ6yU=; b=msTyHD5y71+3i9n1XG5bN/+VqMXN5edsInmObvJJYPTliLUFAjfujaob9BqOyZlO/v ftF/sytqUoVHfuQOQw4TIDCo3ZpE8xjwBPtKVyl0KaCTW/WiX9XAuNuW8P5IS1qTi5qQ K65r65WEqrxdeExmsV0widQE5sS0R6yJuimvXrENohY2/vKXheyNVXRima2O7Tv5u0AD FA5qck32wP43O7isWGa8nEK5h8mqpjynBDaI0XVwF8+/Rycca6xr+duy/2Ylp1qSZWfU Df2dWJsX28/2hHTT9RDNrKUVxSmZnjMKsBxPuJ0V8mhmNtvgY7NcpRt6cSnwOK9nW3jP QE9A== X-Gm-Message-State: AKS2vOx7wvWOcObuG4EF6iwMY5lWm0U9yvAGfVs2/2bB5Lguiw/FpwUW fLbG6g/a/bKz7tUP X-Received: by 10.107.169.28 with SMTP id s28mr4696808ioe.1.1498527675181; Mon, 26 Jun 2017 18:41:15 -0700 (PDT) Received: from aither.local ([2601:282:4202:67d3:5c8c:f89e:d54d:fabe]) by smtp.gmail.com with ESMTPSA id z64sm916712iod.55.2017.06.26.18.41.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jun 2017 18:41:11 -0700 (PDT) To: Peter Saint-Andre - Filament , Linda Dunbar , "gen-art@ietf.org" References: <4A95BA014132FF49AE685FAB4B9F17F6593D94F9@SJCEML702-CHM.china.huawei.com> <3feb4084-d038-9253-fc48-e739d846102f@filament.com> Cc: "precis@ietf.org" , "ietf@ietf.org" , "draft-ietf-precis-7613bis@ietf.org" From: Peter Saint-Andre - Filament Message-ID: Date: Mon, 26 Jun 2017 19:41:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3feb4084-d038-9253-fc48-e739d846102f@filament.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [precis] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 01:41:18 -0000 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 >> >> . >> >> 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 From nobody Tue Jun 27 08:45:42 2017 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB7A1200B9; Tue, 27 Jun 2017 08:45:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: precis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149857833414.31049.9369247554989293669@ietfa.amsl.com> Date: Tue, 27 Jun 2017 08:45:34 -0700 Archived-At: Subject: [precis] I-D Action: draft-ietf-precis-7564bis-08.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 15:45:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings of the IETF. Title : PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols Authors : Peter Saint-Andre Marc Blanchet Filename : draft-ietf-precis-7564bis-08.txt Pages : 43 Date : 2017-06-27 Abstract: Application protocols using Unicode code points in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 7564. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7564bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-precis-7564bis-08 https://datatracker.ietf.org/doc/html/draft-ietf-precis-7564bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7564bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 27 08:46:05 2017 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8AD129BA4; Tue, 27 Jun 2017 08:45:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: precis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149857834475.31129.4071969636632626238@ietfa.amsl.com> Date: Tue, 27 Jun 2017 08:45:44 -0700 Archived-At: Subject: [precis] I-D Action: draft-ietf-precis-7613bis-08.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 15:45:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords Authors : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-7613bis-08.txt Pages : 26 Date : 2017-06-27 Abstract: This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. This document obsoletes RFC 7613. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7613bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-precis-7613bis-08 https://datatracker.ietf.org/doc/html/draft-ietf-precis-7613bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7613bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 27 08:46:11 2017 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 836A5129BA4; Tue, 27 Jun 2017 08:45:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: precis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149857835750.31069.5539969448849501568@ietfa.amsl.com> Date: Tue, 27 Jun 2017 08:45:57 -0700 Archived-At: Subject: [precis] I-D Action: draft-ietf-precis-7700bis-08.txt X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 15:45:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings of the IETF. Title : Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames Author : Peter Saint-Andre Filename : draft-ietf-precis-7700bis-08.txt Pages : 11 Date : 2017-06-27 Abstract: This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames", "display names", or "petnames") for people, devices, accounts, websites, and other entities. This document obsoletes RFC 7700. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-7700bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-precis-7700bis-08 https://datatracker.ietf.org/doc/html/draft-ietf-precis-7700bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-precis-7700bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 27 08:48:59 2017 Return-Path: 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 99876129A9F for ; Tue, 27 Jun 2017 08:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=HYa4zJlY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PZH+c1+o 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 ThfMuyGsRzbS for ; Tue, 27 Jun 2017 08:48:56 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3896A128BA2 for ; Tue, 27 Jun 2017 08:48:56 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9C43F219EF; Tue, 27 Jun 2017 11:48:55 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 27 Jun 2017 11:48:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=to4uEKC5HR6ScciSIBm1/xi/d0RExbuyrhm3FbPab v0=; b=HYa4zJlYqIh9F2htNFjPqE/0KdhaidwdtzYSs+KTkvo5WgDHclts/+vqm Jq4mna6x5WF+CeuIVdAAEvxTXBuePNgnBHoJogRmSuhByj05i5OEIvHL9/3746nl 3Oe65WgKYWLMrCIHId+eaNl1SPv+cjsSzVHBiqoTmFGjy9Htd8P2yjo5OHTHRAkc APcYLuEsU/ButviayYvHEAwInH0t5G8OPHj0ZBELZgK8V3BX1GMOQMovsBQB9uDG GhOhL1IZINdOmf4HoKTX0+McjWgZNhJNyfm7FBQRRsyl/ZOPzNQgZK6dXKOBo825 vchpSQ63ChFadzhzvdzDGEGvXi+Bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=to4uEKC5HR6ScciSIB m1/xi/d0RExbuyrhm3FbPabv0=; b=PZH+c1+oiLJu6v9bddUffgItCaIFHdnQeU aZuWtv7RnAm2pGviZnRrUiGbgnC14eVqC1esCKGjoTv9D9bVRM0mazDa3UgiUV9Z H6bkoYDaSNqB3hh/qaeLVy9hDhLKPF2aR97lCIs6yqmEHBsvyUecqP1lCsaqPM1j d1w6wahCrUfpELvK/Fq3ZeuS2Os7OqdL1g8P9tT6fUhBBnLSUhfHwBvSMeHOo1sp 1eFoncvzedg3ThLnil0oWjkyHj3jiLbefqq/b8vbr+xcmOnUD0IAI/2T4mLf4k3P eL18C1HjiKcKmwdFpnPxXhtNDXtifrHEYETCETiOZZ/AlXBFLfDw== X-ME-Sender: X-Sasl-enc: gtMzVC7cvI9eWPBEmFSJDqCxnMG41ieY4W/EyIafEmm4 1498578535 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 32F372475F; Tue, 27 Jun 2017 11:48:55 -0400 (EDT) To: "precis@ietf.org" From: Peter Saint-Andre Message-ID: Date: Tue, 27 Jun 2017 09:48:54 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [precis] version -08 I-Ds X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 15:48:57 -0000 I've updated the PRECIS bis I-Ds to reflect comments received during IETF Last Call (including from various directorate reviews). Peter From nobody Tue Jun 27 13:22:33 2017 Return-Path: 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 6E74D126B71; Tue, 27 Jun 2017 13:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 kab8yM_smbd0; Tue, 27 Jun 2017 13:22:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE1D1200ED; Tue, 27 Jun 2017 13:22:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPY04760; Tue, 27 Jun 2017 20:22:13 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 27 Jun 2017 21:22:11 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML703-CHM.china.huawei.com ([169.254.5.136]) with mapi id 14.03.0301.000; Tue, 27 Jun 2017 13:22:05 -0700 From: Linda Dunbar To: Peter Saint-Andre - Filament , "gen-art@ietf.org" CC: "precis@ietf.org" , "ietf@ietf.org" , "draft-ietf-precis-7613bis@ietf.org" Thread-Topic: [precis] Gen-art last call review of draft-ietf-precis-7613bis-07 Thread-Index: AdLuzwlSicte5jFwS92cRaxDldpIjAAQlv4AAAPukoAAGGnvQA== Date: Tue, 27 Jun 2017 20:22:05 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6593D9AA6@SJCEML702-CHM.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F6593D94F9@SJCEML702-CHM.china.huawei.com> <3feb4084-d038-9253-fc48-e739d846102f@filament.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5952BE75.0116, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: befc2f0ab0b180b3a3ba228e0f21ff5f Archived-At: Subject: Re: [precis] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 20:22:18 -0000 Peter,=20 Thank you very much for the explanation and the revised wording. Your new w= ording is much clearer and help people to understand why to postpone the ch= ecking.=20 Thank you.=20 Linda Dunbar -----Original Message----- From: Peter Saint-Andre - Filament [mailto:peter@filament.com]=20 Sent: Monday, June 26, 2017 8:41 PM To: Peter Saint-Andre - Filament ; Linda Dunbar ; 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, >=20 > Thanks for your review. Comments inline. >=20 > On 6/26/17 4:53 PM, Linda Dunbar wrote: >> =20 >> Reviewer: Linda Dunbar >> Review result: Ready >> =20 >> I am the assigned Gen-ART reviewer for this draft. The General Area=20 >> Review Team (Gen-ART) reviews all IETF documents being processed by=20 >> the IESG for the IETF Chair. Please treat these comments just like=20 >> any other last call comments. >> =20 >> For more information, please see the FAQ at >> =20 >> . >> =20 >> 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 >> =20 >> Summary: >> The document is written very clear. Even for a person who is not=20 >> familiar with the App area, I can follow through the description. The=20 >> document is ready for publication as standard track document Major issue= s: >> =20 >> One Minor issue: >> =20 >> Page 6 last paragraph has: >> /SASL mechanisms SHOULD delay any case////mapping to the last=20 >> possible moment, such as when doing a lookup////by username,=20 >> performing username comparisons, or generating a////cryptographic=20 >> salt from a username (if the last possible moment////happens on the=20 >> server, then decisions about case mapping can be a////matter of=20 >> deployment policy). In keeping with [RFC4422], SASL////mechanisms are=20 >> not to apply this or any other profile to////authorization=20 >> identifiers, only to authentication identifiers./ >> =20 >> What does "last possible moment" mean? When I read it, I thought it=20 >> meant wait until you got all the characters. But the next sentence=20 >> mentions "..happens on the server". How is the "server" related to=20 >> the entity that check the user name & password? >=20 > Many authentication decisions happen on an application server to which=20 > a user-oriented client connects (think of an email client connecting=20 > to an email server). By "last possible moment" we're referring to=20 > processing within the application server or an authentication module=20 > thereof - for instance, instead of performing case mapping on first=20 > receiving data from the client (thus implying that the case=20 > information is lost through most of the processing stages), it's=20 > better to lose that information only at the very end. Do you feel it=20 > 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 From nobody Tue Jun 27 17:01:48 2017 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0711A124D68; Tue, 27 Jun 2017 17:01:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-precis-7564bis@ietf.org, Marc Blanchet , precis-chairs@ietf.org, Marc.Blanchet@viagenie.ca, precis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149860810601.18163.18269572715905629893.idtracker@ietfa.amsl.com> Date: Tue, 27 Jun 2017 17:01:46 -0700 Archived-At: Subject: [precis] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-precis-7564bis-08=3A_=28with_COMMENT=29?= X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 00:01:46 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-precis-7564bis-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-precis-7564bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- not a problem but I noticed that marc is author and shepherd of this document which looks a bit weird... From nobody Wed Jun 28 00:47:35 2017 Return-Path: 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 D663B129649; Wed, 28 Jun 2017 00:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kNCpEWl0k_nb; Wed, 28 Jun 2017 00:47:32 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8038012EB97; Wed, 28 Jun 2017 00:47:29 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id f92so43020722qtb.2; Wed, 28 Jun 2017 00:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=K0vNr7Z0xJDhgS1/tZLzPD4QxfTrMqc5GuXr3O5MVRQ=; b=RKvCgdsg+zdbJGekT+xvKZqg5OfNpDXbambeBvQ+kFgOaIm+EU+SihYRHs8UcVdWrj 8NUU0LOTNBhzLAhK0CA3wrz5V1L7myx9qscPfCfua2wJg0o849Co6PFGy2FO1n8cIPa4 4TiPh0sqWP5bqDSBw/A/K9RW6Y2yyxGYNMgKAdkzGpS6UW52Tg12QVzGPOvYE+FvMoFg HNSjOXsOhQBf9+9OWCPGGMb+Q3x4MdaEMfXwGjLJ9687BQJ+22epLUwD/KWi9O0V+1uc 4oUD7Qz5hpQVOUl0CSrhe/aI4yWy2Jah0P6qA06hw6HWMjTVAETOlvjf1b/s57x9Qg0B Ne9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=K0vNr7Z0xJDhgS1/tZLzPD4QxfTrMqc5GuXr3O5MVRQ=; b=QdOWZgXpaI0qC1eOOdJH73KsLs0x0+lppC1vCfwvJr+RDVFiRDl3wPcOzEKif6ioth msL0HOAyfvT9+h0/vUUAGmX4Xp0qFN+xg9OITb3kytxXeonDg5YyqVmM/FQZooU8a1XQ nnbZPh3Ll7V0wiLyff09+4if00WLG7pbhww5Xzn2N17tVSb+yNSciDKErSiZ/Ck/JCzS tkTnIvY512GO05TE+ZbXaccT3b4MnNntbNAWhrKItgX8m97n2IKf156vscKdhTLzYInS RfWrtzex6hXeZrUViA95BumwT2OxSXW4zmVHoMZUtHiLWLbuMP56QqqKO2+bdBlifchj 7+jQ== X-Gm-Message-State: AKS2vOz/IyrvHpLjnk/8lcTwtEgJrjIbc6q2XAGG24ye6c3ByOLn0Qjy aeZVhpB11x1Z4U750Ipm6ANfgqMW2g== X-Received: by 10.200.53.151 with SMTP id k23mr12023766qtb.104.1498636048744; Wed, 28 Jun 2017 00:47:28 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.37.40 with HTTP; Wed, 28 Jun 2017 00:47:28 -0700 (PDT) In-Reply-To: <149860810601.18163.18269572715905629893.idtracker@ietfa.amsl.com> References: <149860810601.18163.18269572715905629893.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Wed, 28 Jun 2017 09:47:28 +0200 X-Google-Sender-Auth: TwzhbPB6_FvolSj9zvDVS61H5I0 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-precis-7564bis@ietf.org, precis@ietf.org, precis-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [precis] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-precis-7564bis-08=3A_=28with_COMMENT=29?= X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 07:47:34 -0000 > not a problem but I noticed that marc is author and shepherd of this document > which looks a bit weird... Less weird when you know that this is an update to a doc that Marc was involved with, but that Marc wasn't involved with the update (except as chair). I think it actually makes him the best choice for shepherd, as he's familiar with the document and with the issues that needed updating. Barry From nobody Thu Jun 29 12:55:45 2017 Return-Path: X-Original-To: precis@ietf.org Delivered-To: precis@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4327712EAB4; Thu, 29 Jun 2017 12:55:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley To: Cc: precis@ietf.org, ietf@ietf.org, draft-ietf-precis-7700bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149876614410.27838.18091001653680250992@ietfa.amsl.com> Date: Thu, 29 Jun 2017 12:55:44 -0700 Archived-At: Subject: [precis] Genart telechat review of draft-ietf-precis-7700bis-08 X-BeenThere: precis@ietf.org X-Mailman-Version: 2.1.22 List-Id: Preparation and Comparison of Internationalized Strings List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 19:55:44 -0000 Reviewer: Russ Housley 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-precis-7700bis-08 Reviewer: Russ Housley Review Date: 2017-06-29 IETF LC End Date: 2017-06-13 IESG Telechat date: 2017-07-06 Summary: Ready Major Concerns: None Minor Concerns: None Nits: None Thanks for addressing the concern that was raised in my earlier review.