From nobody Sun Feb 8 16:26:21 2015 Return-Path: X-Original-To: sandbox-mailoutput@ietfa.amsl.com Delivered-To: sandbox-mailoutput@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16541A6F96 for ; Sun, 8 Feb 2015 16:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.856 X-Spam-Level: ** X-Spam-Status: No, score=2.856 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_FAIL=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.001] autolearn=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 4JvtnKkfWXiG for ; Sun, 8 Feb 2015 16:26:18 -0800 (PST) Received: from mail.ietf.org (unknown [162.242.242.195]) by ietfa.amsl.com (Postfix) with ESMTP id 77E5B1A1B7F for ; Sun, 8 Feb 2015 16:26:18 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by sandbox.ietf.org (Postfix) with ESMTP id 5D854C2824 for ; Sun, 8 Feb 2015 19:22:40 -0500 (EST) Content-Type: multipart/mixed; boundary="===============4608776675763394938==" MIME-Version: 1.0 From: IETF Secretariat To: sandbox-mailoutput@ietf.org Message-ID: <20150209002239.9978.59467.idtracker@sandbox> Date: Sun, 08 Feb 2015 16:22:39 -0800 Archived-At: Subject: [Sandbox-mailoutput] [Django development] Confirm registration at datatracker.ietf.org X-BeenThere: sandbox-mailoutput@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 00:26:20 -0000 --===============4608776675763394938== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody. --===============4608776675763394938== Content-Type: message/rfc822 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: <9itaton@gmail.com> Subject: Confirm registration at datatracker.ietf.org X-Test-IDTracker: yes X-IETF-IDTracker: 5.10.3-dev0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209002239.9978.3549.idtracker@sandbox> Date: Sun, 08 Feb 2015 16:22:39 -0800 Hello, We have received an account creation request for 9itaton@gmail.com at datatracker.ietf.org. In order to set a new password for the 9itaton@gmail.com account, please go to the following link and follow the instructions there: https://datatracker.ietf.org/accounts/confirm/9itaton%40gmail.com/20150208/IETF/64bc66fed1c27e3219c46cc1276cb201/ This link will expire in 3 days. Best regards, The datatracker login manager service (for the IETF Secretariat) --===============4608776675763394938==-- From nobody Sun Feb 8 20:31:15 2015 Return-Path: X-Original-To: sandbox-mailoutput@ietfa.amsl.com Delivered-To: sandbox-mailoutput@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C401A0021 for ; Sun, 8 Feb 2015 20:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.667 X-Spam-Level: *** X-Spam-Status: No, score=3.667 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_FAIL=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=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 DIUVLM2UMKOR for ; Sun, 8 Feb 2015 20:31:09 -0800 (PST) Received: from mail.ietf.org (unknown [162.242.242.195]) by ietfa.amsl.com (Postfix) with ESMTP id 56DF71A0011 for ; Sun, 8 Feb 2015 20:31:09 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by sandbox.ietf.org (Postfix) with ESMTP id 51760C2824 for ; Sun, 8 Feb 2015 23:27:36 -0500 (EST) Content-Type: multipart/mixed; boundary="===============1098219234597803489==" MIME-Version: 1.0 From: IETF Secretariat To: sandbox-mailoutput@ietf.org Message-ID: <20150209042735.23347.33134.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:27:35 -0800 Archived-At: Subject: [Sandbox-mailoutput] [Django development] Evaluation: to Proposed Standard X-BeenThere: sandbox-mailoutput@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 04:31:12 -0000 --===============1098219234597803489== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody. --===============1098219234597803489== Content-Type: message/rfc822 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: IESG Secretary To: "Internet Engineering Steering Group" Subject: Evaluation: to Proposed Standard X-Test-IDTracker: yes X-IETF-IDTracker: 5.10.3-dev0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: IESG Secretary Message-ID: <20150209042735.23347.45733.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:27:35 -0800 Evaluation for can be found at http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ Last call to expire on: 2015-02-19 00:00 Please return the full line with your position. Yes No-Objection Discuss Abstain Adrian Farrel [ ] [ X ] [ ] [ ] Alissa Cooper [ ] [ X ] [ ] [ ] Barry Leiba [ X ] [ ] [ ] [ ] Benoit Claise [ ] [ X ] [ ] [ ] Brian Haberman [ ] [ X ] [ ] [ ] Jari Arkko [ ] [ X ] [ ] [ ] Joel Jaeggli [ ] [ X ] [ ] [ ] Kathleen Moriarty [ ] [ X ] [ ] [ ] Martin Stiemerling [ ] [ X ] [ ] [ ] Pete Resnick [ X ] [ ] [ ] [ ] Richard Barnes [ ] [ X ] [ ] [ ] Spencer Dawkins [ ] [ X ] [ ] [ ] Stephen Farrell [ ] [ X ] [ ] [ ] Ted Lemon [ ] [ X ] [ ] [ ] Has enough positions to pass. DISCUSSES AND COMMENTS ====================== Adrian Farrel: Comment [2014-04-22]: Not my area of expertise, but ... :-) Why isn't BCP18 an important reference? Alissa Cooper: Comment [2014-04-21]: Nice work. I have one comment in Section 4.3, which says: One consequence of disallowing space characters in the IdentifierClass might be to effectively discourage the use of ASCII space (or, even more problematically, non-ASCII space characters) within identifiers created in newer application protocols; given the challenges involved in properly handling space characters in identifiers and other protocol strings, the Working Group considered this to be a feature, not a bug. I find the use of the phrase “even more problematically” confusing given that it comes after “to effectively discourage.” I think the intended meaning here is that if non-ASCII space characters were to be used (or _encouraged_), that would be even more problematic than if ASCII space characters were to be used (or encouraged), right? I would suggest the following edit to the first part of the first sentence: One consequence of disallowing space characters in the IdentifierClass might be to effectively discourage the use of ASCII space (or the even more problematic non-ASCII space characters) within identifiers created in newer application protocols; Barry Leiba: Comment [2014-04-24]: After discussion, I'm moving this to a non-blocking comment. I still think that the working group and the responsible AD did not handle this right, and strongly urge not repeating this mechanism in future. The registry created in Section 9.1 is very odd indeed. I guess IANA is expected to assume that the format of the registry will look like the non-normative table in the appendix, but Section 9.1 doesn't say what the format of the registry will be. In the IANA review, it's clear that they're not sure what's going to happen here. But the real oddity here is that the specification of the registry involves an *enormous* startup cost for the designated expert, *and* requires that the DE be appointed and start her work immediately. Normally, IANA takes the required actions as soon as the document's approval is announced, but in this case they will have to wait for the DE to be appointed and to derive the entire content of the registry. It seems to me that the right way to have handled this would have been for the working group to have engaged the appropriate experts and made the table Appendix A *be* the initial contents of the registry, rather than explicitly denouncing Appendix A and leaving it as a seemingly quite onerous startup task that will delay the IANA actions indefinitely. Why was it done this way, and what is the plan to get the registry content specified in a reasonable time? Should approval of the document wait for that content to be specified? Or are we really expecting to approve the document with the content of the registry left open? UPDATE AFTER DISCUSSION: The response to my final questions says that IDNAbis did it this way, the intent is to use the same expert as for that registry, and it's not expected to be terribly burdensome. It's good to hear that it won't be burdensome, but it still seems that the working group produced an incomplete document. The right way to have handled this would have been to involve the appropriate experts near the end of the working group's process, and to get the table in Appendix A to be the initial registration data, already vetted by the expert. That way, the instructions to IANA would be clear, and the IETF and the IESG would be reviewing the complete picture. When the document is approved and IANA creates the registry, they will contact the authors to confirm that it's all correct, at which point the authors would ask the expert to check it again. It's unlikely that there'd be any changes needed in the roughly four weeks between IETF last call and document approval, and given that the expert you intend to recruit is also our liaison to the Unicode Consortium, he could confirm that they are not working on any updates just now. As it stands, what the working group seems to be saying is that they don't have the expertise to get this right, and can't get the right experts involved... which, in any other context, we would push back on very hard, indeed. Benoit Claise: Comment [2014-04-24]: - More of a series of question than a COMMENT. Disclaimer: the PRECIS work is very far from my comfort zone, so there might be a little bit of eduction involved here. You have identified IdentifierClass and FreeformClass. As OPS AD, I'm wondering whether future OPS data models should take these classes into account. Let me explain. We have: SMI Textual Convention (RFC 2579). For example: SnmpAdminString YANG typedef (https://tools.ietf.org/html/rfc6020#section-7.3) IPFIX data types (RFC 7011) AAA Should we ideally start specifying our data model strings according to these classes, to facilitate strings comparison operations? Should we start defining new SMI TC, YANG typedef, or IPFIX data types? Is there some education required in OPS? I guess that there is no action for the authors at this point, and the next step is an informal discussion with Pete. - https://datatracker.ietf.org/doc/draft-ietf-precis-framework/shepherdwriteup/ There is a normative downref to draft-ietf-precis-mappings (an Informative document). I see that draft-ietf-precis-mappings in the informative references. Kathleen Moriarty: Comment [2014-04-22]: Thanks for addressing the SecDir comments so quickly! Pete Resnick: Comment [2014-04-18]: The following are all items I mentioned in my AD Eval, but we decided none was a show-stopper and all could be held until the end of Last Call. The only substantive point is on 4.1.5, and the world will not end if I end up in the rough on this point. (We don't expect a whole lot of feedback during Last Call; the document got a good deal of review by a lot of experts, but the topic is pretty esoteric for anyone else to have much of a strong opinion.) Throughout: Change "Informational Note:" to "Note:". I don't see any of them for which it makes a difference. 3.1: I would move the first paragraph down further in the section. And I would delete the parenthetical at the end of "Contextual Rule Required"; no need to introduce undefined terms here. 3.2.4 and 3.3.4: The SHALLs in here seem weird to me. Above, you don't say that a string with a Disallowed character "SHALL be rejected". If it were me, I'd simply say: Any code points that are not yet designated in the Unicode character set are considered Unassigned for purposes of the XXXClass, and such code points are to be treated as Disallowed. 4.1: Change "MUST register" to "are registered". MUSTs for registration seem silly. (If you want to say, "Implementations MUST NOT use unregistered classes", you could, but I don't think you want to do that.) Change "It is RECOMMENDED for profile names to be of the form" to "The naming convention for profile names is to use the form". 4.1.5: I'm not thrilled with this section in general, but in particular I'm not sure what "mixed-direction strings are not supported" means. We do know how to process strings that contain characters with a mix of directionality. Such strings are sometimes a visual challenge, but not a processing challenge: The RFC 5893 Bidi Rule exists because IDNs want to be visually stable in either an LTR or RTL context, and because IDNs use "." as a label separator yet want to have text display consistent in a context that is unaware of labels. There are perfectly reasonable cases where none of these hold true, so I think this section could be softened so that it's not overtly pushing that protocols never allow mixed direction text or that they should always lean toward using RFC 5893. 4.2: A bit of ABNF neatening: OLD fullname = namepart [1*(1*SP namepart)] namepart = 1*(idpoint) NEW fullname = namepart *(1*SP namepart) namepart = 1*idpoint 9.2: It might be nice to add section numbers (3.2 and 3.3) to the registrations for IdentifierClass and FreeformClass. 9.3: It might be nice to note the naming convention from 4.1 in the template. Stephen Farrell: Comment [2014-04-24]: - I agree with Bary's discuss - it seems weird to not have the initial registries in hand when the RFC is being issued. People will, I guess, implement from Appendix A here anyway, so why not either delete this and get the registry in place, or else make Appendix A be the initial registry content. 7.7: This uses the empty set, which is puzzling. I think you mean that this set is to be populated by the DE in the IANA registries but if so, saying so would be good. 10.5: This says that a) its all too hard but also b) "Nevertheless, specifications for application protocols that use this framework MUST describe how confusable characters can be abused to compromise the security of systems that use the protocol in question, along with any protocol-specific suggestions for overcoming those threats." That seems like a 6919 MUST (but we know you won't) to me. Is that a good plan? 10.6: Prompted by the secdir review, it might be worth a few words on password hashing, which is very common. E.g. say that the canonical form is input to hashing and therefore just can't be mucked about with. (But say that nicely:-) Ted Lemon: Comment [2014-04-23]: In section 6, last paragraph, the reference to [UNICODE] would be more helpful if it said (see Chapter 4 of [UNICODE]), similar to later references in section 7. Aside from that, this is an excellent attempt to provide a basis for unraveling the gordian knot of unicode use in standards, and I look forward to seeing how it works in practice. ---- following is a DRAFT of message to be sent AFTER approval --- From: The IESG To: IETF-Announce Cc: RFC Editor , precis mailing list , precis chair Subject: Protocol Action: 'PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols' to Proposed Standard (draft-ietf-precis-framework-15.txt) The IESG has approved the following document: - 'PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols' (draft-ietf-precis-framework-15.txt) as Proposed Standard This document is the product of the Preparation and Comparison of Internationalized Strings Working Group. The IESG contact persons are Pete Resnick and Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ Technical Summary Application protocols using Unicode characters in protocol strings need to properly prepare such strings in order 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 and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. Working Group Summary The WG spent some time deciding how many classes need to be defined and what kind of class is suitable for "profiling" for different purposes. In particular the discussion of use of spaces in Identifier class took a bit of time. But the WG converged at the end. Document Quality The approach used by the document is similar to IDNA 2008 approach (use of Unicode character properties for deciding what to do with characters) and thus wasn't controversial. Several protocols intend to use the framework described in this document, and people from different working groups have been contributing to this work, including folks involved in iSCSI and RADIUS. Personnel The document shepherd is Alexey Melnikov. The responsible Area Director is Pete Resnick. --===============1098219234597803489==-- From nobody Sun Feb 8 20:32:42 2015 Return-Path: X-Original-To: sandbox-mailoutput@ietfa.amsl.com Delivered-To: sandbox-mailoutput@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BAA1A0011 for ; Sun, 8 Feb 2015 20:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.667 X-Spam-Level: *** X-Spam-Status: No, score=3.667 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_FAIL=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=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 SpFFjbzRKt7b for ; Sun, 8 Feb 2015 20:31:10 -0800 (PST) Received: from mail.ietf.org (unknown [162.242.242.195]) by ietfa.amsl.com (Postfix) with ESMTP id 040AA1A001B for ; Sun, 8 Feb 2015 20:31:10 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by sandbox.ietf.org (Postfix) with ESMTP id 5E48CC29A0 for ; Sun, 8 Feb 2015 23:27:36 -0500 (EST) Content-Type: multipart/mixed; boundary="===============5328819130093185018==" MIME-Version: 1.0 From: IETF Secretariat To: sandbox-mailoutput@ietf.org Message-ID: <20150209042736.23347.75140.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:27:36 -0800 Archived-At: Subject: [Sandbox-mailoutput] [Django development] Evaluation: to Proposed Standard X-BeenThere: sandbox-mailoutput@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 04:31:13 -0000 --===============5328819130093185018== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody. --===============5328819130093185018== Content-Type: message/rfc822 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IANA" Subject: Evaluation: to Proposed Standard X-Test-IDTracker: yes X-IETF-IDTracker: 5.10.3-dev0 Auto-Submitted: auto-generated Precedence: bulk X-IETF-Draft-string: draft-ietf-precis-framework X-IETF-Draft-revision: 22 Message-ID: <20150209042736.23347.61493.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:27:36 -0800 Evaluation for can be found at http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ Last call to expire on: 2015-02-19 00:00 Please return the full line with your position. Yes No-Objection Discuss Abstain Adrian Farrel [ ] [ X ] [ ] [ ] Alissa Cooper [ ] [ X ] [ ] [ ] Barry Leiba [ X ] [ ] [ ] [ ] Benoit Claise [ ] [ X ] [ ] [ ] Brian Haberman [ ] [ X ] [ ] [ ] Jari Arkko [ ] [ X ] [ ] [ ] Joel Jaeggli [ ] [ X ] [ ] [ ] Kathleen Moriarty [ ] [ X ] [ ] [ ] Martin Stiemerling [ ] [ X ] [ ] [ ] Pete Resnick [ X ] [ ] [ ] [ ] Richard Barnes [ ] [ X ] [ ] [ ] Spencer Dawkins [ ] [ X ] [ ] [ ] Stephen Farrell [ ] [ X ] [ ] [ ] Ted Lemon [ ] [ X ] [ ] [ ] Has enough positions to pass. DISCUSSES AND COMMENTS ====================== Adrian Farrel: Comment [2014-04-22]: Not my area of expertise, but ... :-) Why isn't BCP18 an important reference? Alissa Cooper: Comment [2014-04-21]: Nice work. I have one comment in Section 4.3, which says: One consequence of disallowing space characters in the IdentifierClass might be to effectively discourage the use of ASCII space (or, even more problematically, non-ASCII space characters) within identifiers created in newer application protocols; given the challenges involved in properly handling space characters in identifiers and other protocol strings, the Working Group considered this to be a feature, not a bug. I find the use of the phrase “even more problematically” confusing given that it comes after “to effectively discourage.” I think the intended meaning here is that if non-ASCII space characters were to be used (or _encouraged_), that would be even more problematic than if ASCII space characters were to be used (or encouraged), right? I would suggest the following edit to the first part of the first sentence: One consequence of disallowing space characters in the IdentifierClass might be to effectively discourage the use of ASCII space (or the even more problematic non-ASCII space characters) within identifiers created in newer application protocols; Barry Leiba: Comment [2014-04-24]: After discussion, I'm moving this to a non-blocking comment. I still think that the working group and the responsible AD did not handle this right, and strongly urge not repeating this mechanism in future. The registry created in Section 9.1 is very odd indeed. I guess IANA is expected to assume that the format of the registry will look like the non-normative table in the appendix, but Section 9.1 doesn't say what the format of the registry will be. In the IANA review, it's clear that they're not sure what's going to happen here. But the real oddity here is that the specification of the registry involves an *enormous* startup cost for the designated expert, *and* requires that the DE be appointed and start her work immediately. Normally, IANA takes the required actions as soon as the document's approval is announced, but in this case they will have to wait for the DE to be appointed and to derive the entire content of the registry. It seems to me that the right way to have handled this would have been for the working group to have engaged the appropriate experts and made the table Appendix A *be* the initial contents of the registry, rather than explicitly denouncing Appendix A and leaving it as a seemingly quite onerous startup task that will delay the IANA actions indefinitely. Why was it done this way, and what is the plan to get the registry content specified in a reasonable time? Should approval of the document wait for that content to be specified? Or are we really expecting to approve the document with the content of the registry left open? UPDATE AFTER DISCUSSION: The response to my final questions says that IDNAbis did it this way, the intent is to use the same expert as for that registry, and it's not expected to be terribly burdensome. It's good to hear that it won't be burdensome, but it still seems that the working group produced an incomplete document. The right way to have handled this would have been to involve the appropriate experts near the end of the working group's process, and to get the table in Appendix A to be the initial registration data, already vetted by the expert. That way, the instructions to IANA would be clear, and the IETF and the IESG would be reviewing the complete picture. When the document is approved and IANA creates the registry, they will contact the authors to confirm that it's all correct, at which point the authors would ask the expert to check it again. It's unlikely that there'd be any changes needed in the roughly four weeks between IETF last call and document approval, and given that the expert you intend to recruit is also our liaison to the Unicode Consortium, he could confirm that they are not working on any updates just now. As it stands, what the working group seems to be saying is that they don't have the expertise to get this right, and can't get the right experts involved... which, in any other context, we would push back on very hard, indeed. Benoit Claise: Comment [2014-04-24]: - More of a series of question than a COMMENT. Disclaimer: the PRECIS work is very far from my comfort zone, so there might be a little bit of eduction involved here. You have identified IdentifierClass and FreeformClass. As OPS AD, I'm wondering whether future OPS data models should take these classes into account. Let me explain. We have: SMI Textual Convention (RFC 2579). For example: SnmpAdminString YANG typedef (https://tools.ietf.org/html/rfc6020#section-7.3) IPFIX data types (RFC 7011) AAA Should we ideally start specifying our data model strings according to these classes, to facilitate strings comparison operations? Should we start defining new SMI TC, YANG typedef, or IPFIX data types? Is there some education required in OPS? I guess that there is no action for the authors at this point, and the next step is an informal discussion with Pete. - https://datatracker.ietf.org/doc/draft-ietf-precis-framework/shepherdwriteup/ There is a normative downref to draft-ietf-precis-mappings (an Informative document). I see that draft-ietf-precis-mappings in the informative references. Kathleen Moriarty: Comment [2014-04-22]: Thanks for addressing the SecDir comments so quickly! Pete Resnick: Comment [2014-04-18]: The following are all items I mentioned in my AD Eval, but we decided none was a show-stopper and all could be held until the end of Last Call. The only substantive point is on 4.1.5, and the world will not end if I end up in the rough on this point. (We don't expect a whole lot of feedback during Last Call; the document got a good deal of review by a lot of experts, but the topic is pretty esoteric for anyone else to have much of a strong opinion.) Throughout: Change "Informational Note:" to "Note:". I don't see any of them for which it makes a difference. 3.1: I would move the first paragraph down further in the section. And I would delete the parenthetical at the end of "Contextual Rule Required"; no need to introduce undefined terms here. 3.2.4 and 3.3.4: The SHALLs in here seem weird to me. Above, you don't say that a string with a Disallowed character "SHALL be rejected". If it were me, I'd simply say: Any code points that are not yet designated in the Unicode character set are considered Unassigned for purposes of the XXXClass, and such code points are to be treated as Disallowed. 4.1: Change "MUST register" to "are registered". MUSTs for registration seem silly. (If you want to say, "Implementations MUST NOT use unregistered classes", you could, but I don't think you want to do that.) Change "It is RECOMMENDED for profile names to be of the form" to "The naming convention for profile names is to use the form". 4.1.5: I'm not thrilled with this section in general, but in particular I'm not sure what "mixed-direction strings are not supported" means. We do know how to process strings that contain characters with a mix of directionality. Such strings are sometimes a visual challenge, but not a processing challenge: The RFC 5893 Bidi Rule exists because IDNs want to be visually stable in either an LTR or RTL context, and because IDNs use "." as a label separator yet want to have text display consistent in a context that is unaware of labels. There are perfectly reasonable cases where none of these hold true, so I think this section could be softened so that it's not overtly pushing that protocols never allow mixed direction text or that they should always lean toward using RFC 5893. 4.2: A bit of ABNF neatening: OLD fullname = namepart [1*(1*SP namepart)] namepart = 1*(idpoint) NEW fullname = namepart *(1*SP namepart) namepart = 1*idpoint 9.2: It might be nice to add section numbers (3.2 and 3.3) to the registrations for IdentifierClass and FreeformClass. 9.3: It might be nice to note the naming convention from 4.1 in the template. Stephen Farrell: Comment [2014-04-24]: - I agree with Bary's discuss - it seems weird to not have the initial registries in hand when the RFC is being issued. People will, I guess, implement from Appendix A here anyway, so why not either delete this and get the registry in place, or else make Appendix A be the initial registry content. 7.7: This uses the empty set, which is puzzling. I think you mean that this set is to be populated by the DE in the IANA registries but if so, saying so would be good. 10.5: This says that a) its all too hard but also b) "Nevertheless, specifications for application protocols that use this framework MUST describe how confusable characters can be abused to compromise the security of systems that use the protocol in question, along with any protocol-specific suggestions for overcoming those threats." That seems like a 6919 MUST (but we know you won't) to me. Is that a good plan? 10.6: Prompted by the secdir review, it might be worth a few words on password hashing, which is very common. E.g. say that the canonical form is input to hashing and therefore just can't be mucked about with. (But say that nicely:-) Ted Lemon: Comment [2014-04-23]: In section 6, last paragraph, the reference to [UNICODE] would be more helpful if it said (see Chapter 4 of [UNICODE]), similar to later references in section 7. Aside from that, this is an excellent attempt to provide a basis for unraveling the gordian knot of unicode use in standards, and I look forward to seeing how it works in practice. ---- following is a DRAFT of message to be sent AFTER approval --- From: The IESG To: IETF-Announce Cc: RFC Editor , precis mailing list , precis chair Subject: Protocol Action: 'PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols' to Proposed Standard (draft-ietf-precis-framework-15.txt) The IESG has approved the following document: - 'PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols' (draft-ietf-precis-framework-15.txt) as Proposed Standard This document is the product of the Preparation and Comparison of Internationalized Strings Working Group. The IESG contact persons are Pete Resnick and Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ Technical Summary Application protocols using Unicode characters in protocol strings need to properly prepare such strings in order 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 and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. Working Group Summary The WG spent some time deciding how many classes need to be defined and what kind of class is suitable for "profiling" for different purposes. In particular the discussion of use of spaces in Identifier class took a bit of time. But the WG converged at the end. Document Quality The approach used by the document is similar to IDNA 2008 approach (use of Unicode character properties for deciding what to do with characters) and thus wasn't controversial. Several protocols intend to use the framework described in this document, and people from different working groups have been contributing to this work, including folks involved in iSCSI and RADIUS. Personnel The document shepherd is Alexey Melnikov. The responsible Area Director is Pete Resnick. --===============5328819130093185018==-- From nobody Sun Feb 8 20:34:11 2015 Return-Path: X-Original-To: sandbox-mailoutput@ietfa.amsl.com Delivered-To: sandbox-mailoutput@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481861A0011 for ; Sun, 8 Feb 2015 20:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.855 X-Spam-Level: ** X-Spam-Status: No, score=2.855 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_FAIL=0.001] autolearn=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 fMVwMzKhk7kM for ; Sun, 8 Feb 2015 20:31:12 -0800 (PST) Received: from mail.ietf.org (unknown [162.242.242.195]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4171A001C for ; Sun, 8 Feb 2015 20:31:10 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by sandbox.ietf.org (Postfix) with ESMTP id 6F1F8C29A1 for ; Sun, 8 Feb 2015 23:27:36 -0500 (EST) Content-Type: multipart/mixed; boundary="===============8890767635962609878==" MIME-Version: 1.0 From: IETF Secretariat To: sandbox-mailoutput@ietf.org Message-ID: <20150209042736.23347.89859.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:27:36 -0800 Archived-At: Subject: [Sandbox-mailoutput] [Django development] Personal ID list of bortzmeyer+ietf@nic.fr notification: Changes on draft-ietf-precis-framework X-BeenThere: sandbox-mailoutput@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 04:31:13 -0000 --===============8890767635962609878== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody. --===============8890767635962609878== Content-Type: message/rfc822 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Subject: Personal ID list of bortzmeyer+ietf@nic.fr notification: Changes on draft-ietf-precis-framework X-Test-IDTracker: yes X-IETF-IDTracker: 5.10.3-dev0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209042736.23347.6125.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:27:36 -0800 Hello, This is a notification from the Personal ID list of bortzmeyer+ietf@nic.fr. Document: draft-ietf-precis-framework, https://datatracker.ietf.org/doc/draft-ietf-precis-framework Change: Ballot has been issued Best regards, The datatracker draft tracking service (for the IETF Secretariat) --===============8890767635962609878==-- From nobody Sun Feb 8 20:42:01 2015 Return-Path: X-Original-To: sandbox-mailoutput@ietfa.amsl.com Delivered-To: sandbox-mailoutput@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F6D1A0029 for ; Sun, 8 Feb 2015 20:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.356 X-Spam-Level: ** X-Spam-Status: No, score=2.356 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_FAIL=0.001] autolearn=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 nuuQ6HvK2yIG for ; Sun, 8 Feb 2015 20:41:59 -0800 (PST) Received: from mail.ietf.org (unknown [IPv6:2001:4802:7802:102:be76:4eff:fe20:5a74]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC171A0015 for ; Sun, 8 Feb 2015 20:41:59 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by sandbox.ietf.org (Postfix) with ESMTP id E9DEEC2824 for ; Sun, 8 Feb 2015 23:38:25 -0500 (EST) Content-Type: multipart/mixed; boundary="===============5902556673678717926==" MIME-Version: 1.0 From: IETF Secretariat To: sandbox-mailoutput@ietf.org Message-ID: <20150209043824.23266.60774.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:38:24 -0800 Archived-At: Subject: [Sandbox-mailoutput] [Django development] Personal ID list of bortzmeyer+ietf@nic.fr notification: Changes on draft-ietf-precis-framework X-BeenThere: sandbox-mailoutput@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 04:42:00 -0000 --===============5902556673678717926== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody. --===============5902556673678717926== Content-Type: message/rfc822 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Subject: Personal ID list of bortzmeyer+ietf@nic.fr notification: Changes on draft-ietf-precis-framework X-Test-IDTracker: yes X-IETF-IDTracker: 5.10.3-dev0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209043824.23266.95602.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:38:24 -0800 Hello, This is a notification from the Personal ID list of bortzmeyer+ietf@nic.fr. Document: draft-ietf-precis-framework, https://datatracker.ietf.org/doc/draft-ietf-precis-framework Change: Ballot writeup was changed Best regards, The datatracker draft tracking service (for the IETF Secretariat) --===============5902556673678717926==-- From nobody Sun Feb 8 20:43:44 2015 Return-Path: X-Original-To: sandbox-mailoutput@ietfa.amsl.com Delivered-To: sandbox-mailoutput@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2765B1A0029 for ; Sun, 8 Feb 2015 20:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.356 X-Spam-Level: ** X-Spam-Status: No, score=2.356 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_FAIL=0.001] autolearn=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 2vH52IirbYgB for ; Sun, 8 Feb 2015 20:42:00 -0800 (PST) Received: from mail.ietf.org (unknown [162.242.242.195]) by ietfa.amsl.com (Postfix) with ESMTP id 04D0D1A0027 for ; Sun, 8 Feb 2015 20:42:00 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by sandbox.ietf.org (Postfix) with ESMTP id 2FDBFC29A2 for ; Sun, 8 Feb 2015 23:38:26 -0500 (EST) Content-Type: multipart/mixed; boundary="===============6477445393999599766==" MIME-Version: 1.0 From: IETF Secretariat To: sandbox-mailoutput@ietf.org Message-ID: <20150209043826.23266.91972.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:38:26 -0800 Archived-At: Subject: [Sandbox-mailoutput] [Django development] Personal ID list of bortzmeyer+ietf@nic.fr notification: Changes on draft-ietf-precis-framework X-BeenThere: sandbox-mailoutput@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 04:42:01 -0000 --===============6477445393999599766== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody. --===============6477445393999599766== Content-Type: message/rfc822 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Subject: Personal ID list of bortzmeyer+ietf@nic.fr notification: Changes on draft-ietf-precis-framework X-Test-IDTracker: yes X-IETF-IDTracker: 5.10.3-dev0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209043826.23266.58028.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:38:26 -0800 Hello, This is a notification from the Personal ID list of bortzmeyer+ietf@nic.fr. Document: draft-ietf-precis-framework, https://datatracker.ietf.org/doc/draft-ietf-precis-framework Change: Ballot has been issued Best regards, The datatracker draft tracking service (for the IETF Secretariat) --===============6477445393999599766==-- From nobody Sun Feb 8 20:45:14 2015 Return-Path: X-Original-To: sandbox-mailoutput@ietfa.amsl.com Delivered-To: sandbox-mailoutput@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B471A0027 for ; Sun, 8 Feb 2015 20:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.667 X-Spam-Level: *** X-Spam-Status: No, score=3.667 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_FAIL=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=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 ksuIADuvu32Y for ; Sun, 8 Feb 2015 20:41:59 -0800 (PST) Received: from mail.ietf.org (unknown [162.242.242.195]) by ietfa.amsl.com (Postfix) with ESMTP id 9827A1A0024 for ; Sun, 8 Feb 2015 20:41:59 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by sandbox.ietf.org (Postfix) with ESMTP id 1B098C29A0 for ; Sun, 8 Feb 2015 23:38:26 -0500 (EST) Content-Type: multipart/mixed; boundary="===============5571496934127545854==" MIME-Version: 1.0 From: IETF Secretariat To: sandbox-mailoutput@ietf.org Message-ID: <20150209043826.23266.29546.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:38:26 -0800 Archived-At: Subject: [Sandbox-mailoutput] [Django development] Evaluation: to Proposed Standard X-BeenThere: sandbox-mailoutput@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 04:42:02 -0000 --===============5571496934127545854== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody. --===============5571496934127545854== Content-Type: message/rfc822 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: IESG Secretary To: "Internet Engineering Steering Group" Subject: Evaluation: to Proposed Standard X-Test-IDTracker: yes X-IETF-IDTracker: 5.10.3-dev0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: IESG Secretary Message-ID: <20150209043826.23266.49429.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:38:26 -0800 Evaluation for can be found at http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ Last call to expire on: 2015-02-19 00:00 Please return the full line with your position. Yes No-Objection Discuss Abstain Adrian Farrel [ ] [ X ] [ ] [ ] Alissa Cooper [ ] [ X ] [ ] [ ] Barry Leiba [ X ] [ ] [ ] [ ] Benoit Claise [ ] [ X ] [ ] [ ] Brian Haberman [ ] [ X ] [ ] [ ] Jari Arkko [ ] [ X ] [ ] [ ] Joel Jaeggli [ ] [ X ] [ ] [ ] Kathleen Moriarty [ ] [ X ] [ ] [ ] Martin Stiemerling [ ] [ X ] [ ] [ ] Pete Resnick [ X ] [ ] [ ] [ ] Richard Barnes [ ] [ X ] [ ] [ ] Spencer Dawkins [ ] [ X ] [ ] [ ] Stephen Farrell [ ] [ X ] [ ] [ ] Ted Lemon [ ] [ X ] [ ] [ ] Has enough positions to pass. DISCUSSES AND COMMENTS ====================== Adrian Farrel: Comment [2014-04-22]: Not my area of expertise, but ... :-) Why isn't BCP18 an important reference? Alissa Cooper: Comment [2014-04-21]: Nice work. I have one comment in Section 4.3, which says: One consequence of disallowing space characters in the IdentifierClass might be to effectively discourage the use of ASCII space (or, even more problematically, non-ASCII space characters) within identifiers created in newer application protocols; given the challenges involved in properly handling space characters in identifiers and other protocol strings, the Working Group considered this to be a feature, not a bug. I find the use of the phrase “even more problematically” confusing given that it comes after “to effectively discourage.” I think the intended meaning here is that if non-ASCII space characters were to be used (or _encouraged_), that would be even more problematic than if ASCII space characters were to be used (or encouraged), right? I would suggest the following edit to the first part of the first sentence: One consequence of disallowing space characters in the IdentifierClass might be to effectively discourage the use of ASCII space (or the even more problematic non-ASCII space characters) within identifiers created in newer application protocols; Barry Leiba: Comment [2014-04-24]: After discussion, I'm moving this to a non-blocking comment. I still think that the working group and the responsible AD did not handle this right, and strongly urge not repeating this mechanism in future. The registry created in Section 9.1 is very odd indeed. I guess IANA is expected to assume that the format of the registry will look like the non-normative table in the appendix, but Section 9.1 doesn't say what the format of the registry will be. In the IANA review, it's clear that they're not sure what's going to happen here. But the real oddity here is that the specification of the registry involves an *enormous* startup cost for the designated expert, *and* requires that the DE be appointed and start her work immediately. Normally, IANA takes the required actions as soon as the document's approval is announced, but in this case they will have to wait for the DE to be appointed and to derive the entire content of the registry. It seems to me that the right way to have handled this would have been for the working group to have engaged the appropriate experts and made the table Appendix A *be* the initial contents of the registry, rather than explicitly denouncing Appendix A and leaving it as a seemingly quite onerous startup task that will delay the IANA actions indefinitely. Why was it done this way, and what is the plan to get the registry content specified in a reasonable time? Should approval of the document wait for that content to be specified? Or are we really expecting to approve the document with the content of the registry left open? UPDATE AFTER DISCUSSION: The response to my final questions says that IDNAbis did it this way, the intent is to use the same expert as for that registry, and it's not expected to be terribly burdensome. It's good to hear that it won't be burdensome, but it still seems that the working group produced an incomplete document. The right way to have handled this would have been to involve the appropriate experts near the end of the working group's process, and to get the table in Appendix A to be the initial registration data, already vetted by the expert. That way, the instructions to IANA would be clear, and the IETF and the IESG would be reviewing the complete picture. When the document is approved and IANA creates the registry, they will contact the authors to confirm that it's all correct, at which point the authors would ask the expert to check it again. It's unlikely that there'd be any changes needed in the roughly four weeks between IETF last call and document approval, and given that the expert you intend to recruit is also our liaison to the Unicode Consortium, he could confirm that they are not working on any updates just now. As it stands, what the working group seems to be saying is that they don't have the expertise to get this right, and can't get the right experts involved... which, in any other context, we would push back on very hard, indeed. Benoit Claise: Comment [2014-04-24]: - More of a series of question than a COMMENT. Disclaimer: the PRECIS work is very far from my comfort zone, so there might be a little bit of eduction involved here. You have identified IdentifierClass and FreeformClass. As OPS AD, I'm wondering whether future OPS data models should take these classes into account. Let me explain. We have: SMI Textual Convention (RFC 2579). For example: SnmpAdminString YANG typedef (https://tools.ietf.org/html/rfc6020#section-7.3) IPFIX data types (RFC 7011) AAA Should we ideally start specifying our data model strings according to these classes, to facilitate strings comparison operations? Should we start defining new SMI TC, YANG typedef, or IPFIX data types? Is there some education required in OPS? I guess that there is no action for the authors at this point, and the next step is an informal discussion with Pete. - https://datatracker.ietf.org/doc/draft-ietf-precis-framework/shepherdwriteup/ There is a normative downref to draft-ietf-precis-mappings (an Informative document). I see that draft-ietf-precis-mappings in the informative references. Kathleen Moriarty: Comment [2014-04-22]: Thanks for addressing the SecDir comments so quickly! Pete Resnick: Comment [2014-04-18]: The following are all items I mentioned in my AD Eval, but we decided none was a show-stopper and all could be held until the end of Last Call. The only substantive point is on 4.1.5, and the world will not end if I end up in the rough on this point. (We don't expect a whole lot of feedback during Last Call; the document got a good deal of review by a lot of experts, but the topic is pretty esoteric for anyone else to have much of a strong opinion.) Throughout: Change "Informational Note:" to "Note:". I don't see any of them for which it makes a difference. 3.1: I would move the first paragraph down further in the section. And I would delete the parenthetical at the end of "Contextual Rule Required"; no need to introduce undefined terms here. 3.2.4 and 3.3.4: The SHALLs in here seem weird to me. Above, you don't say that a string with a Disallowed character "SHALL be rejected". If it were me, I'd simply say: Any code points that are not yet designated in the Unicode character set are considered Unassigned for purposes of the XXXClass, and such code points are to be treated as Disallowed. 4.1: Change "MUST register" to "are registered". MUSTs for registration seem silly. (If you want to say, "Implementations MUST NOT use unregistered classes", you could, but I don't think you want to do that.) Change "It is RECOMMENDED for profile names to be of the form" to "The naming convention for profile names is to use the form". 4.1.5: I'm not thrilled with this section in general, but in particular I'm not sure what "mixed-direction strings are not supported" means. We do know how to process strings that contain characters with a mix of directionality. Such strings are sometimes a visual challenge, but not a processing challenge: The RFC 5893 Bidi Rule exists because IDNs want to be visually stable in either an LTR or RTL context, and because IDNs use "." as a label separator yet want to have text display consistent in a context that is unaware of labels. There are perfectly reasonable cases where none of these hold true, so I think this section could be softened so that it's not overtly pushing that protocols never allow mixed direction text or that they should always lean toward using RFC 5893. 4.2: A bit of ABNF neatening: OLD fullname = namepart [1*(1*SP namepart)] namepart = 1*(idpoint) NEW fullname = namepart *(1*SP namepart) namepart = 1*idpoint 9.2: It might be nice to add section numbers (3.2 and 3.3) to the registrations for IdentifierClass and FreeformClass. 9.3: It might be nice to note the naming convention from 4.1 in the template. Stephen Farrell: Comment [2014-04-24]: - I agree with Bary's discuss - it seems weird to not have the initial registries in hand when the RFC is being issued. People will, I guess, implement from Appendix A here anyway, so why not either delete this and get the registry in place, or else make Appendix A be the initial registry content. 7.7: This uses the empty set, which is puzzling. I think you mean that this set is to be populated by the DE in the IANA registries but if so, saying so would be good. 10.5: This says that a) its all too hard but also b) "Nevertheless, specifications for application protocols that use this framework MUST describe how confusable characters can be abused to compromise the security of systems that use the protocol in question, along with any protocol-specific suggestions for overcoming those threats." That seems like a 6919 MUST (but we know you won't) to me. Is that a good plan? 10.6: Prompted by the secdir review, it might be worth a few words on password hashing, which is very common. E.g. say that the canonical form is input to hashing and therefore just can't be mucked about with. (But say that nicely:-) Ted Lemon: Comment [2014-04-23]: In section 6, last paragraph, the reference to [UNICODE] would be more helpful if it said (see Chapter 4 of [UNICODE]), similar to later references in section 7. Aside from that, this is an excellent attempt to provide a basis for unraveling the gordian knot of unicode use in standards, and I look forward to seeing how it works in practice. ---- following is a DRAFT of message to be sent AFTER approval --- From: The IESG To: IETF-Announce Cc: RFC Editor , precis mailing list , precis chair Subject: Protocol Action: 'PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols' to Proposed Standard (draft-ietf-precis-framework-15.txt) The IESG has approved the following document: - 'PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols' (draft-ietf-precis-framework-15.txt) as Proposed Standard This document is the product of the Preparation and Comparison of Internationalized Strings Working Group. The IESG contact persons are Pete Resnick and Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ Technical Summary Testing Application protocols using Unicode characters in protocol strings need to properly prepare such strings in order 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 and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. Working Group Summary The WG spent some time deciding how many classes need to be defined and what kind of class is suitable for "profiling" for different purposes. In particular the discussion of use of spaces in Identifier class took a bit of time. But the WG converged at the end. Document Quality The approach used by the document is similar to IDNA 2008 approach (use of Unicode character properties for deciding what to do with characters) and thus wasn't controversial. Several protocols intend to use the framework described in this document, and people from different working groups have been contributing to this work, including folks involved in iSCSI and RADIUS. Personnel The document shepherd is Alexey Melnikov. The responsible Area Director is Pete Resnick. --===============5571496934127545854==-- From nobody Sun Feb 8 20:46:42 2015 Return-Path: X-Original-To: sandbox-mailoutput@ietfa.amsl.com Delivered-To: sandbox-mailoutput@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B030A1A0024 for ; Sun, 8 Feb 2015 20:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.667 X-Spam-Level: *** X-Spam-Status: No, score=3.667 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_FAIL=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=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 Db2sXSJyUEOs for ; Sun, 8 Feb 2015 20:42:01 -0800 (PST) Received: from mail.ietf.org (unknown [162.242.242.195]) by ietfa.amsl.com (Postfix) with ESMTP id 91EB11A0015 for ; Sun, 8 Feb 2015 20:42:00 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by sandbox.ietf.org (Postfix) with ESMTP id 1DD06C29A1 for ; Sun, 8 Feb 2015 23:38:26 -0500 (EST) Content-Type: multipart/mixed; boundary="===============1936772925445901083==" MIME-Version: 1.0 From: IETF Secretariat To: sandbox-mailoutput@ietf.org Message-ID: <20150209043826.23266.94474.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:38:26 -0800 Archived-At: Subject: [Sandbox-mailoutput] [Django development] Evaluation: to Proposed Standard X-BeenThere: sandbox-mailoutput@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 04:42:03 -0000 --===============1936772925445901083== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody. --===============1936772925445901083== Content-Type: message/rfc822 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IANA" Subject: Evaluation: to Proposed Standard X-Test-IDTracker: yes X-IETF-IDTracker: 5.10.3-dev0 Auto-Submitted: auto-generated Precedence: bulk X-IETF-Draft-string: draft-ietf-precis-framework X-IETF-Draft-revision: 22 Message-ID: <20150209043826.23266.69669.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:38:26 -0800 Evaluation for can be found at http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ Last call to expire on: 2015-02-19 00:00 Please return the full line with your position. Yes No-Objection Discuss Abstain Adrian Farrel [ ] [ X ] [ ] [ ] Alissa Cooper [ ] [ X ] [ ] [ ] Barry Leiba [ X ] [ ] [ ] [ ] Benoit Claise [ ] [ X ] [ ] [ ] Brian Haberman [ ] [ X ] [ ] [ ] Jari Arkko [ ] [ X ] [ ] [ ] Joel Jaeggli [ ] [ X ] [ ] [ ] Kathleen Moriarty [ ] [ X ] [ ] [ ] Martin Stiemerling [ ] [ X ] [ ] [ ] Pete Resnick [ X ] [ ] [ ] [ ] Richard Barnes [ ] [ X ] [ ] [ ] Spencer Dawkins [ ] [ X ] [ ] [ ] Stephen Farrell [ ] [ X ] [ ] [ ] Ted Lemon [ ] [ X ] [ ] [ ] Has enough positions to pass. DISCUSSES AND COMMENTS ====================== Adrian Farrel: Comment [2014-04-22]: Not my area of expertise, but ... :-) Why isn't BCP18 an important reference? Alissa Cooper: Comment [2014-04-21]: Nice work. I have one comment in Section 4.3, which says: One consequence of disallowing space characters in the IdentifierClass might be to effectively discourage the use of ASCII space (or, even more problematically, non-ASCII space characters) within identifiers created in newer application protocols; given the challenges involved in properly handling space characters in identifiers and other protocol strings, the Working Group considered this to be a feature, not a bug. I find the use of the phrase “even more problematically” confusing given that it comes after “to effectively discourage.” I think the intended meaning here is that if non-ASCII space characters were to be used (or _encouraged_), that would be even more problematic than if ASCII space characters were to be used (or encouraged), right? I would suggest the following edit to the first part of the first sentence: One consequence of disallowing space characters in the IdentifierClass might be to effectively discourage the use of ASCII space (or the even more problematic non-ASCII space characters) within identifiers created in newer application protocols; Barry Leiba: Comment [2014-04-24]: After discussion, I'm moving this to a non-blocking comment. I still think that the working group and the responsible AD did not handle this right, and strongly urge not repeating this mechanism in future. The registry created in Section 9.1 is very odd indeed. I guess IANA is expected to assume that the format of the registry will look like the non-normative table in the appendix, but Section 9.1 doesn't say what the format of the registry will be. In the IANA review, it's clear that they're not sure what's going to happen here. But the real oddity here is that the specification of the registry involves an *enormous* startup cost for the designated expert, *and* requires that the DE be appointed and start her work immediately. Normally, IANA takes the required actions as soon as the document's approval is announced, but in this case they will have to wait for the DE to be appointed and to derive the entire content of the registry. It seems to me that the right way to have handled this would have been for the working group to have engaged the appropriate experts and made the table Appendix A *be* the initial contents of the registry, rather than explicitly denouncing Appendix A and leaving it as a seemingly quite onerous startup task that will delay the IANA actions indefinitely. Why was it done this way, and what is the plan to get the registry content specified in a reasonable time? Should approval of the document wait for that content to be specified? Or are we really expecting to approve the document with the content of the registry left open? UPDATE AFTER DISCUSSION: The response to my final questions says that IDNAbis did it this way, the intent is to use the same expert as for that registry, and it's not expected to be terribly burdensome. It's good to hear that it won't be burdensome, but it still seems that the working group produced an incomplete document. The right way to have handled this would have been to involve the appropriate experts near the end of the working group's process, and to get the table in Appendix A to be the initial registration data, already vetted by the expert. That way, the instructions to IANA would be clear, and the IETF and the IESG would be reviewing the complete picture. When the document is approved and IANA creates the registry, they will contact the authors to confirm that it's all correct, at which point the authors would ask the expert to check it again. It's unlikely that there'd be any changes needed in the roughly four weeks between IETF last call and document approval, and given that the expert you intend to recruit is also our liaison to the Unicode Consortium, he could confirm that they are not working on any updates just now. As it stands, what the working group seems to be saying is that they don't have the expertise to get this right, and can't get the right experts involved... which, in any other context, we would push back on very hard, indeed. Benoit Claise: Comment [2014-04-24]: - More of a series of question than a COMMENT. Disclaimer: the PRECIS work is very far from my comfort zone, so there might be a little bit of eduction involved here. You have identified IdentifierClass and FreeformClass. As OPS AD, I'm wondering whether future OPS data models should take these classes into account. Let me explain. We have: SMI Textual Convention (RFC 2579). For example: SnmpAdminString YANG typedef (https://tools.ietf.org/html/rfc6020#section-7.3) IPFIX data types (RFC 7011) AAA Should we ideally start specifying our data model strings according to these classes, to facilitate strings comparison operations? Should we start defining new SMI TC, YANG typedef, or IPFIX data types? Is there some education required in OPS? I guess that there is no action for the authors at this point, and the next step is an informal discussion with Pete. - https://datatracker.ietf.org/doc/draft-ietf-precis-framework/shepherdwriteup/ There is a normative downref to draft-ietf-precis-mappings (an Informative document). I see that draft-ietf-precis-mappings in the informative references. Kathleen Moriarty: Comment [2014-04-22]: Thanks for addressing the SecDir comments so quickly! Pete Resnick: Comment [2014-04-18]: The following are all items I mentioned in my AD Eval, but we decided none was a show-stopper and all could be held until the end of Last Call. The only substantive point is on 4.1.5, and the world will not end if I end up in the rough on this point. (We don't expect a whole lot of feedback during Last Call; the document got a good deal of review by a lot of experts, but the topic is pretty esoteric for anyone else to have much of a strong opinion.) Throughout: Change "Informational Note:" to "Note:". I don't see any of them for which it makes a difference. 3.1: I would move the first paragraph down further in the section. And I would delete the parenthetical at the end of "Contextual Rule Required"; no need to introduce undefined terms here. 3.2.4 and 3.3.4: The SHALLs in here seem weird to me. Above, you don't say that a string with a Disallowed character "SHALL be rejected". If it were me, I'd simply say: Any code points that are not yet designated in the Unicode character set are considered Unassigned for purposes of the XXXClass, and such code points are to be treated as Disallowed. 4.1: Change "MUST register" to "are registered". MUSTs for registration seem silly. (If you want to say, "Implementations MUST NOT use unregistered classes", you could, but I don't think you want to do that.) Change "It is RECOMMENDED for profile names to be of the form" to "The naming convention for profile names is to use the form". 4.1.5: I'm not thrilled with this section in general, but in particular I'm not sure what "mixed-direction strings are not supported" means. We do know how to process strings that contain characters with a mix of directionality. Such strings are sometimes a visual challenge, but not a processing challenge: The RFC 5893 Bidi Rule exists because IDNs want to be visually stable in either an LTR or RTL context, and because IDNs use "." as a label separator yet want to have text display consistent in a context that is unaware of labels. There are perfectly reasonable cases where none of these hold true, so I think this section could be softened so that it's not overtly pushing that protocols never allow mixed direction text or that they should always lean toward using RFC 5893. 4.2: A bit of ABNF neatening: OLD fullname = namepart [1*(1*SP namepart)] namepart = 1*(idpoint) NEW fullname = namepart *(1*SP namepart) namepart = 1*idpoint 9.2: It might be nice to add section numbers (3.2 and 3.3) to the registrations for IdentifierClass and FreeformClass. 9.3: It might be nice to note the naming convention from 4.1 in the template. Stephen Farrell: Comment [2014-04-24]: - I agree with Bary's discuss - it seems weird to not have the initial registries in hand when the RFC is being issued. People will, I guess, implement from Appendix A here anyway, so why not either delete this and get the registry in place, or else make Appendix A be the initial registry content. 7.7: This uses the empty set, which is puzzling. I think you mean that this set is to be populated by the DE in the IANA registries but if so, saying so would be good. 10.5: This says that a) its all too hard but also b) "Nevertheless, specifications for application protocols that use this framework MUST describe how confusable characters can be abused to compromise the security of systems that use the protocol in question, along with any protocol-specific suggestions for overcoming those threats." That seems like a 6919 MUST (but we know you won't) to me. Is that a good plan? 10.6: Prompted by the secdir review, it might be worth a few words on password hashing, which is very common. E.g. say that the canonical form is input to hashing and therefore just can't be mucked about with. (But say that nicely:-) Ted Lemon: Comment [2014-04-23]: In section 6, last paragraph, the reference to [UNICODE] would be more helpful if it said (see Chapter 4 of [UNICODE]), similar to later references in section 7. Aside from that, this is an excellent attempt to provide a basis for unraveling the gordian knot of unicode use in standards, and I look forward to seeing how it works in practice. ---- following is a DRAFT of message to be sent AFTER approval --- From: The IESG To: IETF-Announce Cc: RFC Editor , precis mailing list , precis chair Subject: Protocol Action: 'PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols' to Proposed Standard (draft-ietf-precis-framework-15.txt) The IESG has approved the following document: - 'PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols' (draft-ietf-precis-framework-15.txt) as Proposed Standard This document is the product of the Preparation and Comparison of Internationalized Strings Working Group. The IESG contact persons are Pete Resnick and Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ Technical Summary Testing Application protocols using Unicode characters in protocol strings need to properly prepare such strings in order 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 and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. Working Group Summary The WG spent some time deciding how many classes need to be defined and what kind of class is suitable for "profiling" for different purposes. In particular the discussion of use of spaces in Identifier class took a bit of time. But the WG converged at the end. Document Quality The approach used by the document is similar to IDNA 2008 approach (use of Unicode character properties for deciding what to do with characters) and thus wasn't controversial. Several protocols intend to use the framework described in this document, and people from different working groups have been contributing to this work, including folks involved in iSCSI and RADIUS. Personnel The document shepherd is Alexey Melnikov. The responsible Area Director is Pete Resnick. --===============1936772925445901083==-- From nobody Sun Feb 8 20:48:02 2015 Return-Path: X-Original-To: sandbox-mailoutput@ietfa.amsl.com Delivered-To: sandbox-mailoutput@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FA91A0029 for ; Sun, 8 Feb 2015 20:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.856 X-Spam-Level: ** X-Spam-Status: No, score=2.856 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_FAIL=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.001] autolearn=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 rHuxnWQMMHmo for ; Sun, 8 Feb 2015 20:42:16 -0800 (PST) Received: from mail.ietf.org (unknown [IPv6:2001:4802:7802:102:be76:4eff:fe20:5a74]) by ietfa.amsl.com (Postfix) with ESMTP id ADF6A1A0027 for ; Sun, 8 Feb 2015 20:42:15 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by sandbox.ietf.org (Postfix) with ESMTP id B002DC29A0 for ; Sun, 8 Feb 2015 23:38:43 -0500 (EST) Content-Type: multipart/mixed; boundary="===============8784956378346623777==" MIME-Version: 1.0 From: IETF Secretariat To: sandbox-mailoutput@ietf.org Message-ID: <20150209043843.23065.64171.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:38:43 -0800 Archived-At: Subject: [Sandbox-mailoutput] [Django development] Telechat update notice: X-BeenThere: sandbox-mailoutput@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 04:42:17 -0000 --===============8784956378346623777== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody. --===============8784956378346623777== Content-Type: message/rfc822 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , Subject: Telechat update notice: X-Test-IDTracker: yes X-IETF-IDTracker: 5.10.3-dev0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209043843.23065.1234.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:38:43 -0800 From: IETF Secretariat Telechat date has been changed to 2015-02-19 from 2014-04-24 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ --===============8784956378346623777==-- From nobody Sun Feb 8 20:49:40 2015 Return-Path: X-Original-To: sandbox-mailoutput@ietfa.amsl.com Delivered-To: sandbox-mailoutput@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DB21A0024 for ; Sun, 8 Feb 2015 20:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.356 X-Spam-Level: ** X-Spam-Status: No, score=2.356 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_FAIL=0.001] autolearn=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 vJGdQ05v8wJ7 for ; Sun, 8 Feb 2015 20:42:15 -0800 (PST) Received: from mail.ietf.org (unknown [162.242.242.195]) by ietfa.amsl.com (Postfix) with ESMTP id 969A01A0015 for ; Sun, 8 Feb 2015 20:42:15 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by sandbox.ietf.org (Postfix) with ESMTP id 9CD87C2824 for ; Sun, 8 Feb 2015 23:38:43 -0500 (EST) Content-Type: multipart/mixed; boundary="===============0720726919151384258==" MIME-Version: 1.0 From: IETF Secretariat To: sandbox-mailoutput@ietf.org Message-ID: <20150209043843.23065.58787.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:38:43 -0800 Archived-At: Subject: [Sandbox-mailoutput] [Django development] Personal ID list of bortzmeyer+ietf@nic.fr notification: Changes on draft-ietf-precis-framework X-BeenThere: sandbox-mailoutput@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 04:42:20 -0000 --===============0720726919151384258== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody. --===============0720726919151384258== Content-Type: message/rfc822 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Subject: Personal ID list of bortzmeyer+ietf@nic.fr notification: Changes on draft-ietf-precis-framework X-Test-IDTracker: yes X-IETF-IDTracker: 5.10.3-dev0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209043843.23065.15164.idtracker@sandbox> Date: Sun, 08 Feb 2015 20:38:43 -0800 Hello, This is a notification from the Personal ID list of bortzmeyer+ietf@nic.fr. Document: draft-ietf-precis-framework, https://datatracker.ietf.org/doc/draft-ietf-precis-framework Change: Telechat date has been changed to *2015-02-19* from *2014-04-24* Best regards, The datatracker draft tracking service (for the IETF Secretariat) --===============0720726919151384258==-- From nobody Mon Feb 9 03:17:50 2015 Return-Path: X-Original-To: sandbox-mailoutput@ietfa.amsl.com Delivered-To: sandbox-mailoutput@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3961A0222 for ; Mon, 9 Feb 2015 03:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.856 X-Spam-Level: ** X-Spam-Status: No, score=2.856 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_FAIL=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.001] autolearn=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 8B9d8joAz1X5 for ; Mon, 9 Feb 2015 03:17:48 -0800 (PST) Received: from mail.ietf.org (unknown [162.242.242.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF241A0233 for ; Mon, 9 Feb 2015 03:17:48 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by sandbox.ietf.org (Postfix) with ESMTP id 95DE4C2824 for ; Mon, 9 Feb 2015 06:14:14 -0500 (EST) Content-Type: multipart/mixed; boundary="===============6171704627221883252==" MIME-Version: 1.0 From: IETF Secretariat To: sandbox-mailoutput@ietf.org Message-ID: <20150209111413.12973.50922.idtracker@sandbox> Date: Mon, 09 Feb 2015 03:14:13 -0800 Archived-At: Subject: [Sandbox-mailoutput] [Django development] Confirm registration at datatracker.ietf.org X-BeenThere: sandbox-mailoutput@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 11:17:49 -0000 --===============6171704627221883252== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody. --===============6171704627221883252== Content-Type: message/rfc822 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: <9itaton@gmail.com> Subject: Confirm registration at datatracker.ietf.org X-Test-IDTracker: yes X-IETF-IDTracker: 5.10.3-dev0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209111413.12973.51369.idtracker@sandbox> Date: Mon, 09 Feb 2015 03:14:13 -0800 Hello, We have received an account creation request for 9itaton@gmail.com at datatracker.ietf.org. In order to set a new password for the 9itaton@gmail.com account, please go to the following link and follow the instructions there: https://datatracker.ietf.org/accounts/confirm/9itaton%40gmail.com/20150209/IETF/5572ad429ae7a779b51553ba609159b1/ This link will expire in 3 days. Best regards, The datatracker login manager service (for the IETF Secretariat) --===============6171704627221883252==-- From nobody Mon Feb 9 03:19:21 2015 Return-Path: X-Original-To: sandbox-mailoutput@ietfa.amsl.com Delivered-To: sandbox-mailoutput@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F831A0252 for ; Mon, 9 Feb 2015 03:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.357 X-Spam-Level: ** X-Spam-Status: No, score=2.357 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_FAIL=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.001] autolearn=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 rX7Oi8yCUaBJ for ; Mon, 9 Feb 2015 03:18:25 -0800 (PST) Received: from mail.ietf.org (unknown [IPv6:2001:4802:7802:102:be76:4eff:fe20:5a74]) by ietfa.amsl.com (Postfix) with ESMTP id AAF3C1A0222 for ; Mon, 9 Feb 2015 03:18:25 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by sandbox.ietf.org (Postfix) with ESMTP id 18705C2824 for ; Mon, 9 Feb 2015 06:14:53 -0500 (EST) Content-Type: multipart/mixed; boundary="===============2671938057695990689==" MIME-Version: 1.0 From: IETF Secretariat To: sandbox-mailoutput@ietf.org Message-ID: <20150209111453.14006.69291.idtracker@sandbox> Date: Mon, 09 Feb 2015 03:14:53 -0800 Archived-At: Subject: [Sandbox-mailoutput] [Django development] Password reset at datatracker.ietf.org X-BeenThere: sandbox-mailoutput@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 11:18:27 -0000 --===============2671938057695990689== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody. --===============2671938057695990689== Content-Type: message/rfc822 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: <9itaton@gmail.com> Subject: Password reset at datatracker.ietf.org X-Test-IDTracker: yes X-IETF-IDTracker: 5.10.3-dev0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209111453.14006.73567.idtracker@sandbox> Date: Mon, 09 Feb 2015 03:14:53 -0800 Hello, We have received a password reset request for 9itaton@gmail.com at datatracker.ietf.org. In order to set a new password for the 9itaton@gmail.com account, please go to the following link and follow the instructions there: https://datatracker.ietf.org/accounts/reset/confirm/9itaton%40gmail.com/20150209/IETF/5572ad429ae7a779b51553ba609159b1/ This link will expire in 3 days. If you have not requested a password reset you can ignore this email, your credentials have been left untouched. Best regards, The datatracker login manager service (for the IETF Secretariat) --===============2671938057695990689==-- From nobody Mon Feb 9 03:28:44 2015 Return-Path: X-Original-To: sandbox-mailoutput@ietfa.amsl.com Delivered-To: sandbox-mailoutput@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554B71A02F1 for ; Mon, 9 Feb 2015 03:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.856 X-Spam-Level: ** X-Spam-Status: No, score=2.856 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_FAIL=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.001] autolearn=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 sX4ncE2DKFS9 for ; Mon, 9 Feb 2015 03:27:48 -0800 (PST) Received: from mail.ietf.org (unknown [IPv6:2001:4802:7802:102:be76:4eff:fe20:5a74]) by ietfa.amsl.com (Postfix) with ESMTP id 3173C1A02BE for ; Mon, 9 Feb 2015 03:27:48 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by sandbox.ietf.org (Postfix) with ESMTP id 9C12AC2824 for ; Mon, 9 Feb 2015 06:24:14 -0500 (EST) Content-Type: multipart/mixed; boundary="===============5008952908265998248==" MIME-Version: 1.0 From: IETF Secretariat To: sandbox-mailoutput@ietf.org Message-ID: <20150209112413.14006.12202.idtracker@sandbox> Date: Mon, 09 Feb 2015 03:24:13 -0800 Archived-At: Subject: [Sandbox-mailoutput] [Django development] Confirm registration at datatracker.ietf.org X-BeenThere: sandbox-mailoutput@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 11:27:49 -0000 --===============5008952908265998248== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody. --===============5008952908265998248== Content-Type: message/rfc822 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: <9itaton@gmail.com> Subject: Confirm registration at datatracker.ietf.org X-Test-IDTracker: yes X-IETF-IDTracker: 5.10.3-dev0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209112413.14006.85365.idtracker@sandbox> Date: Mon, 09 Feb 2015 03:24:13 -0800 Hello, We have received an account creation request for 9itaton@gmail.com at datatracker.ietf.org. In order to set a new password for the 9itaton@gmail.com account, please go to the following link and follow the instructions there: https://datatracker.ietf.org/accounts/confirm/9itaton%40gmail.com/20150209/IETF/5572ad429ae7a779b51553ba609159b1/ This link will expire in 3 days. Best regards, The datatracker login manager service (for the IETF Secretariat) --===============5008952908265998248==-- From nobody Mon Feb 9 03:30:10 2015 Return-Path: X-Original-To: sandbox-mailoutput@ietfa.amsl.com Delivered-To: sandbox-mailoutput@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E836D1A02BE for ; Mon, 9 Feb 2015 03:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.357 X-Spam-Level: ** X-Spam-Status: No, score=2.357 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_FAIL=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.001] autolearn=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 Xkuf9z_-A6eu for ; Mon, 9 Feb 2015 03:28:41 -0800 (PST) Received: from mail.ietf.org (unknown [IPv6:2001:4802:7802:102:be76:4eff:fe20:5a74]) by ietfa.amsl.com (Postfix) with ESMTP id BB1FC1A028A for ; Mon, 9 Feb 2015 03:28:41 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by sandbox.ietf.org (Postfix) with ESMTP id 52F9FC2824 for ; Mon, 9 Feb 2015 06:25:08 -0500 (EST) Content-Type: multipart/mixed; boundary="===============1418778868800880038==" MIME-Version: 1.0 From: IETF Secretariat To: sandbox-mailoutput@ietf.org Message-ID: <20150209112508.14006.39959.idtracker@sandbox> Date: Mon, 09 Feb 2015 03:25:08 -0800 Archived-At: Subject: [Sandbox-mailoutput] [Django development] Password reset at datatracker.ietf.org X-BeenThere: sandbox-mailoutput@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 11:28:43 -0000 --===============1418778868800880038== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message would have been sent, but the tracker is in development mode. It was not sent to anybody. --===============1418778868800880038== Content-Type: message/rfc822 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: <9itaton@gmail.com> Subject: Password reset at datatracker.ietf.org X-Test-IDTracker: yes X-IETF-IDTracker: 5.10.3-dev0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209112508.14006.77666.idtracker@sandbox> Date: Mon, 09 Feb 2015 03:25:08 -0800 Hello, We have received a password reset request for 9itaton@gmail.com at datatracker.ietf.org. In order to set a new password for the 9itaton@gmail.com account, please go to the following link and follow the instructions there: https://datatracker.ietf.org/accounts/reset/confirm/9itaton%40gmail.com/20150209/IETF/5572ad429ae7a779b51553ba609159b1/ This link will expire in 3 days. If you have not requested a password reset you can ignore this email, your credentials have been left untouched. Best regards, The datatracker login manager service (for the IETF Secretariat) --===============1418778868800880038==--