From nobody Fri Sep 1 04:08:21 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F791132192 for ; Fri, 1 Sep 2017 04:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 hGLdsddCQ8rP for ; Fri, 1 Sep 2017 04:08:14 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDA6132969 for ; Fri, 1 Sep 2017 04:08:13 -0700 (PDT) Received: from localhost ([::1]:44290 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dnjo4-0007zN-BC; Fri, 01 Sep 2017 04:08:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org, rse@rfc-editor.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com, julian.reschke@gmx.de X-Trac-Project: xml2rfc Date: Fri, 01 Sep 2017 11:08:12 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/333#comment:2 Message-ID: <078.e5b4d403debb200de67b96c1fe1e588a@tools.ietf.org> References: <063.3bc135fe7315d5ddf61341c0a06a472a@tools.ietf.org> X-Trac-Ticket-ID: 333 In-Reply-To: <063.3bc135fe7315d5ddf61341c0a06a472a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, julian.reschke@gmx.de, rse@rfc-editor.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] #333 (Version 2 cli): change to 'https' URLs in boilerplate text X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 11:08:21 -0000 #333: change to 'https' URLs in boilerplate text Changes (by henrik@levkowetz.com): * status: new => closed * resolution: => fixed Comment: Fixed in [2375]: Changed the use of http: to https: in many places. In the generation of RFCs, the code uses a switchover date of August 21, 2017 when deciding whether to insert http: or https: URLs. In practice, this means that RFCs with a date of September 2017 or later will get https:. Also fixed URL line-breaking prevention to apply to https: URLS. Fixes issue #333. -- ------------------------------+---------------------------------- Reporter: arusso@amsl.com | Owner: henrik@levkowetz.com Type: task | Status: closed Priority: medium | Milestone: Component: Version 2 cli | Version: 2.4.x Resolution: fixed | Keywords: ------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Fri Sep 1 04:30:26 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2103113305B for ; Fri, 1 Sep 2017 04:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 EKh2zBivPpCR for ; Fri, 1 Sep 2017 04:30:23 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 610E5133052 for ; Fri, 1 Sep 2017 04:30:23 -0700 (PDT) Received: from localhost ([::1]:45124 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dnk9W-0006eC-FO; Fri, 01 Sep 2017 04:30:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org, arusso@amsl.com, sginoza@amsl.com Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com X-Trac-Project: xml2rfc Date: Fri, 01 Sep 2017 11:30:22 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/334#comment:1 Message-ID: <084.ed2676f1a0eb26497736345950d66eb4@tools.ietf.org> References: <069.068a05f78621b72bbf25d01040986e3e@tools.ietf.org> X-Trac-Ticket-ID: 334 In-Reply-To: <069.068a05f78621b72bbf25d01040986e3e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, arusso@amsl.com, sginoza@amsl.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] #334 (Version 2 cli txt): Non-contiguous URL numbers in text format X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 11:30:25 -0000 #334: Non-contiguous URL numbers in text format Changes (by henrik@levkowetz.com): * cc: arusso@amsl.com, sginoza@amsl.com (added) Comment: I see 2 possible resolutions of this ticket: 1. Fix the bracketed numbers for entries in the URIs section to be contigous, with only the 2 entries marked [1] and [3] above shown, or 2. Add an entry for link2 to the URIs section, with a bracketed reference [2] to it in the text. I propose to resolve this as in 2. Thoughts? -- ------------------------------------+---------------------------------- Reporter: jyasskin@chromium.org | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: medium | Milestone: Component: Version 2 cli txt | Version: Resolution: | Keywords: ------------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Fri Sep 1 04:33:53 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A339132F18 for ; Fri, 1 Sep 2017 04:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 zgdLWrl_JlZA for ; Fri, 1 Sep 2017 04:33:49 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CCB133070 for ; Fri, 1 Sep 2017 04:33:49 -0700 (PDT) Received: from localhost ([::1]:45624 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dnkCp-0000Ig-SR; Fri, 01 Sep 2017 04:33:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org, arusso@amsl.com, sginoza@amsl.com Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com X-Trac-Project: xml2rfc Date: Fri, 01 Sep 2017 11:33:47 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/334#comment:2 Message-ID: <084.a7a8ff0a1aba491069b32438293f22d5@tools.ietf.org> References: <069.068a05f78621b72bbf25d01040986e3e@tools.ietf.org> X-Trac-Ticket-ID: 334 In-Reply-To: <069.068a05f78621b72bbf25d01040986e3e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, arusso@amsl.com, sginoza@amsl.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] #334 (Version 2 cli txt): Non-contiguous URL numbers in text format X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 11:33:51 -0000 #334: Non-contiguous URL numbers in text format Comment (by henrik@levkowetz.com): From [2378]: Include erefs with text equal to the URL in the URIs section. See issue #334. -- ------------------------------------+---------------------------------- Reporter: jyasskin@chromium.org | Owner: henrik@levkowetz.com Type: defect | Status: new Priority: medium | Milestone: Component: Version 2 cli txt | Version: Resolution: | Keywords: ------------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Fri Sep 1 04:51:12 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B04132E55 for ; Fri, 1 Sep 2017 04:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 JyxscDf61Htu for ; Fri, 1 Sep 2017 04:51:08 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C810D1332D6 for ; Fri, 1 Sep 2017 04:51:08 -0700 (PDT) Received: from localhost ([::1]:46025 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dnkTc-0002J0-Dv; Fri, 01 Sep 2017 04:51:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: henrik@levkowetz.com X-Trac-Project: xml2rfc Date: Fri, 01 Sep 2017 11:51:08 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: /ticket/335#comment:1 Message-ID: <084.950b091ac6a5ef5b3f90eb103b341a6e@tools.ietf.org> References: <069.9bee161759f832ae3273bc9264d098b5@tools.ietf.org> X-Trac-Ticket-ID: 335 In-Reply-To: <069.9bee161759f832ae3273bc9264d098b5@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: henrik@levkowetz.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] #335 (Version 2 cli txt): Mismatched URL references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 11:51:11 -0000 #335: Mismatched URL references Changes (by henrik@levkowetz.com): * status: new => closed * resolution: => fixed Comment: Fixed in [2379]: Include notes when doing index processing. Fixes issue #335. -- ------------------------------------+---------------------------------- Reporter: jyasskin@chromium.org | Owner: henrik@levkowetz.com Type: defect | Status: closed Priority: medium | Milestone: Component: Version 2 cli txt | Version: Resolution: fixed | Keywords: ------------------------------------+---------------------------------- Ticket URL: xml2rfc From nobody Fri Sep 1 04:55:12 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763DA129A89 for ; Fri, 1 Sep 2017 04:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 PTZ-6DtBZ8BD for ; Fri, 1 Sep 2017 04:55:08 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABDF1126E7A for ; Fri, 1 Sep 2017 04:55:08 -0700 (PDT) Received: from localhost ([::1]:46066 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dnkXU-00086T-AJ; Fri, 01 Sep 2017 04:55:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: tony@att.com, henrik@levkowetz.com X-Trac-Project: xml2rfc Date: Fri, 01 Sep 2017 11:55:08 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/336#comment:1 Message-ID: <084.648638c32de8bbd033d128d2f965d801@tools.ietf.org> References: <069.18177c451f378539dd6a1c83288a4804@tools.ietf.org> X-Trac-Ticket-ID: 336 In-Reply-To: <069.18177c451f378539dd6a1c83288a4804@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: tony@att.com, henrik@levkowetz.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] #336 (Version 2 cli): Website should say to report issues to this Trac X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 11:55:10 -0000 #336: Website should say to report issues to this Trac Changes (by henrik@levkowetz.com): * owner: henrik@levkowetz.com => tony@att.com -- ------------------------------------+-------------------------- Reporter: jyasskin@chromium.org | Owner: tony@att.com Type: defect | Status: new Priority: medium | Milestone: Component: Version 2 cli | Version: Resolution: | Keywords: ------------------------------------+-------------------------- Ticket URL: xml2rfc From nobody Fri Sep 1 07:17:33 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5F613310C for ; Fri, 1 Sep 2017 07:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 2Hs-sL5mluhZ for ; Fri, 1 Sep 2017 07:17:31 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C192132E82 for ; Fri, 1 Sep 2017 07:17:30 -0700 (PDT) Received: from localhost ([::1]:49859 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dnmlD-0005gs-Ps; Fri, 01 Sep 2017 07:17:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: tony@att.com, henrik@levkowetz.com X-Trac-Project: xml2rfc Date: Fri, 01 Sep 2017 14:17:27 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/336#comment:2 Message-ID: <084.9ed68526b6ef265b5eb464954bd85ee6@tools.ietf.org> References: <069.18177c451f378539dd6a1c83288a4804@tools.ietf.org> X-Trac-Ticket-ID: 336 In-Reply-To: <069.18177c451f378539dd6a1c83288a4804@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: tony@att.com, henrik@levkowetz.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] #336 (Version 2 cli): Website should say to report issues to this Trac X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 14:17:32 -0000 #336: Website should say to report issues to this Trac Comment (by tony@att.com): modified info in experimental.html Committed revision 2382. -- ------------------------------------+-------------------------- Reporter: jyasskin@chromium.org | Owner: tony@att.com Type: defect | Status: new Priority: medium | Milestone: Component: Version 2 cli | Version: Resolution: | Keywords: ------------------------------------+-------------------------- Ticket URL: xml2rfc From nobody Fri Sep 1 07:18:17 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4E91341E3 for ; Fri, 1 Sep 2017 07:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 No6ypSyV7ubE for ; Fri, 1 Sep 2017 07:18:14 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E742F132E66 for ; Fri, 1 Sep 2017 07:18:14 -0700 (PDT) Received: from localhost ([::1]:49871 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1dnmlx-0007B6-Rz; Fri, 01 Sep 2017 07:18:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "xml2rfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Cc: xml2rfc@ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: tony@att.com, henrik@levkowetz.com X-Trac-Project: xml2rfc Date: Fri, 01 Sep 2017 14:18:13 -0000 X-URL: http://tools.ietf.org/tools/xml2rfc/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/336#comment:3 Message-ID: <084.156a26c8ada978a6c9184fac3cb25a36@tools.ietf.org> References: <069.18177c451f378539dd6a1c83288a4804@tools.ietf.org> X-Trac-Ticket-ID: 336 In-Reply-To: <069.18177c451f378539dd6a1c83288a4804@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: tony@att.com, henrik@levkowetz.com, xml2rfc@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] #336 (Version 2 cli): Website should say to report issues to this Trac X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 14:18:16 -0000 #336: Website should say to report issues to this Trac Changes (by tony@att.com): * status: new => closed * resolution: => fixed -- ------------------------------------+-------------------------- Reporter: jyasskin@chromium.org | Owner: tony@att.com Type: defect | Status: closed Priority: medium | Milestone: Component: Version 2 cli | Version: Resolution: fixed | Keywords: ------------------------------------+-------------------------- Ticket URL: xml2rfc From nobody Mon Sep 4 08:01:44 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0010B12426E; Mon, 4 Sep 2017 08:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 d16NABIFcDmF; Mon, 4 Sep 2017 08:01:29 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC58D132C2C; Mon, 4 Sep 2017 08:01:22 -0700 (PDT) Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from ) id 1dossM-00067i-Kd; Mon, 04 Sep 2017 08:01:22 -0700 To: xml2rfc@ietf.org Cc: codesprints@ietf.org, rfc-markdown@ietf.org Message-Id: From: Henrik Levkowetz Date: Mon, 04 Sep 2017 08:01:22 -0700 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: codesprints@ietf.org, rfc-markdown@ietf.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc] New xml2rfc release: v2.8.0 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 15:01:31 -0000 Hi, This is an automatic notification about a new xml2rfc release, v2.8.0, generated when running the mkrelease script. Release notes: xml2rfc (2.8.0) ietf; urgency=low This is a small feature release which changes URLs in boilerplate to use https: instead of http:. There are also some bugfixes. * Include notes when doing index processing. Fixes issue #335. * Include erefs with text equal to the URL in the URIs section. See issue #334. * Changed the use of http: to https: in many places. In the generation of RFCs, the code uses a switchover date of August 21, 2017 when deciding whether to insert http: or https: URLs. In practice, this means that RFCs with a date of September 2017 or later will get https:. Also fixed URL line-breaking prevention to apply to https: URLS. Fixes issue #333. * In urlkeep(), prevent breaking also for https:, not only http: URLs The new version is available through SVN checkout, with 'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.8.0' Regards, Henrik (via the mkrelease script) From nobody Mon Sep 4 12:01:34 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EF1126BFD; Mon, 4 Sep 2017 12:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 XZzsugLc6_J8; Mon, 4 Sep 2017 12:01:20 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 79C91126B6D; Mon, 4 Sep 2017 12:01:20 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id b23so4668814qkg.1; Mon, 04 Sep 2017 12:01:20 -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=FSl0pz6qokGMGGgy4BBJiUh4Q7rxhhH2h4LZjlCJAcY=; b=ef4PMYIJojTCbUK6uaBl2gu5l8jTANq8WnOZ+u0PtPsbWw0JXTNTQ1xTJ633cUTsrN h1F6y4DMbCey4pAOPQEQha1AxoyvCx7TMLkKsP9EirsWoCbCRvXRF5t1hrqXerYWas5N cYGd5QK9clSH85dD1erFokSrDRH3qT5+5z+5kPHBWgA8ghkJrC39ngY7ZYuXFAMlMfA6 LwlXDE/GFF/HjT4Clrqjs7mW4ZrJHs5kXfWPnLTLM0milBbTwl+U1rb71PWD3+YHU2rU DYqDUiypuB8oS+qX26YNtBA8/yMMKGun4wXaU22wreEb9hX9F/1wLEA+GQyKQw6syo7w UGpg== 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=FSl0pz6qokGMGGgy4BBJiUh4Q7rxhhH2h4LZjlCJAcY=; b=Jt2VyF+DT8yDp4Qi8cdqss0xS+/YWs/6JvJe9TfqqZZneSvpUFEPKir4nOufNIgDf6 NB2AJT/h/qYfB3i6dYscMsJNv29XesKjLNv8d//aqkoKdMn4KrK9JSkKlvyRR/UxkPmF s5SMHs+qJ3b+LbRnpb4TLDa4IGioRt7tUup9ZCkYPmPYpBrUdvCI2roYB3tvqYRJ4uPb K5MNtMIn3uXEG9kRTIzYhLyYVHvbFeQI4gqznjzr6cnwNBA0L3Y+BwwDnAOA7Yfu5q67 YdB6nw6I0W8TN1Yr6FJvvLDQIle9AutJDMjcyYtoEJH9XXRC20RWi0jFX2+2Wg0VLH2i V3VQ== X-Gm-Message-State: AHPjjUgExlsfe/qw0Qu9NNmza8Hf4tTwycEAPIHdsIYyUQOgNrTSqpiX V3aOsn/uHX2pTBnplO2xKt1cLytmZUistZk= X-Google-Smtp-Source: ADKCNb4LnCMUfr4yGSwBA1HjQ3l0K1k/843g/UH+U2HUc2leEFj4zBfHSZxtfbhQbZnsKBi8kRRrLWA8uhDwhvhwtAA= X-Received: by 10.55.186.1 with SMTP id k1mr1291771qkf.28.1504551677548; Mon, 04 Sep 2017 12:01:17 -0700 (PDT) MIME-Version: 1.0 Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.140.107.73 with HTTP; Mon, 4 Sep 2017 12:01:16 -0700 (PDT) In-Reply-To: References: From: Dhruv Dhody Date: Tue, 5 Sep 2017 00:31:16 +0530 X-Google-Sender-Auth: W2YPfiy6Atjqsou0kG6L5YbQ6Fs Message-ID: To: Henrik Levkowetz Cc: xml2rfc@ietf.org, rfc-markdown@ietf.org, codesprints@ietf.org Content-Type: multipart/alternative; boundary="94eb2c043d0c497447055861bcfa" Archived-At: Subject: Re: [xml2rfc] New xml2rfc release: v2.8.0 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 19:01:28 -0000 --94eb2c043d0c497447055861bcfa Content-Type: text/plain; charset="UTF-8" Hi, Because of this change idnits is failing and submission for draft is getting blocked. I am going to make manual change now, idnits output below for your reference - Thanks! Dhruv idnits 2.14.01 /var/www/.idnits tmp/draft-ietf-pce-pceps-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. ... text found in draft: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ..................................^ (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? 1id_guidelines, paragraph 1: Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. ... text found in draft: Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working ....................^ documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. 1id_guidelines, paragraph 3: The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. 1id_guidelines, paragraph 4: The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119, paragraph 2: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. ... text found in draft: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", ................................................^ and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC5440, updated by this document, for RFC5378 checks: 2007-11-16) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). -------------------------------------------------------------------------------- 2 PCE Working Group D. Lopez 3 Internet-Draft O. Gonzalez de Dios 4 Updates: 5440 (if approved) Telefonica I+D 5 Intended status: Standards Track Q. Wu 6 Expires: March 8, 2018 D. Dhody 7 Huawei 8 September 4, 2017 10 Secure Transport for PCEP 11 draft-ietf-pce-pceps-17 13 Abstract 15 The Path Computation Element Communication Protocol (PCEP) defines 16 the mechanisms for the communication between a Path Computation 17 Client (PCC) and a Path Computation Element (PCE), or among PCEs. 18 This document describes the usage of Transport Layer Security (TLS) 19 to enhance PCEP security, hence the PCEPS acronym proposed for it. 20 The additional security mechanisms are provided by the transport 21 protocol supporting PCEP, and therefore they do not affect the 22 flexibility and extensibility of PCEP. 24 This document updates RFC 5440 in regards to the PCEP initialization 25 phase procedures. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 8, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 75 3. Applying PCEPS . . . . . . . . . . . . . . . . . . . . . . . 4 76 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3.2. Initiating the TLS Procedures . . . . . . . . . . . . . . 4 78 3.3. The StartTLS Message . . . . . . . . . . . . . . . . . . 7 79 3.4. TLS Connection Establishment . . . . . . . . . . . . . . 12 80 3.5. Peer Identity . . . . . . . . . . . . . . . . . . . . . . 14 81 3.6. Connection Establishment Failure . . . . . . . . . . . . 15 82 4. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . . 15 83 4.1. DANE Applicability . . . . . . . . . . . . . . . . . . . 16 84 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 16 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 6.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . 17 87 6.2. New Error-Values . . . . . . . . . . . . . . . . . . . . 17 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 8. Manageability Considerations . . . . . . . . . . . . . . . . 19 90 8.1. Control of Function and Policy . . . . . . . . . . . . . 19 91 8.2. Information and Data Models . . . . . . . . . . . . . . . 20 92 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20 93 8.4. Verifying Correct Operations . . . . . . . . . . . . . . 20 94 8.5. Requirements on Other Protocols . . . . . . . . . . . . . 20 95 8.6. Impact on Network Operation . . . . . . . . . . . . . . . 21 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 99 10.2. Informative References . . . . . . . . . . . . . . . . . 23 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 102 1. Introduction 104 The Path Computation Element Communication Protocol (PCEP) [RFC5440] 105 defines the mechanisms for the communication between a Path 106 Computation Client (PCC) and a Path Computation Element (PCE), or 107 between two PCEs. These interactions include requests and replies 108 that can be critical for a sustainable network operation and adequate 109 resource allocation, and therefore appropriate security becomes a key 110 element in the PCE infrastructure. As the applications of the PCE 111 framework evolves, and more complex service patterns emerge, the 112 definition of a secure mode of operation becomes more relevant. 114 [RFC5440] analyzes in its section on security considerations the 115 potential threats to PCEP and their consequences, and discusses 116 several mechanisms for protecting PCEP against security attacks, 117 without making a specific recommendation on a particular one or 118 defining their application in depth. Moreover, [RFC6952] remarks the 119 importance of ensuring PCEP communication confidentiality, especially 120 when PCEP communication endpoints do not reside in the same 121 Autonomous System (AS), as the interception of PCEP messages could 122 leak sensitive information related to computed paths and resources. 124 Among the possible solutions mentioned in these documents, Transport 125 Layer Security (TLS) [RFC5246] provides support for peer 126 authentication, message encryption and integrity. TLS provides well- 127 known mechanisms to support key configuration and exchange, as well 128 as means to perform security checks on the results of PCE discovery 129 procedures via Interior Gateway Protocol (IGP) ([RFC5088] and 130 [RFC5089]). 132 This document describes a security container for the transport of 133 PCEP messages, and therefore it does not affect the flexibility and 134 extensibility of PCEP. 136 This document describes how to apply TLS to secure interactions with 137 PCE, including initiation of the TLS procedures, the TLS handshake 138 mechanism, the TLS methods for peer authentication, the applicable 139 TLS ciphersuites for data exchange, and the handling of errors in the 140 security checks. In the rest of the document we will refer to this 141 usage of TLS to provide a secure transport for PCEP as "PCEPS". 143 Within this document, PCEP communications are described through PCC- 144 PCE relationship. The PCE architecture also supports the PCE-PCE 145 communication, this is achieved by requesting PCE fill the role of a 146 PCC, as usual. Thus, in this document, the PCC refers to a PCC or a 147 PCE initiating the PCEP session and acting as a client. 149 2. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 3. Applying PCEPS 159 3.1. Overview 161 The steps involved in establishing a PCEPS session are as follows: 163 1. Establishment of a TCP connection. 165 2. Initiating the TLS procedures by the StartTLS message from PCE to 166 PCC and from PCC to PCE. 168 3. Negotiation and establishment of TLS connection. 170 4. Start exchanging PCEP messages as per [RFC5440]. 172 This document uses the standard StartTLS procedure in PCEP, instead 173 of using a different port for the secured session. This is done to 174 avoid requesting allocation of another port number for the PCEPS. 175 The StartTLS procedure makes more efficient use of scarce port 176 numbers and allow simpler configuration of PCEP. 178 Implementations SHOULD follow the best practices and recommendations 179 for using TLS, as per [RFC7525]. 181 It should be noted that this procedure updates what is defined in 182 section 4.2.1 and section 6.7 of [RFC5440] regarding the 183 initialization phase and the processing of messages prior to the Open 184 message. The details of processing, including backward 185 compatibility, are discussed in the following sections. 187 3.2. Initiating the TLS Procedures 189 Since PCEP can operate either with or without TLS, it is necessary 190 for a PCEP speaker to indicate whether it wants to set up a TLS 191 connection or not. For this purpose, this document specifies a new 192 PCEP message called StartTLS. Thus, the PCEP session is secured via 193 TLS from the start before exchange of any other PCEP message (that 194 includes the Open message). This document thus updates [RFC5440], 195 which required the Open message to be the first PCEP message that is 196 exchanged. In the case of a PCEP session using TLS, the StartTLS 197 message will be sent first. Also a PCEP speaker that supports PCEPS 198 MUST NOT start the OpenWait timer after the TCP establishment, 199 instead it starts a StartTLSWait timer as described in Section 3.3. 201 The PCEP speaker MAY discover that the PCEP peer supports PCEPS or 202 can be preconfigured to use PCEPS for a given peer (see Section 4 for 203 more details). An existing PCEP session cannot be secured via TLS, 204 the session MUST be closed and re-established with TLS as per the 205 procedure described in this document. 207 The StartTLS message is a PCEP message sent by a PCC to a PCE and by 208 a PCE to a PCC in order to initiate the TLS procedure for PCEP. The 209 PCC initiates the use of TLS by sending a StartTLS message. The PCE 210 agrees to the use of TLS by responding with its own StartTLS message. 211 If the PCE is configured to only support TLS, it may send the 212 StartTLS message immediately upon TCP connection establishment; 213 otherwise it MUST wait for the PCC's first message to see whether it 214 is an Open or a StartTLS message. The TLS negotiation and 215 establishment procedures are triggered once the PCEP speaker has sent 216 and received the StartTLS message. The Message-Type field of the 217 PCEP common header for the StartTLS message is set to [TBA1 by IANA]. 219 Once the TCP connection has been successfully established, the first 220 message sent by the PCC to the PCE and by the PCE to the PCC MUST be 221 a StartTLS message for the PCEPS. Note that, this is a significant 222 change from [RFC5440], where the first PCEP message is the Open 223 message. 225 A PCEP speaker receiving a StartTLS message, after any other PCEP 226 exchange has taken place (by receiving or sending any other messages 227 from either side) MUST treat it as an unexpected message and reply 228 with a PCErr message with Error-Type set to [TBA2 by IANA] (PCEP 229 StartTLS failure) and Error-value set to 1 (reception of StartTLS 230 after any PCEP exchange), and MUST close the TCP connection. 232 Any message received prior to StartTLS or Open message MUST trigger a 233 protocol error condition causing a PCErr message to be sent with 234 Error-Type set to [TBA2 by IANA] (PCEP StartTLS failure) and Error- 235 value set to 2 (reception of a message apart from StartTLS or Open) 236 and MUST close the TCP connection. 238 If the PCEP speaker that does not support PCEPS, receives a StartTLS 239 message, it will behave according to the existing error mechanism 240 described in section 6.2 of [RFC5440] (in case message is received 241 prior to an Open message) or section 6.9 of [RFC5440] (for the case 242 of reception of unknown message). See Section 5 for more details. 244 If the PCEP speaker that only supports PCEPS connection (as a local 245 policy), receives an Open message, it MUST treat it as an unexpected 246 message and reply with a PCErr message with Error-Type set to 1 (PCEP 247 session establishment failure) and Error-value set to 1 (reception of 248 an invalid Open message or a non Open message), and MUST close the 249 TCP connection. 251 If a PCC supports PCEPS connections as well as allow non-PCEPS 252 connection (as a local policy), it MUST first try to establish PCEPS, 253 by sending StartTLS message and in case it receives an PCErr message 254 from the PCE, it MAY retry to establish connection without PCEPS by 255 sending an Open message. If a PCE supports PCEPS connections as well 256 as allow non-PCEPS connection (as a local policy), it MUST wait to 257 respond after TCP establishment, based on the message received from 258 the PCC. In case of StartTLS message, PCE MUST respond with sending 259 a StartTLS message and moving to TLS establishment procedures as 260 described in this document. In case of Open message, PCE MUST 261 respond with Open message and move to PCEP session establishment 262 procedure as per [RFC5440]. If a PCE supports PCEPS connections only 263 (as a local policy), it MAY send StartTLS message to PCC without 264 waiting to receive a StartTLS message from PCC. 266 If a PCEP speaker that is unwilling or unable to negotiate TLS 267 receives a StartTLS messages, it MUST return a PCErr message (in 268 clear) with Error-Type set to [TBA2 by IANA] (PCEP StartTLS failure) 269 and Error-value set to: 271 o 3 (Failure, connection without TLS is not possible) if it is not 272 willing to exchange PCEP messages without the solicited TLS 273 connection, and it MUST close the TCP session. 275 o 4 (Failure, connection without TLS is possible) if it is willing 276 to exchange PCEP messages without the solicited TLS connection, 277 and it MUST close the TCP session. The receiver MAY choose to 278 attempt to re-establish the PCEP session without TLS next. The 279 attempt to re-establish the PCEP session without TLS SHOULD be 280 limited to only once. 282 If the PCEP speaker supports PCEPS and can establish a TLS connection 283 it MUST start the TLS connection negotiation and establishment steps 284 described in Section 3.4 before the PCEP initialization procedure 285 (section 4.2.1 of [RFC5440]). 287 After the exchange of StartTLS messages, if the TLS negotiation fails 288 for some reason (e.g. the required mechanisms for certificate 289 revocation checking are not available), both peers SHOULD immediately 290 close the connection. 292 A PCEP speaker that does not support PCEPS sends the Open message 293 directly, as per [RFC5440]. A PCEP speaker that supports PCEPS, but 294 has learned in the last exchange the peer's willingness to 295 reestablish session without TLS, MAY send the Open message directly, 296 as per [RFC5440]. The attempt to re-establish the PCEP session 297 without TLS SHOULD be limited to only once. 299 Given the asymmetric nature of TLS for connection establishment, it 300 is relevant to identify the roles of each of the PCEP peers in it. 301 The PCC SHALL act as TLS client, and the PCE SHALL act as TLS server 302 as per [RFC5246]. 304 As per the recommendation from [RFC7525] to avoid downgrade attacks, 305 PCEP peers that support PCEPS, SHOULD default to strict TLS 306 configuration i.e. do not allow non-TLS PCEP sessions to be 307 established. PCEPS implementations MAY provide an option to allow 308 the operator to manually override strict TLS configuration and allow 309 unsecured connections. Execution of this override SHOULD trigger a 310 warning about the security implications of permitting unsecured 311 connections. 313 3.3. The StartTLS Message 315 The StartTLS message is used to initiate the TLS procedure for a 316 PCEPS session between the PCEP peers. A PCEP speaker sends the 317 StartTLS message to request negotiation and establishment of TLS 318 connection for PCEP. On receiving a StartTLS message from the PCEP 319 peer (i.e. when the PCEP speaker has sent and received StartTLS 320 message) it is ready to start the negotiation and establishment of 321 TLS and move to steps described in Section 3.4. 323 The collision resolution procedures described in [RFC5440] for the 324 exchange of Open messages MUST be applied by the PCEP peers during 325 the exchange of StartTLS messages. 327 The format of a StartTLS message is as follows: 329 ::= 331 The StartTLS message MUST contain only the PCEP common header with 332 Message-Type field set to [TBA1 by IANA]. 334 Once the TCP connection has been successfully established, the PCEP 335 speaker MUST start a timer called StartTLSWait timer, after the 336 expiration of which, if neither StartTLS message has been received, 337 nor a PCErr/Open message (in case of failure and PCEPS not supported 338 by the peer, respectively), it MUST send a PCErr message with Error- 339 Type set to [TBA2 by IANA] and Error-value set to 5 (no StartTLS (nor 340 PCErr/Open) message received before the expiration of the 341 StartTLSWait timer) and it MUST release the TCP connection . A 342 RECOMMENDED value for StartTLSWait timer is 60 seconds. The value of 343 StartTLSWait timer MUST NOT be less than OpenWait timer. 345 +-+-+ +-+-+ 346 |PCC| |PCE| 347 +-+-+ +-+-+ 348 | | 349 | StartTLS | 350 | msg | 351 |------- | 352 | \ StartTLS | 353 | \ msg | 354 | \ ---------| 355 | \/ | 356 | /\ | 357 | / -------->| 358 | / | 359 |<------ | 360 |:::::::::TLS:::::::::| 361 |:::::Establishment:::| 362 | | 363 | | 364 |:::::::PCEP::::::::::| 365 | | 367 Figure 1: Both PCEP Speaker supports PCEPS (strict) 368 +-+-+ +-+-+ 369 |PCC| |PCE| 370 +-+-+ +-+-+ 371 | | 372 | StartTLS | 373 | msg | 374 |------- | 375 | \ StartTLS | 376 | \ msg | 377 | \ ---------| 378 | \/ | 379 | /\ | 380 | / -------->| 381 | / | 382 |<------ | 383 |:::::::::TLS:::::::::| TLS Establishment 384 |:::::Establishment:::| Failure, Both 385 | | peers close 386 session 388 Figure 2: Both PCEP Speaker supports PCEPS (strict), but cannot 389 establish TLS 391 +-+-+ +-+-+ 392 |PCC| |PCE| 393 +-+-+ +-+-+ 394 | | Does not support 395 | StartTLS | PCEPS and thus 396 | msg | sends Open 397 |------- | 398 | \ Open | 399 | \ msg | 400 | \ ---------| 401 | \/ | 402 | /\ | 403 | / -------->| 404 | / | 405 |<------ | 406 | | 407 |<--------------------| Send Error 408 | PCErr | Type=1,Value=1 409 | | (non-Open message 410 |<--------------------| received) 411 | Close | 412 ///////// TCP ///////// 413 //////re-establish///// 414 Send Open | Open | 415 this time | msg | 416 |------- | 417 | \ Open | 418 | \ msg | 419 | \ ---------| 420 | \/ | 421 | /\ | 422 | / -------->| 423 | / | 424 |<------ | 426 Figure 3: One PCEP Speaker (PCE) does not support PCEPS, while PCC 427 supports both with or without PCEPS 429 +-+-+ +-+-+ 430 |PCC| |PCE| 431 +-+-+ +-+-+ 432 | | 433 | StartTLS | 434 | msg | PCE waits 435 |-------------------->| for PCC and 436 | StartTLS | respond with 437 |<--------------------| Start TLS 438 | | 439 |:::::::::TLS:::::::::| 440 |:::::Establishment:::| 441 | | 442 | | 443 |:::::::PCEP::::::::::| 444 | | 446 Figure 4: Both PCEP Speaker supports PCEPS as well as without PCEPS 448 +-+-+ +-+-+ 449 |PCC| |PCE| 450 +-+-+ +-+-+ 451 | | 452 | StartTLS | 453 | msg | PCE waits 454 |-------------------->| for PCC 455 | PCErr | 456 |<--------------------| Send Error 457 | | Type=TBA2,Value=3 458 | | (Failure, connection 459 |<--------------------| without TLS is not 460 | Close | possible) 462 Figure 5: Both PCEP Speaker supports PCEPS as well as without PCEPS, 463 but PCE cannot start TLS negotiation 465 +-+-+ +-+-+ 466 |PCC| |PCE| 467 +-+-+ +-+-+ 468 | | 469 | Open | 470 | msg | PCE waits 471 |-------------------->| for PCC and 472 | Open | respond with 473 |<--------------------| Open 474 | | 475 |:::::::PCEP::::::::::| 476 | | 478 Figure 6: PCE supports PCEPS as well as without PCEPS, while PCC does 479 not support PCEPS 481 3.4. TLS Connection Establishment 483 Once the establishment of TLS has been agreed by the PCEP peers, the 484 connection establishment SHALL follow the following steps: 486 1. Immediately negotiate a TLS session according to [RFC5246]. The 487 following restrictions apply: 489 * Support for TLS v1.2 [RFC5246] or later is REQUIRED. 491 * Support for certificate-based mutual authentication is 492 REQUIRED. 494 * Negotiation of a ciphersuite providing for integrity 495 protection is REQUIRED. 497 * Negotiation of a ciphersuite providing for confidentiality is 498 RECOMMENDED. 500 * Support for and negotiation of compression is OPTIONAL. 502 * PCEPS implementations MUST, at a minimum, support negotiation 503 of the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [RFC6460], and 504 SHOULD support TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as 505 well. Implementations SHOULD support the NIST P-256 506 (secp256r1) curve [RFC4492]. In addition, PCEPS 507 implementations MUST support negotiation of the mandatory-to- 508 implement ciphersuites required by the versions of TLS that 509 they support from TLS 1.3 onwards. 511 2. Peer authentication can be performed in any of the following two 512 REQUIRED operation models: 514 * TLS with X.509 certificates using Public-Key Infrastructure 515 Exchange (PKIX) trust models: 517 + Implementations MUST allow the configuration of a list of 518 trusted Certification Authorities (CAs) for incoming 519 connections. 521 + Certificate validation MUST include the verification rules 522 as per [RFC5280]. 524 + PCEPS implementations SHOULD incorporate revocation methods 525 (CRL downloading, OCSP...) according to the trusted CA 526 policies. 528 + Implementations SHOULD indicate their trusted CAs. For TLS 529 1.2, this is done using [RFC5246], Section 7.4.4, 530 "certificate_authorities" (server side) and [RFC6066], 531 Section 6 "Trusted CA Indication" (client side). 533 + Implementations MUST follow the rules and guidelines for 534 peer validation as defined in [RFC6125]. If an expected 535 DNS name or IP address for the peer is configured, then the 536 implementations MUST check them against the values in the 537 presented certificate. The DNS names and the IP addresses 538 can be contained in the CN-ID [RFC6125] (Common Name 539 Identifier) or the subjectAltName entries. For 540 verification, only one of these entries is considered. The 541 following precedence applies: for DNS name validation, DNS- 542 ID [RFC6125] has precedence over CN-ID; for IP address 543 validation, subjectAltName:iPAddr has precedence over CN- 544 ID. 546 + Implementations MAY allow the configuration of a set of 547 additional properties of the certificate to check for a 548 peer's authorization to communicate (e.g., a set of allowed 549 values in URI-ID [RFC6125] or a set of allowed X509v3 550 Certificate Policies). The definition of these properties 551 are out of scope of this document. 553 * TLS with X.509 certificates using certificate fingerprints: 554 Implementations MUST allow the configuration of a list of 555 certificates that are trusted to identify peers, identified 556 via fingerprint of the Distinguished Encoding Rules (DER) 557 encoded certificate octets. Implementations MUST support 558 SHA-256 as defined by [SHS] as the hash algorithm for the 559 fingerprint, but a later revision may demand support for a 560 stronger hash function. 562 3. Start exchanging PCEP messages. 564 * Once the TLS connection has been successfully established, the 565 PCEP speaker MUST start the OpenWait timer [RFC5440], after 566 the expiration of which, if no Open message has been received, 567 it sends a PCErr message and releases the TCP/TLS connection. 569 3.5. Peer Identity 571 Depending on the peer authentication method in use, PCEPS supports 572 different operation modes to establish peer's identity and whether it 573 is entitled to perform requests or can be considered authoritative in 574 its replies. PCEPS implementations SHOULD provide mechanisms for 575 associating peer identities with different levels of access and/or 576 authoritativeness, and they MUST provide a mechanism for establishing 577 a default level for properly identified peers. Any connection 578 established with a peer that cannot be properly identified SHALL be 579 terminated before any PCEP exchange takes place. 581 In TLS-X.509 mode using fingerprints, a peer is uniquely identified 582 by the fingerprint of the presented certificate. 584 There are numerous trust models in PKIX environments, and it is 585 beyond the scope of this document to define how a particular 586 deployment determines whether a peer is trustworthy. Implementations 587 that want to support a wide variety of trust models should expose as 588 many details of the presented certificate to the administrator as 589 possible so that the trust model can be implemented by the 590 administrator. At least the following parameters of the X.509 591 certificate SHOULD be exposed: 593 o Peer's IP address 595 o Peer's fully qualified domain name (FQDN) 597 o Certificate Fingerprint 599 o Issuer 601 o Subject 603 o All X509v3 Extended Key Usage 605 o All X509v3 Subject Alternative Name 607 o All X509v3 Certificate Policies 608 Note that the remote IP address used for the TCP session 609 establishment is also exposed. 611 [I-D.ietf-pce-stateful-sync-optimizations] specify a Speaker Entity 612 Identifier TLV (SPEAKER-ENTITY-ID), as an optional TLV that is 613 included in the OPEN Object. It contains a unique identifier for the 614 node that does not change during the lifetime of the PCEP speaker. 615 An implementation would thus expose the speaker entity identifier as 616 part of the X509v3 certificate's subjectAltName:otherName, so that an 617 implementation could use this identifier for the peer identification 618 trust model. 620 In addition, a PCC MAY apply the procedures described in [RFC6698] 621 DNS-Based Authentication of Named Entities (DANE) to verify its peer 622 identity when using DNS discovery. See section Section 4.1 for 623 further details. 625 3.6. Connection Establishment Failure 627 In case the initial TLS negotiation or the peer identity check fails, 628 according to the procedures listed in this document, both peers 629 SHOULD immediately close the connection. 631 The initiator SHOULD follow the procedure listed in [RFC5440] to 632 retry session setup as per the exponential back-off session 633 establishment retry procedure. 635 4. Discovery Mechanisms 637 This document does not specify any discovery mechanism for support of 638 PCEPS. Other documents, [I-D.wu-pce-discovery-pceps-support] and 639 [I-D.wu-pce-dns-pce-discovery] have made proposals: 641 o A PCE can advertise its capability to support PCEPS using the 642 IGP's advertisement mechanism of the PCE discovery information. 643 The PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to advertise 644 PCE capabilities. It is present within the PCE Discovery (PCED) 645 sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] provide 646 the description and processing rules for this sub-TLV when carried 647 within OSPF and IS-IS, respectively. PCE capability bits are 648 defined in [RFC5088]. A new capability flag bit for the PCE-CAP- 649 FLAGS sub-TLV that can be announced as an attribute to distribute 650 PCEP security support information is proposed in 651 [I-D.wu-pce-discovery-pceps-support]. 653 o A PCE can advertise its capability to support PCEPS using the DNS 654 [I-D.wu-pce-dns-pce-discovery] by identifying the support of TLS. 656 4.1. DANE Applicability 658 DANE [RFC6698] defines a secure method to associate the certificate 659 that is obtained from a TLS server with a domain name using DNS, 660 i.e., using the TLSA DNS resource record (RR) to associate a TLS 661 server certificate or public key with the domain name where the 662 record is found, thus forming a "TLSA certificate association". The 663 DNS information needs to be protected by DNS Security (DNSSEC). A 664 PCC willing to apply DANE to verify server identity MUST conform to 665 the rules defined in section 4 of [RFC6698]. The implementation MUST 666 support Service certificate constraint (TLSA Certificate Usages type 667 1) with Matching type 2 (SHA2-256) as described in 668 [RFC6698][RFC7671]. The server's domain name must be authorized 669 separately, as TLSA does not provide any useful authorization 670 guarantees. 672 5. Backward Compatibility 674 The procedures described in this document define a security container 675 for the transport of PCEP requests and replies carried by a TLS 676 connection initiated by means of a specific extended message 677 (StartTLS) that does not interfere with PCEP speaker implementations 678 not supporting it. 680 A PCC that does not support PCEPS will send Open message as the first 681 message on TCP establishment. A PCE that supports PCEPS only, will 682 send StartTLS message on TCP establishment. On receiving StartTLS 683 message, PCC would consider it as an error and behave according to 684 the existing error mechanism of [RFC5440] and send PCErr message with 685 Error-Type 1 (PCEP session establishment failure) and Error-Value 1 686 (reception of an invalid Open message or a non Open message) and 687 close the session. 689 A PCC that support PCEPS will send StartTLS message as the first 690 message on TCP establishment. A PCE that does not supports PCEPS, 691 would consider receiving StartTLS message as an error and respond 692 with PCErr message (with Error-Type 1 and Error-Value 1) and close 693 the session. 695 If a StartTLS message is received at any other time by a PCEP speaker 696 that does not implement PCEPS, it would consider it as an unknown 697 message and would behave according to the existing error mechanism of 698 [RFC5440] and send PCErr message with Error-Type 2 (Capability not 699 supported) and close the session. 701 An existing PCEP session cannot be upgraded to PCEPS, the session 702 needs to be terminated and reestablished as per the procedure 703 described in this document. During the incremental upgrade, the PCEP 704 speaker SHOULD allow session establishment with and without TLS. 705 Once both PCEP speakers are upgraded to support PCEPS, the PCEP 706 session is re-established with TLS, otherwise PCEP session without 707 TLS is setup. A redundant PCE MAY also be used during the 708 incremental deployment to take over the PCE undergoing upgrade. Once 709 the upgrade is completed, support for unsecured version SHOULD be 710 removed. 712 A PCE that accepts connections with or without PCEPS, it would 713 respond based on the message received from PCC. A PCC that supports 714 connection with or without PCEPS, it would first attempt to connect 715 with PCEPS and in case of error, it MAY retry to establish connection 716 without PCEPS. For successful TLS operations with PCEP, both PCEP 717 peers in the network would need to be upgraded to support this 718 document. 720 Note that, a PCEP implementation that support PCEPS would respond 721 with PCErr message with Error-Type set to [TBA2 by IANA] (PCEP 722 StartTLS failure) and Error-value set to 2 if any other message is 723 sent before StartTLS or Open. If the sender of the invalid message 724 is a PCEP implementation that does not support PCEPS, it will not be 725 able to understand this error. A PCEPS implementation could also 726 send the PCErr message as per [RFC5440] with Error-Type "PCEP session 727 establishment failure" and Error-value "reception of an invalid Open 728 message or a non Open message" before closing the session. 730 6. IANA Considerations 732 6.1. New PCEP Message 734 IANA is requested to allocate new message types within the "PCEP 735 Messages" sub-registry of the PCEP Numbers registry, as follows: 737 Value Description Reference 738 TBA1 The Start TLS Message (StartTLS) This document 740 6.2. New Error-Values 742 IANA is requested to allocate new Error Types and Error Values within 743 the " PCEP-ERROR Object Error Types and Values" sub-registry of the 744 PCEP Numbers registry, as follows: 746 Error- 747 Type Meaning Error-value Reference 749 TBA2 PCEP StartTLS 0:Unassigned This document 750 failure 1:Reception of This document 751 StartTLS after 752 any PCEP exchange 753 2:Reception of This document 754 any other message 755 apart from StartTLS, 756 Open or PCErr 757 3:Failure, connection This document 758 without TLS is not 759 possible 760 4:Failure, connection This document 761 without TLS is 762 possible 763 5:No StartTLS message This document 764 (nor PCErr/Open) 765 before StartTLSWait 766 timer expiry 768 7. Security Considerations 770 While the application of TLS satisfies the requirement on 771 confidentiality as well as fine-grained, policy-based peer 772 authentication, there are security threats that it cannot address. 773 It may be advisable to apply additional protection measures, in 774 particular in what relates to attacks specifically addressed to 775 forging the TCP connection underpinning TLS, especially in the case 776 of long-lived connections. One of these measures is the application 777 of TCP-AO (TCP Authentication Option [RFC5925]), which is fully 778 compatible with and deemed as complementary to TLS. The mechanisms 779 to configure the requirements to use TCP-AO and other lower-layer 780 protection measures with a particular peer are outside the scope of 781 this document. 783 Since computational resources required by TLS handshake and 784 ciphersuite are higher than unencrypted TCP, clients connecting to a 785 PCEPS server can more easily create high load conditions and a 786 malicious client might create a Denial-of-Service attack more easily. 788 Some TLS ciphersuites only provide integrity validation of their 789 payload, and provide no encryption, such ciphersuites SHOULD NOT be 790 used by default. Administrators MAY allow the usage of these 791 ciphersuites after careful weighting of the risk of relevant internal 792 data leakage, that can occur in such a case, as explicitly stated by 793 [RFC6952]. 795 When using certificate fingerprints to identify PCEPS peers, any two 796 certificates that produce the same hash value will be considered the 797 same peer. Therefore, it is important to make sure that the hash 798 function used is cryptographically uncompromised, so that attackers 799 are very unlikely to be able to produce a hash collision with a 800 certificate of their choice. This document mandates support for 801 SHA-256 as defined by [SHS], but a later revision may demand support 802 for stronger functions if suitable attacks on it are known. 804 PCEPS implementations that continue to accept connections without TLS 805 are susceptible to downgrade attacks as described in [RFC7457]. An 806 attacker could attempt to remove the use of StartTLS message that 807 request the use of TLS as it pass on the wire in clear, and further 808 inject a PCErr message that suggest to attempt PCEP connection 809 without TLS. 811 The guidance given in [RFC7525] SHOULD be followed to avoid attacks 812 on TLS. 814 8. Manageability Considerations 816 All manageability requirements and considerations listed in [RFC5440] 817 apply to PCEP protocol extensions defined in this document. In 818 addition, requirements and considerations listed in this section 819 apply. 821 8.1. Control of Function and Policy 823 A PCE or PCC implementation SHOULD allow configuring the PCEP 824 security via TLS capabilities as described in this document. 826 A PCE or PCC implementation supporting PCEP security via TLS MUST 827 support general TLS configuration as per [RFC5246]. At least the 828 configuration of one of the trust models and its corresponding 829 parameters, as described in Section 3.4 and Section 3.5, MUST be 830 supported by the implementation. 832 A PCEP implementation SHOULD allow configuring the StartTLSWait timer 833 value. 835 PCEPS implementations MAY provide an option to allow the operator to 836 manually override strict TLS configuration and allow unsecure 837 connections. Execution of this override SHOULD trigger a warning 838 about the security implications of permitting unsecure connections. 840 Further, the operator needs to develop suitable security policies 841 around PCEP within his network. The PCEP peers SHOULD provide ways 842 for the operator to complete the following tasks in regards to a PCEP 843 session: 845 o Determine if a session is protected via PCEPS. 847 o Determine the version of TLS, the mechanism used for 848 authentication, and the ciphersuite in use. 850 o Determine if the certificate could not be verified, and the reason 851 for this circumstance. 853 o Inspect the certificate offered by the PCEP peer. 855 o Be warned if StartTLS procedure fails for the PCEP peers, that are 856 known to support PCEPS via configurations or capability 857 advertisements. 859 8.2. Information and Data Models 861 The PCEP MIB module is defined in [RFC7420]. The MIB module could be 862 extended to include the ability to view the PCEPS capability, TLS 863 related information as well as TLS status for each PCEP peer. 865 Further, to allow the operator to configure the PCEPS capability and 866 various TLS related parameters as well as to view the current TLS 867 status for a PCEP session, the PCEP YANG module 868 [I-D.ietf-pce-pcep-yang] is extended to include TLS related 869 information. 871 8.3. Liveness Detection and Monitoring 873 Mechanisms defined in this document do not imply any new liveness 874 detection and monitoring requirements in addition to those already 875 listed in [RFC5440] and [RFC5246]. 877 8.4. Verifying Correct Operations 879 A PCEPS implementation SHOULD log error events and provide PCEPS 880 failure statistics with reasons. 882 8.5. Requirements on Other Protocols 884 Mechanisms defined in this document do not imply any new requirements 885 on other protocols. Note that, Section 4 list possible discovery 886 mechanism for support of PCEPS. 888 8.6. Impact on Network Operation 890 Mechanisms defined in this document do not have any significant 891 impact on network operations in addition to those already listed in 892 [RFC5440], and the policy and management implications discussed 893 above. 895 9. Acknowledgements 897 This specification relies on the analysis and profiling of TLS 898 included in [RFC6614] and the procedures described for the STARTTLS 899 command in [RFC4513]. 901 We would like to thank Joe Touch for his suggestions and support 902 regarding the StartTLS mechanisms. 904 Thanks to Daniel King for reminding the authors about manageability 905 considerations. 907 Thanks to Cyril Margaria for shepherding this document. 909 Thanks to David Mandelberg for early SECDIR review comments as well 910 as re-reviewing during IETF last call. 912 Thanks to Dan Frost for the RTGDIR review and comments. 914 Thanks to Dale Worley for the Gen-ART review and comments. 916 Also thanks to Tianran Zhou for OPSDIR review. 918 Thanks to Deborah Brungard for being the responsible AD and guiding 919 the authors as needed. 921 Thanks to Mirja Kuhlewind, Eric Rescorla, Warren Kumari, Kathleen 922 Moriarty, Suresh Krishnan, Ben Campbell and Alexey Melnikov for the 923 IESG review and comments. 925 10. References 927 10.1. Normative References 929 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 930 Requirement Levels", BCP 14, RFC 2119, 931 DOI 10.17487/RFC2119, March 1997, 932 . 934 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 935 (TLS) Protocol Version 1.2", RFC 5246, 936 DOI 10.17487/RFC5246, August 2008, 937 . 939 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 940 Housley, R., and W. Polk, "Internet X.509 Public Key 941 Infrastructure Certificate and Certificate Revocation List 942 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 943 . 945 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 946 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 947 DOI 10.17487/RFC5440, March 2009, 948 . 950 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 951 Extensions: Extension Definitions", RFC 6066, 952 DOI 10.17487/RFC6066, January 2011, 953 . 955 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 956 Verification of Domain-Based Application Service Identity 957 within Internet Public Key Infrastructure Using X.509 958 (PKIX) Certificates in the Context of Transport Layer 959 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 960 2011, . 962 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 963 of Named Entities (DANE) Transport Layer Security (TLS) 964 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 965 2012, . 967 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 968 "Recommendations for Secure Use of Transport Layer 969 Security (TLS) and Datagram Transport Layer Security 970 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 971 2015, . 973 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 974 Authentication of Named Entities (DANE) Protocol: Updates 975 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 976 October 2015, . 978 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 979 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 980 May 2017, . 982 [SHS] National Institute of Standards and Technology, "Secure 983 Hash Standard (SHS), FIPS PUB 180-4", 984 DOI 10.6028/NIST.FIPS.180-4, August 2015, 985 . 988 10.2. Informative References 990 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 991 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 992 for Transport Layer Security (TLS)", RFC 4492, 993 DOI 10.17487/RFC4492, May 2006, 994 . 996 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol 997 (LDAP): Authentication Methods and Security Mechanisms", 998 RFC 4513, DOI 10.17487/RFC4513, June 2006, 999 . 1001 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1002 Zhang, "OSPF Protocol Extensions for Path Computation 1003 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 1004 January 2008, . 1006 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1007 Zhang, "IS-IS Protocol Extensions for Path Computation 1008 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 1009 January 2008, . 1011 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1012 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1013 June 2010, . 1015 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport 1016 Layer Security (TLS)", RFC 6460, DOI 10.17487/RFC6460, 1017 January 2012, . 1019 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 1020 "Transport Layer Security (TLS) Encryption for RADIUS", 1021 RFC 6614, DOI 10.17487/RFC6614, May 2012, 1022 . 1024 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1025 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1026 and Authentication for Routing Protocols (KARP) Design 1027 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 1028 . 1030 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1031 Hardwick, "Path Computation Element Communication Protocol 1032 (PCEP) Management Information Base (MIB) Module", 1033 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1034 . 1036 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1037 Known Attacks on Transport Layer Security (TLS) and 1038 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1039 February 2015, . 1041 [I-D.ietf-pce-stateful-sync-optimizations] 1042 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1043 and D. Dhody, "Optimizations of Label Switched Path State 1044 Synchronization Procedures for a Stateful PCE", draft- 1045 ietf-pce-stateful-sync-optimizations-10 (work in 1046 progress), March 2017. 1048 [I-D.ietf-pce-pcep-yang] 1049 Dhody, D., Hardwick, J., Beeram, V., and j. 1050 jefftant@gmail.com, "A YANG Data Model for Path 1051 Computation Element Communications Protocol (PCEP)", 1052 draft-ietf-pce-pcep-yang-05 (work in progress), June 2017. 1054 [I-D.wu-pce-dns-pce-discovery] 1055 Wu, Q., Dhody, D., King, D., Lopez, D., and J. Tantsura, 1056 "Path Computation Element (PCE) Discovery using Domain 1057 Name System(DNS)", draft-wu-pce-dns-pce-discovery-10 (work 1058 in progress), March 2017. 1060 [I-D.wu-pce-discovery-pceps-support] 1061 Lopez, D., Wu, Q., Dhody, D., and D. King, "IGP extension 1062 for PCEP security capability support in the PCE 1063 discovery", draft-wu-pce-discovery-pceps-support-07 (work 1064 in progress), March 2017. 1066 Authors' Addresses 1068 Diego R. Lopez 1069 Telefonica I+D 1070 Don Ramon de la Cruz, 82 1071 Madrid 28006 1072 Spain 1074 Phone: +34 913 129 041 1075 EMail: diego.r.lopez@telefonica.com 1076 Oscar Gonzalez de Dios 1077 Telefonica I+D 1078 Don Ramon de la Cruz, 82 1079 Madrid 28006 1080 Spain 1082 Phone: +34 913 129 041 1083 EMail: oscar.gonzalezdedios@telefonica.com 1085 Qin Wu 1086 Huawei 1087 101 Software Avenue, Yuhua District 1088 Nanjing, Jiangsu 210012 1089 China 1091 EMail: sunseawq@huawei.com 1093 Dhruv Dhody 1094 Huawei 1095 Divyashree Techno Park, Whitefield 1096 Bangalore, KA 560066 1097 India 1099 EMail: dhruv.ietf@gmail.com On Mon, Sep 4, 2017 at 8:31 PM, Henrik Levkowetz wrote: > > Hi, > > This is an automatic notification about a new xml2rfc release, > v2.8.0, generated when running the mkrelease script. > > Release notes: > > xml2rfc (2.8.0) ietf; urgency=low > This is a small feature release which changes URLs in boilerplate to > use https: instead of http:. There are also some bugfixes. > * Include notes when doing index processing. Fixes issue #335. > * Include erefs with text equal to the URL in the URIs section. See > issue #334. > * Changed the use of http: to https: in many places. In the generation > of RFCs, the code uses a switchover date of August 21, 2017 when > deciding > whether to insert http: or https: URLs. In practice, this means that > RFCs > with a date of September 2017 or later will get https:. Also fixed URL > line-breaking prevention to apply to https: URLS. Fixes issue #333. > * In urlkeep(), prevent breaking also for https:, not only http: URLs > > The new version is available through SVN checkout, with > 'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.8.0 > ' > > Regards, > > Henrik > (via the mkrelease script) > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc > --94eb2c043d0c497447055861bcfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Because of = this change idnits is failing and submission for draft is getting blocked.=C2=A0
I am going to make manual change now, idnits=C2=A0output below for your reference -=C2=A0

Thanks! 
Dhruv

idnits 2.14.01  /var/www/.idnits


tmp/draft-ietf-pce-pceps-17.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/=
license-info):
  -------------------------------------------------------------------------=
---

  ** The document seems to lack a License Notice according IETF Trust
     Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
     Section 6.b -- however, there's a paragraph with a matching beginn=
ing.
     Boilerplate error?

     IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph =
3:
        This document is subject to BCP 78 and the IETF Trust's Legal P=
rovisions
        Relating to IETF Documents (http://trustee.ietf.org/license-info)
        in effect on the date of publication of this document.  Please
        review these documents carefully, as they describe your rights
        and restrictions with respect to this document.  Code Components
        extracted from this document must include Simplified BSD License
        text as described in Section 4.e of the Trust Legal Provisions
        and are provided without warranty as described in the Simplified
        BSD License.    =20

     ... text found in draft:
        This document is subject to BCP 78 and the IETF Trust's Legal P=
rovisions
        Relating to IETF Documents
..................................^
        (https://trustee.=
ietf.org/license-info) in effect on the date of
        publication of this document.  Please review these documents
        carefully, as they describe your rights and restrictions with
        respect to this document.  Code Components extracted from this
        document must include Simplified BSD License text as described in
        Section 4.e of the Trust Legal Provisions and are provided
        without warranty as described in the Simplified BSD License.



  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  -------------------------------------------------------------------------=
---

  ** The document seems to lack a 1id_guidelines paragraph about
     Internet-Drafts being working documents -- however, there's a para=
graph
     with a matching beginning. Boilerplate error?

     1id_guidelines, paragraph 1:
        Internet-Drafts are working documents of the Internet Engineering T=
ask
        Force (IETF), its areas, and its working groups.  Note that other
        groups may also distribute working documents as Internet-Drafts.   =
 =20

     ... text found in draft:
        Internet-Drafts are working documents of the Internet Engineering T=
ask
        Force (IETF).  Note that other groups may also distribute working
....................^
        documents as Internet-Drafts.  The list of current
        Internet-Drafts is at
        https://da=
tatracker.ietf.org/drafts/current/.


  ** The document seems to lack a 1id_guidelines paragraph about the list o=
f
     current Internet-Drafts.=20

     1id_guidelines, paragraph 3:
        The list of current Internet-Drafts can be accessed at
        http://www.ietf.=
org/1id-abstracts.html

  ** The document seems to lack a 1id_guidelines paragraph about the list o=
f
     Shadow Directories.=20

     1id_guidelines, paragraph 4:
        The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/sha=
dow.html


  Checking nits according to http://www.ietf.org/id-info/checklist :
  -------------------------------------------------------------------------=
---

     No issues found here.

  Miscellaneous warnings:
  -------------------------------------------------------------------------=
---

  =3D=3D The document seems to lack the recommended RFC 2119 boilerplate, e=
ven if
     it appears to use RFC 2119 keywords -- however, there's a paragrap=
h with
     a matching beginning. Boilerplate error?

     RFC 2119, paragraph 2:
        The key words "MUST", "MUST NOT", "REQUIRE=
D", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED"=
, "MAY", and "OPTIONAL" in
        this document are to be interpreted as described in RFC 2119.    =
=20

     ... text found in draft:
        The key words "MUST", "MUST NOT", "REQUIRE=
D", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED"=
, "NOT RECOMMENDED", "MAY",
................................................^
        and "OPTIONAL" in this document are to be interpreted as
        described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
        appear in all capitals, as shown here.


     (The document does seem to have the reference to RFC 2119 which the
     ID-Checklist requires).
     (Using the creation date from RFC5440, updated by this document, for
     RFC5378 checks: 2007-11-16)

  -- The document seems to contain a disclaimer for pre-RFC5378 work, and m=
ay
     have content which was first submitted before 10 November 2008.  The
     disclaimer is necessary when there are original authors that you have
     been unable to contact, or if some do not wish to grant the BCP78 righ=
ts
     to the IETF Trust.  If you are able to get all authors (current and
     original) to grant those rights, you can and should remove the
     disclaimer; otherwise, the disclaimer is needed and you can ignore thi=
s
     comment. (See the Legal Provisions document at
     http://trustee.ietf.o=
rg/license-info for more information.)


  Checking references for intended status: Proposed Standard
  -------------------------------------------------------------------------=
---

     (See RFCs 3967 and 4897 for information about using normative referenc=
es
     to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS'


     Summary: 4 errors (**), 0 flaws (~~), 1 warning (=3D=3D), 2 comments (=
--).

---------------------------------------------------------------------------=
-----


2	PCE Working Group                                               D. Lopez
3	Internet-Draft                                       O. Gonzalez de Dios
4	Updates: 5440 (if approved)                               Telefonica I+D
5	Intended status: Standards Track                                   Q. Wu
6	Expires: March 8, 2018                                          D. Dhody
7	                                                                  Huawei
8	                                                       September 4, 2017

10	                       Secure Transport for PCEP
11	                        draft-ietf-pce-pceps-17

13	Abstract

15	   The Path Computation Element Communication Protocol (PCEP) defines
16	   the mechanisms for the communication between a Path Computation
17	   Client (PCC) and a Path Computation Element (PCE), or among PCEs.
18	   This document describes the usage of Transport Layer Security (TLS)
19	   to enhance PCEP security, hence the PCEPS acronym proposed for it.
20	   The additional security mechanisms are provided by the transport
21	   protocol supporting PCEP, and therefore they do not affect the
22	   flexibility and extensibility of PCEP.

24	   This document updates RFC 5440 in regards to the PCEP initialization
25	   phase procedures.

27	Status of This Memo

29	   This Internet-Draft is submitted in full conformance with the
30	   provisions of BCP 78 and BCP 79.

32	   Internet-Drafts are working documents of the Internet Engineering
33	   Task Force (IETF).  Note that other groups may also distribute
34	   working documents as Internet-Drafts.  The list of current Internet-
35	   Drafts is at https://datatracker.ietf.org/drafts/current/.

37	   Internet-Drafts are draft documents valid for a maximum of six months
38	   and may be updated, replaced, or obsoleted by other documents at any
39	   time.  It is inappropriate to use Internet-Drafts as reference
40	   material or to cite them other than as "work in progress."

42	   This Internet-Draft will expire on March 8, 2018.

44	Copyright Notice

46	   Copyright (c) 2017 IETF Trust and the persons identified as the
47	   document authors.  All rights reserved.

49	   This document is subject to BCP 78 and the IETF Trust's Legal
50	   Provisions Relating to IETF Documents
51	   (https://trustee.ie=
tf.org/license-info) in effect on the date of
52	   publication of this document.  Please review these documents
53	   carefully, as they describe your rights and restrictions with respect
54	   to this document.  Code Components extracted from this document must
55	   include Simplified BSD License text as described in Section 4.e of
56	   the Trust Legal Provisions and are provided without warranty as
57	   described in the Simplified BSD License.

59	   This document may contain material from IETF Documents or IETF
60	   Contributions published or made publicly available before November
61	   10, 2008.  The person(s) controlling the copyright in some of this
62	   material may not have granted the IETF Trust the right to allow
63	   modifications of such material outside the IETF Standards Process.
64	   Without obtaining an adequate license from the person(s) controlling
65	   the copyright in such materials, this document may not be modified
66	   outside the IETF Standards Process, and derivative works of it may
67	   not be created outside the IETF Standards Process, except to format
68	   it for publication as an RFC or to translate it into languages other
69	   than English.

71	Table of Contents

73	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
74	   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
75	   3.  Applying PCEPS  . . . . . . . . . . . . . . . . . . . . . . .   4
76	     3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
77	     3.2.  Initiating the TLS Procedures . . . . . . . . . . . . . .   4
78	     3.3.  The StartTLS Message  . . . . . . . . . . . . . . . . . .   7
79	     3.4.  TLS Connection Establishment  . . . . . . . . . . . . . .  12
80	     3.5.  Peer Identity . . . . . . . . . . . . . . . . . . . . . .  14
81	     3.6.  Connection Establishment Failure  . . . . . . . . . . . .  15
82	   4.  Discovery Mechanisms  . . . . . . . . . . . . . . . . . . . .  15
83	     4.1.  DANE Applicability  . . . . . . . . . . . . . . . . . . .  16
84	   5.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .  16
85	   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
86	     6.1.  New PCEP Message  . . . . . . . . . . . . . . . . . . . .  17
87	     6.2.  New Error-Values  . . . . . . . . . . . . . . . . . . . .  17
88	   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
89	   8.  Manageability Considerations  . . . . . . . . . . . . . . . .  19
90	     8.1.  Control of Function and Policy  . . . . . . . . . . . . .  19
91	     8.2.  Information and Data Models . . . . . . . . . . . . . . .  20
92	     8.3.  Liveness Detection and Monitoring . . . . . . . . . . . .  20
93	     8.4.  Verifying Correct Operations  . . . . . . . . . . . . . .  20
94	     8.5.  Requirements on Other Protocols . . . . . . . . . . . . .  20
95	     8.6.  Impact on Network Operation . . . . . . . . . . . . . . .  21
96	   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21
97	   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
98	     10.1.  Normative References . . . . . . . . . . . . . . . . . .  21
99	     10.2.  Informative References . . . . . . . . . . . . . . . . .  23
100	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . =
.  24

102	1.  Introduction

104	   The Path Computation Element Communication Protocol (PCEP) [RFC5440]
105	   defines the mechanisms for the communication between a Path
106	   Computation Client (PCC) and a Path Computation Element (PCE), or
107	   between two PCEs.  These interactions include requests and replies
108	   that can be critical for a sustainable network operation and adequat=
e
109	   resource allocation, and therefore appropriate security becomes a ke=
y
110	   element in the PCE infrastructure.  As the applications of the PCE
111	   framework evolves, and more complex service patterns emerge, the
112	   definition of a secure mode of operation becomes more relevant.

114	   [RFC5440] analyzes in its section on security considerations the
115	   potential threats to PCEP and their consequences, and discusses
116	   several mechanisms for protecting PCEP against security attacks,
117	   without making a specific recommendation on a particular one or
118	   defining their application in depth.  Moreover, [RFC6952] remarks th=
e
119	   importance of ensuring PCEP communication confidentiality, especiall=
y
120	   when PCEP communication endpoints do not reside in the same
121	   Autonomous System (AS), as the interception of PCEP messages could
122	   leak sensitive information related to computed paths and resources.

124	   Among the possible solutions mentioned in these documents, Transport
125	   Layer Security (TLS) [RFC5246] provides support for peer
126	   authentication, message encryption and integrity.  TLS provides well=
-
127	   known mechanisms to support key configuration and exchange, as well
128	   as means to perform security checks on the results of PCE discovery
129	   procedures via Interior Gateway Protocol (IGP) ([RFC5088] and
130	   [RFC5089]).

132	   This document describes a security container for the transport of
133	   PCEP messages, and therefore it does not affect the flexibility and
134	   extensibility of PCEP.

136	   This document describes how to apply TLS to secure interactions with
137	   PCE, including initiation of the TLS procedures, the TLS handshake
138	   mechanism, the TLS methods for peer authentication, the applicable
139	   TLS ciphersuites for data exchange, and the handling of errors in th=
e
140	   security checks.  In the rest of the document we will refer to this
141	   usage of TLS to provide a secure transport for PCEP as "PCEPS&q=
uot;.

143	   Within this document, PCEP communications are described through PCC-
144	   PCE relationship.  The PCE architecture also supports the PCE-PCE
145	   communication, this is achieved by requesting PCE fill the role of a
146	   PCC, as usual.  Thus, in this document, the PCC refers to a PCC or a
147	   PCE initiating the PCEP session and acting as a client.

149	2.  Requirements Language

151	   The key words "MUST", "MUST NOT", "REQUIRED=
", "SHALL", "SHALL NOT",
152	   "SHOULD", "SHOULD NOT", "RECOMMENDED",=
 "NOT RECOMMENDED", "MAY", and
153	   "OPTIONAL" in this document are to be interpreted as descr=
ibed in BCP
154	   14 [RFC2119] [RFC8174] when, and only when, they appear in all
155	   capitals, as shown here.

157	3.  Applying PCEPS

159	3.1.  Overview

161	   The steps involved in establishing a PCEPS session are as follows:

163	   1.  Establishment of a TCP connection.

165	   2.  Initiating the TLS procedures by the StartTLS message from PCE t=
o
166	       PCC and from PCC to PCE.

168	   3.  Negotiation and establishment of TLS connection.

170	   4.  Start exchanging PCEP messages as per [RFC5440].

172	   This document uses the standard StartTLS procedure in PCEP, instead
173	   of using a different port for the secured session.  This is done to
174	   avoid requesting allocation of another port number for the PCEPS.
175	   The StartTLS procedure makes more efficient use of scarce port
176	   numbers and allow simpler configuration of PCEP.

178	   Implementations SHOULD follow the best practices and recommendations
179	   for using TLS, as per [RFC7525].

181	   It should be noted that this procedure updates what is defined in
182	   section 4.2.1 and section 6.7 of [RFC5440] regarding the
183	   initialization phase and the processing of messages prior to the Ope=
n
184	   message.  The details of processing, including backward
185	   compatibility, are discussed in the following sections.

187	3.2.  Initiating the TLS Procedures

189	   Since PCEP can operate either with or without TLS, it is necessary
190	   for a PCEP speaker to indicate whether it wants to set up a TLS
191	   connection or not.  For this purpose, this document specifies a new
192	   PCEP message called StartTLS.  Thus, the PCEP session is secured via
193	   TLS from the start before exchange of any other PCEP message (that
194	   includes the Open message).  This document thus updates [RFC5440],
195	   which required the Open message to be the first PCEP message that is
196	   exchanged.  In the case of a PCEP session using TLS, the StartTLS
197	   message will be sent first.  Also a PCEP speaker that supports PCEPS
198	   MUST NOT start the OpenWait timer after the TCP establishment,
199	   instead it starts a StartTLSWait timer as described in Section 3.3.

201	   The PCEP speaker MAY discover that the PCEP peer supports PCEPS or
202	   can be preconfigured to use PCEPS for a given peer (see Section 4 fo=
r
203	   more details).  An existing PCEP session cannot be secured via TLS,
204	   the session MUST be closed and re-established with TLS as per the
205	   procedure described in this document.

207	   The StartTLS message is a PCEP message sent by a PCC to a PCE and by
208	   a PCE to a PCC in order to initiate the TLS procedure for PCEP.  The
209	   PCC initiates the use of TLS by sending a StartTLS message.  The PCE
210	   agrees to the use of TLS by responding with its own StartTLS message=
.
211	   If the PCE is configured to only support TLS, it may send the
212	   StartTLS message immediately upon TCP connection establishment;
213	   otherwise it MUST wait for the PCC's first message to see whethe=
r it
214	   is an Open or a StartTLS message.  The TLS negotiation and
215	   establishment procedures are triggered once the PCEP speaker has sen=
t
216	   and received the StartTLS message.  The Message-Type field of the
217	   PCEP common header for the StartTLS message is set to [TBA1 by IANA]=
.

219	   Once the TCP connection has been successfully established, the first
220	   message sent by the PCC to the PCE and by the PCE to the PCC MUST be
221	   a StartTLS message for the PCEPS.  Note that, this is a significant
222	   change from [RFC5440], where the first PCEP message is the Open
223	   message.

225	   A PCEP speaker receiving a StartTLS message, after any other PCEP
226	   exchange has taken place (by receiving or sending any other messages
227	   from either side) MUST treat it as an unexpected message and reply
228	   with a PCErr message with Error-Type set to [TBA2 by IANA] (PCEP
229	   StartTLS failure) and Error-value set to 1 (reception of StartTLS
230	   after any PCEP exchange), and MUST close the TCP connection.

232	   Any message received prior to StartTLS or Open message MUST trigger =
a
233	   protocol error condition causing a PCErr message to be sent with
234	   Error-Type set to [TBA2 by IANA] (PCEP StartTLS failure) and Error-
235	   value set to 2 (reception of a message apart from StartTLS or Open)
236	   and MUST close the TCP connection.

238	   If the PCEP speaker that does not support PCEPS, receives a StartTLS
239	   message, it will behave according to the existing error mechanism
240	   described in section 6.2 of [RFC5440] (in case message is received
241	   prior to an Open message) or section 6.9 of [RFC5440] (for the case
242	   of reception of unknown message).  See Section 5 for more details.

244	   If the PCEP speaker that only supports PCEPS connection (as a local
245	   policy), receives an Open message, it MUST treat it as an unexpected
246	   message and reply with a PCErr message with Error-Type set to 1 (PCE=
P
247	   session establishment failure) and Error-value set to 1 (reception o=
f
248	   an invalid Open message or a non Open message), and MUST close the
249	   TCP connection.

251	   If a PCC supports PCEPS connections as well as allow non-PCEPS
252	   connection (as a local policy), it MUST first try to establish PCEPS=
,
253	   by sending StartTLS message and in case it receives an PCErr message
254	   from the PCE, it MAY retry to establish connection without PCEPS by
255	   sending an Open message.  If a PCE supports PCEPS connections as wel=
l
256	   as allow non-PCEPS connection (as a local policy), it MUST wait to
257	   respond after TCP establishment, based on the message received from
258	   the PCC.  In case of StartTLS message, PCE MUST respond with sending
259	   a StartTLS message and moving to TLS establishment procedures as
260	   described in this document.  In case of Open message, PCE MUST
261	   respond with Open message and move to PCEP session establishment
262	   procedure as per [RFC5440].  If a PCE supports PCEPS connections onl=
y
263	   (as a local policy), it MAY send StartTLS message to PCC without
264	   waiting to receive a StartTLS message from PCC.

266	   If a PCEP speaker that is unwilling or unable to negotiate TLS
267	   receives a StartTLS messages, it MUST return a PCErr message (in
268	   clear) with Error-Type set to [TBA2 by IANA] (PCEP StartTLS failure)
269	   and Error-value set to:

271	   o  3 (Failure, connection without TLS is not possible) if it is not
272	      willing to exchange PCEP messages without the solicited TLS
273	      connection, and it MUST close the TCP session.

275	   o  4 (Failure, connection without TLS is possible) if it is willing
276	      to exchange PCEP messages without the solicited TLS connection,
277	      and it MUST close the TCP session.  The receiver MAY choose to
278	      attempt to re-establish the PCEP session without TLS next.  The
279	      attempt to re-establish the PCEP session without TLS SHOULD be
280	      limited to only once.

282	   If the PCEP speaker supports PCEPS and can establish a TLS connectio=
n
283	   it MUST start the TLS connection negotiation and establishment steps
284	   described in Section 3.4 before the PCEP initialization procedure
285	   (section 4.2.1 of [RFC5440]).

287	   After the exchange of StartTLS messages, if the TLS negotiation fail=
s
288	   for some reason (e.g. the required mechanisms for certificate
289	   revocation checking are not available), both peers SHOULD immediatel=
y
290	   close the connection.

292	   A PCEP speaker that does not support PCEPS sends the Open message
293	   directly, as per [RFC5440].  A PCEP speaker that supports PCEPS, but
294	   has learned in the last exchange the peer's willingness to
295	   reestablish session without TLS, MAY send the Open message directly,
296	   as per [RFC5440].  The attempt to re-establish the PCEP session
297	   without TLS SHOULD be limited to only once.

299	   Given the asymmetric nature of TLS for connection establishment, it
300	   is relevant to identify the roles of each of the PCEP peers in it.
301	   The PCC SHALL act as TLS client, and the PCE SHALL act as TLS server
302	   as per [RFC5246].

304	   As per the recommendation from [RFC7525] to avoid downgrade attacks,
305	   PCEP peers that support PCEPS, SHOULD default to strict TLS
306	   configuration i.e. do not allow non-TLS PCEP sessions to be
307	   established.  PCEPS implementations MAY provide an option to allow
308	   the operator to manually override strict TLS configuration and allow
309	   unsecured connections.  Execution of this override SHOULD trigger a
310	   warning about the security implications of permitting unsecured
311	   connections.

313	3.3.  The StartTLS Message

315	   The StartTLS message is used to initiate the TLS procedure for a
316	   PCEPS session between the PCEP peers.  A PCEP speaker sends the
317	   StartTLS message to request negotiation and establishment of TLS
318	   connection for PCEP.  On receiving a StartTLS message from the PCEP
319	   peer (i.e.  when the PCEP speaker has sent and received StartTLS
320	   message) it is ready to start the negotiation and establishment of
321	   TLS and move to steps described in Section 3.4.

323	   The collision resolution procedures described in [RFC5440] for the
324	   exchange of Open messages MUST be applied by the PCEP peers during
325	   the exchange of StartTLS messages.

327	   The format of a StartTLS message is as follows:

329	      <StartTLS Message>::=3D <Common Header>

331	   The StartTLS message MUST contain only the PCEP common header with
332	   Message-Type field set to [TBA1 by IANA].

334	   Once the TCP connection has been successfully established, the PCEP
335	   speaker MUST start a timer called StartTLSWait timer, after the
336	   expiration of which, if neither StartTLS message has been received,
337	   nor a PCErr/Open message (in case of failure and PCEPS not supported
338	   by the peer, respectively), it MUST send a PCErr message with Error-
339	   Type set to [TBA2 by IANA] and Error-value set to 5 (no StartTLS (no=
r
340	   PCErr/Open) message received before the expiration of the
341	   StartTLSWait timer) and it MUST release the TCP connection . A
342	   RECOMMENDED value for StartTLSWait timer is 60 seconds.  The value o=
f
343	   StartTLSWait timer MUST NOT be less than OpenWait timer.

345	                  +-+-+                 +-+-+
346	                  |PCC|                 |PCE|
347	                  +-+-+                 +-+-+
348	                    |                     |
349	                    | StartTLS            |
350	                    | msg                 |
351	                    |-------              |
352	                    |       \   StartTLS  |
353	                    |        \  msg       |
354	                    |         \  ---------|
355	                    |          \/         |
356	                    |          /\         |
357	                    |         /  -------->|
358	                    |        /            |
359	                    |<------              |
360	                    |:::::::::TLS:::::::::|
361	                    |:::::Establishment:::|
362	                    |                     |
363	                    |                     |
364	                    |:::::::PCEP::::::::::|
365	                    |                     |

367	            Figure 1: Both PCEP Speaker supports PCEPS (strict)
368	                  +-+-+                 +-+-+
369	                  |PCC|                 |PCE|
370	                  +-+-+                 +-+-+
371	                    |                     |
372	                    | StartTLS            |
373	                    | msg                 |
374	                    |-------              |
375	                    |       \   StartTLS  |
376	                    |        \  msg       |
377	                    |         \  ---------|
378	                    |          \/         |
379	                    |          /\         |
380	                    |         /  -------->|
381	                    |        /            |
382	                    |<------              |
383	                    |:::::::::TLS:::::::::| TLS Establishment
384	                    |:::::Establishment:::| Failure, Both
385	                    |                     | peers close
386	                                            session

388	      Figure 2: Both PCEP Speaker supports PCEPS (strict), but cannot
389	                               establish TLS

391	                  +-+-+                 +-+-+
392	                  |PCC|                 |PCE|
393	                  +-+-+                 +-+-+
394	                    |                     |  Does not support
395	                    | StartTLS            |  PCEPS and thus
396	                    | msg                 |  sends Open
397	                    |-------              |
398	                    |       \   Open      |
399	                    |        \  msg       |
400	                    |         \  ---------|
401	                    |          \/         |
402	                    |          /\         |
403	                    |         /  -------->|
404	                    |        /            |
405	                    |<------              |
406	                    |                     |
407	                    |<--------------------| Send Error
408	                    |       PCErr         | Type=3D1,Value=3D1
409	                    |                     | (non-Open message
410	                    |<--------------------|  received)
411	                    |       Close         |
412	                    ///////// TCP /////////
413	                    //////re-establish/////
414	          Send Open | Open                |
415	          this time | msg                 |
416	                    |-------              |
417	                    |       \   Open      |
418	                    |        \  msg       |
419	                    |         \  ---------|
420	                    |          \/         |
421	                    |          /\         |
422	                    |         /  -------->|
423	                    |        /            |
424	                    |<------              |

426	    Figure 3: One PCEP Speaker (PCE) does not support PCEPS, while PCC
427	                    supports both with or without PCEPS

429	                  +-+-+                 +-+-+
430	                  |PCC|                 |PCE|
431	                  +-+-+                 +-+-+
432	                    |                     |
433	                    | StartTLS            |
434	                    | msg                 | PCE waits
435	                    |-------------------->| for PCC and
436	                    |            StartTLS | respond with
437	                    |<--------------------| Start TLS
438	                    |                     |
439	                    |:::::::::TLS:::::::::|
440	                    |:::::Establishment:::|
441	                    |                     |
442	                    |                     |
443	                    |:::::::PCEP::::::::::|
444	                    |                     |

446	    Figure 4: Both PCEP Speaker supports PCEPS as well as without PCEPS

448	                  +-+-+                 +-+-+
449	                  |PCC|                 |PCE|
450	                  +-+-+                 +-+-+
451	                    |                     |
452	                    | StartTLS            |
453	                    | msg                 | PCE waits
454	                    |-------------------->| for PCC
455	                    |               PCErr |
456	                    |<--------------------| Send Error
457	                    |                     | Type=3DTBA2,Value=3D3
458	                    |                     | (Failure, connection
459	                    |<--------------------|  without TLS is not
460	                    |       Close         |  possible)

462	   Figure 5: Both PCEP Speaker supports PCEPS as well as without PCEPS,
463	                   but PCE cannot start TLS negotiation

465	                  +-+-+                 +-+-+
466	                  |PCC|                 |PCE|
467	                  +-+-+                 +-+-+
468	                    |                     |
469	                    | Open                |
470	                    | msg                 | PCE waits
471	                    |-------------------->| for PCC and
472	                    |                Open | respond with
473	                    |<--------------------| Open
474	                    |                     |
475	                    |:::::::PCEP::::::::::|
476	                    |                     |

478	   Figure 6: PCE supports PCEPS as well as without PCEPS, while PCC doe=
s
479	                             not support PCEPS

481	3.4.  TLS Connection Establishment

483	   Once the establishment of TLS has been agreed by the PCEP peers, the
484	   connection establishment SHALL follow the following steps:

486	   1.  Immediately negotiate a TLS session according to [RFC5246].  The
487	       following restrictions apply:

489	       *  Support for TLS v1.2 [RFC5246] or later is REQUIRED.

491	       *  Support for certificate-based mutual authentication is
492	          REQUIRED.

494	       *  Negotiation of a ciphersuite providing for integrity
495	          protection is REQUIRED.

497	       *  Negotiation of a ciphersuite providing for confidentiality is
498	          RECOMMENDED.

500	       *  Support for and negotiation of compression is OPTIONAL.

502	       *  PCEPS implementations MUST, at a minimum, support negotiation
503	          of the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [RFC6460], and
504	          SHOULD support TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as
505	          well.  Implementations SHOULD support the NIST P-256
506	          (secp256r1) curve [RFC4492].  In addition, PCEPS
507	          implementations MUST support negotiation of the mandatory-to-
508	          implement ciphersuites required by the versions of TLS that
509	          they support from TLS 1.3 onwards.

511	   2.  Peer authentication can be performed in any of the following two
512	       REQUIRED operation models:

514	       *  TLS with X.509 certificates using Public-Key Infrastructure
515	          Exchange (PKIX) trust models:

517	          +  Implementations MUST allow the configuration of a list of
518	             trusted Certification Authorities (CAs) for incoming
519	             connections.

521	          +  Certificate validation MUST include the verification rules
522	             as per [RFC5280].

524	          +  PCEPS implementations SHOULD incorporate revocation method=
s
525	             (CRL downloading, OCSP...) according to the trusted CA
526	             policies.

528	          +  Implementations SHOULD indicate their trusted CAs.  For TL=
S
529	             1.2, this is done using [RFC5246], Section 7.4.4,
530	             "certificate_authorities" (server side) and [RFC=
6066],
531	             Section 6 "Trusted CA Indication" (client side).

533	          +  Implementations MUST follow the rules and guidelines for
534	             peer validation as defined in [RFC6125].  If an expected
535	             DNS name or IP address for the peer is configured, then th=
e
536	             implementations MUST check them against the values in the
537	             presented certificate.  The DNS names and the IP addresses
538	             can be contained in the CN-ID [RFC6125] (Common Name
539	             Identifier) or the subjectAltName entries.  For
540	             verification, only one of these entries is considered.  Th=
e
541	             following precedence applies: for DNS name validation, DNS=
-
542	             ID [RFC6125] has precedence over CN-ID; for IP address
543	             validation, subjectAltName:iPAddr has precedence over CN-
544	             ID.

546	          +  Implementations MAY allow the configuration of a set of
547	             additional properties of the certificate to check for a
548	             peer's authorization to communicate (e.g., a set of al=
lowed
549	             values in URI-ID [RFC6125] or a set of allowed X509v3
550	             Certificate Policies).  The definition of these properties
551	             are out of scope of this document.

553	       *  TLS with X.509 certificates using certificate fingerprints:
554	          Implementations MUST allow the configuration of a list of
555	          certificates that are trusted to identify peers, identified
556	          via fingerprint of the Distinguished Encoding Rules (DER)
557	          encoded certificate octets.  Implementations MUST support
558	          SHA-256 as defined by [SHS] as the hash algorithm for the
559	          fingerprint, but a later revision may demand support for a
560	          stronger hash function.

562	   3.  Start exchanging PCEP messages.

564	       *  Once the TLS connection has been successfully established, th=
e
565	          PCEP speaker MUST start the OpenWait timer [RFC5440], after
566	          the expiration of which, if no Open message has been received=
,
567	          it sends a PCErr message and releases the TCP/TLS connection.

569	3.5.  Peer Identity

571	   Depending on the peer authentication method in use, PCEPS supports
572	   different operation modes to establish peer's identity and wheth=
er it
573	   is entitled to perform requests or can be considered authoritative i=
n
574	   its replies.  PCEPS implementations SHOULD provide mechanisms for
575	   associating peer identities with different levels of access and/or
576	   authoritativeness, and they MUST provide a mechanism for establishin=
g
577	   a default level for properly identified peers.  Any connection
578	   established with a peer that cannot be properly identified SHALL be
579	   terminated before any PCEP exchange takes place.

581	   In TLS-X.509 mode using fingerprints, a peer is uniquely identified
582	   by the fingerprint of the presented certificate.

584	   There are numerous trust models in PKIX environments, and it is
585	   beyond the scope of this document to define how a particular
586	   deployment determines whether a peer is trustworthy.  Implementation=
s
587	   that want to support a wide variety of trust models should expose as
588	   many details of the presented certificate to the administrator as
589	   possible so that the trust model can be implemented by the
590	   administrator.  At least the following parameters of the X.509
591	   certificate SHOULD be exposed:

593	   o  Peer's IP address

595	   o  Peer's fully qualified domain name (FQDN)

597	   o  Certificate Fingerprint

599	   o  Issuer

601	   o  Subject

603	   o  All X509v3 Extended Key Usage

605	   o  All X509v3 Subject Alternative Name

607	   o  All X509v3 Certificate Policies
608	   Note that the remote IP address used for the TCP session
609	   establishment is also exposed.

611	   [I-D.ietf-pce-stateful-sync-optimizations] specify a Speaker Entity
612	   Identifier TLV (SPEAKER-ENTITY-ID), as an optional TLV that is
613	   included in the OPEN Object.  It contains a unique identifier for th=
e
614	   node that does not change during the lifetime of the PCEP speaker.
615	   An implementation would thus expose the speaker entity identifier as
616	   part of the X509v3 certificate's subjectAltName:otherName, so th=
at an
617	   implementation could use this identifier for the peer identification
618	   trust model.

620	   In addition, a PCC MAY apply the procedures described in [RFC6698]
621	   DNS-Based Authentication of Named Entities (DANE) to verify its peer
622	   identity when using DNS discovery.  See section Section 4.1 for
623	   further details.

625	3.6.  Connection Establishment Failure

627	   In case the initial TLS negotiation or the peer identity check fails=
,
628	   according to the procedures listed in this document, both peers
629	   SHOULD immediately close the connection.

631	   The initiator SHOULD follow the procedure listed in [RFC5440] to
632	   retry session setup as per the exponential back-off session
633	   establishment retry procedure.

635	4.  Discovery Mechanisms

637	   This document does not specify any discovery mechanism for support o=
f
638	   PCEPS.  Other documents, [I-D.wu-pce-discovery-pceps-support] and
639	   [I-D.wu-pce-dns-pce-discovery] have made proposals:

641	   o  A PCE can advertise its capability to support PCEPS using the
642	      IGP's advertisement mechanism of the PCE discovery informatio=
n.
643	      The PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to advertis=
e
644	      PCE capabilities.  It is present within the PCE Discovery (PCED)
645	      sub-TLV carried by OSPF or IS-IS.  [RFC5088] and [RFC5089] provid=
e
646	      the description and processing rules for this sub-TLV when carrie=
d
647	      within OSPF and IS-IS, respectively.  PCE capability bits are
648	      defined in [RFC5088].  A new capability flag bit for the PCE-CAP-
649	      FLAGS sub-TLV that can be announced as an attribute to distribute
650	      PCEP security support information is proposed in
651	      [I-D.wu-pce-discovery-pceps-support].

653	   o  A PCE can advertise its capability to support PCEPS using the DNS
654	      [I-D.wu-pce-dns-pce-discovery] by identifying the support of TLS.

656	4.1.  DANE Applicability

658	   DANE [RFC6698] defines a secure method to associate the certificate
659	   that is obtained from a TLS server with a domain name using DNS,
660	   i.e., using the TLSA DNS resource record (RR) to associate a TLS
661	   server certificate or public key with the domain name where the
662	   record is found, thus forming a "TLSA certificate association&q=
uot;.  The
663	   DNS information needs to be protected by DNS Security (DNSSEC).  A
664	   PCC willing to apply DANE to verify server identity MUST conform to
665	   the rules defined in section 4 of [RFC6698].  The implementation MUS=
T
666	   support Service certificate constraint (TLSA Certificate Usages type
667	   1) with Matching type 2 (SHA2-256) as described in
668	   [RFC6698][RFC7671].  The server's domain name must be authorized
669	   separately, as TLSA does not provide any useful authorization
670	   guarantees.

672	5.  Backward Compatibility

674	   The procedures described in this document define a security containe=
r
675	   for the transport of PCEP requests and replies carried by a TLS
676	   connection initiated by means of a specific extended message
677	   (StartTLS) that does not interfere with PCEP speaker implementations
678	   not supporting it.

680	   A PCC that does not support PCEPS will send Open message as the firs=
t
681	   message on TCP establishment.  A PCE that supports PCEPS only, will
682	   send StartTLS message on TCP establishment.  On receiving StartTLS
683	   message, PCC would consider it as an error and behave according to
684	   the existing error mechanism of [RFC5440] and send PCErr message wit=
h
685	   Error-Type 1 (PCEP session establishment failure) and Error-Value 1
686	   (reception of an invalid Open message or a non Open message) and
687	   close the session.

689	   A PCC that support PCEPS will send StartTLS message as the first
690	   message on TCP establishment.  A PCE that does not supports PCEPS,
691	   would consider receiving StartTLS message as an error and respond
692	   with PCErr message (with Error-Type 1 and Error-Value 1) and close
693	   the session.

695	   If a StartTLS message is received at any other time by a PCEP speake=
r
696	   that does not implement PCEPS, it would consider it as an unknown
697	   message and would behave according to the existing error mechanism o=
f
698	   [RFC5440] and send PCErr message with Error-Type 2 (Capability not
699	   supported) and close the session.

701	   An existing PCEP session cannot be upgraded to PCEPS, the session
702	   needs to be terminated and reestablished as per the procedure
703	   described in this document.  During the incremental upgrade, the PCE=
P
704	   speaker SHOULD allow session establishment with and without TLS.
705	   Once both PCEP speakers are upgraded to support PCEPS, the PCEP
706	   session is re-established with TLS, otherwise PCEP session without
707	   TLS is setup.  A redundant PCE MAY also be used during the
708	   incremental deployment to take over the PCE undergoing upgrade.  Onc=
e
709	   the upgrade is completed, support for unsecured version SHOULD be
710	   removed.

712	   A PCE that accepts connections with or without PCEPS, it would
713	   respond based on the message received from PCC.  A PCC that supports
714	   connection with or without PCEPS, it would first attempt to connect
715	   with PCEPS and in case of error, it MAY retry to establish connectio=
n
716	   without PCEPS.  For successful TLS operations with PCEP, both PCEP
717	   peers in the network would need to be upgraded to support this
718	   document.

720	   Note that, a PCEP implementation that support PCEPS would respond
721	   with PCErr message with Error-Type set to [TBA2 by IANA] (PCEP
722	   StartTLS failure) and Error-value set to 2 if any other message is
723	   sent before StartTLS or Open.  If the sender of the invalid message
724	   is a PCEP implementation that does not support PCEPS, it will not be
725	   able to understand this error.  A PCEPS implementation could also
726	   send the PCErr message as per [RFC5440] with Error-Type "PCEP s=
ession
727	   establishment failure" and Error-value "reception of an in=
valid Open
728	   message or a non Open message" before closing the session.

730	6.  IANA Considerations

732	6.1.  New PCEP Message

734	   IANA is requested to allocate new message types within the "PCE=
P
735	   Messages" sub-registry of the PCEP Numbers registry, as follows=
:

737	      Value  Description                             Reference
738	       TBA1  The Start TLS Message (StartTLS)        This document

740	6.2.  New Error-Values

742	   IANA is requested to allocate new Error Types and Error Values withi=
n
743	   the " PCEP-ERROR Object Error Types and Values" sub-regist=
ry of the
744	   PCEP Numbers registry, as follows:

746	   Error-
747	   Type    Meaning               Error-value             Reference

749	   TBA2    PCEP StartTLS         0:Unassigned            This document
750	           failure               1:Reception of          This document
751	                                 StartTLS after
752	                                 any PCEP exchange
753	                                 2:Reception of          This document
754	                                 any other message
755	                                 apart from StartTLS,
756	                                 Open or PCErr
757	                                 3:Failure, connection   This document
758	                                 without TLS is not
759	                                 possible
760	                                 4:Failure, connection   This document
761	                                 without TLS is
762	                                 possible
763	                                 5:No StartTLS message   This document
764	                                 (nor PCErr/Open)
765	                                 before StartTLSWait
766	                                 timer expiry

768	7.  Security Considerations

770	   While the application of TLS satisfies the requirement on
771	   confidentiality as well as fine-grained, policy-based peer
772	   authentication, there are security threats that it cannot address.
773	   It may be advisable to apply additional protection measures, in
774	   particular in what relates to attacks specifically addressed to
775	   forging the TCP connection underpinning TLS, especially in the case
776	   of long-lived connections.  One of these measures is the application
777	   of TCP-AO (TCP Authentication Option [RFC5925]), which is fully
778	   compatible with and deemed as complementary to TLS.  The mechanisms
779	   to configure the requirements to use TCP-AO and other lower-layer
780	   protection measures with a particular peer are outside the scope of
781	   this document.

783	   Since computational resources required by TLS handshake and
784	   ciphersuite are higher than unencrypted TCP, clients connecting to a
785	   PCEPS server can more easily create high load conditions and a
786	   malicious client might create a Denial-of-Service attack more easily=
.

788	   Some TLS ciphersuites only provide integrity validation of their
789	   payload, and provide no encryption, such ciphersuites SHOULD NOT be
790	   used by default.  Administrators MAY allow the usage of these
791	   ciphersuites after careful weighting of the risk of relevant interna=
l
792	   data leakage, that can occur in such a case, as explicitly stated by
793	   [RFC6952].

795	   When using certificate fingerprints to identify PCEPS peers, any two
796	   certificates that produce the same hash value will be considered the
797	   same peer.  Therefore, it is important to make sure that the hash
798	   function used is cryptographically uncompromised, so that attackers
799	   are very unlikely to be able to produce a hash collision with a
800	   certificate of their choice.  This document mandates support for
801	   SHA-256 as defined by [SHS], but a later revision may demand support
802	   for stronger functions if suitable attacks on it are known.

804	   PCEPS implementations that continue to accept connections without TL=
S
805	   are susceptible to downgrade attacks as described in [RFC7457].  An
806	   attacker could attempt to remove the use of StartTLS message that
807	   request the use of TLS as it pass on the wire in clear, and further
808	   inject a PCErr message that suggest to attempt PCEP connection
809	   without TLS.

811	   The guidance given in [RFC7525] SHOULD be followed to avoid attacks
812	   on TLS.

814	8.  Manageability Considerations

816	   All manageability requirements and considerations listed in [RFC5440=
]
817	   apply to PCEP protocol extensions defined in this document.  In
818	   addition, requirements and considerations listed in this section
819	   apply.

821	8.1.  Control of Function and Policy

823	   A PCE or PCC implementation SHOULD allow configuring the PCEP
824	   security via TLS capabilities as described in this document.

826	   A PCE or PCC implementation supporting PCEP security via TLS MUST
827	   support general TLS configuration as per [RFC5246].  At least the
828	   configuration of one of the trust models and its corresponding
829	   parameters, as described in Section 3.4 and Section 3.5, MUST be
830	   supported by the implementation.

832	   A PCEP implementation SHOULD allow configuring the StartTLSWait time=
r
833	   value.

835	   PCEPS implementations MAY provide an option to allow the operator to
836	   manually override strict TLS configuration and allow unsecure
837	   connections.  Execution of this override SHOULD trigger a warning
838	   about the security implications of permitting unsecure connections.

840	   Further, the operator needs to develop suitable security policies
841	   around PCEP within his network.  The PCEP peers SHOULD provide ways
842	   for the operator to complete the following tasks in regards to a PCE=
P
843	   session:

845	   o  Determine if a session is protected via PCEPS.

847	   o  Determine the version of TLS, the mechanism used for
848	      authentication, and the ciphersuite in use.

850	   o  Determine if the certificate could not be verified, and the reaso=
n
851	      for this circumstance.

853	   o  Inspect the certificate offered by the PCEP peer.

855	   o  Be warned if StartTLS procedure fails for the PCEP peers, that ar=
e
856	      known to support PCEPS via configurations or capability
857	      advertisements.

859	8.2.  Information and Data Models

861	   The PCEP MIB module is defined in [RFC7420].  The MIB module could b=
e
862	   extended to include the ability to view the PCEPS capability, TLS
863	   related information as well as TLS status for each PCEP peer.

865	   Further, to allow the operator to configure the PCEPS capability and
866	   various TLS related parameters as well as to view the current TLS
867	   status for a PCEP session, the PCEP YANG module
868	   [I-D.ietf-pce-pcep-yang] is extended to include TLS related
869	   information.

871	8.3.  Liveness Detection and Monitoring

873	   Mechanisms defined in this document do not imply any new liveness
874	   detection and monitoring requirements in addition to those already
875	   listed in [RFC5440] and [RFC5246].

877	8.4.  Verifying Correct Operations

879	   A PCEPS implementation SHOULD log error events and provide PCEPS
880	   failure statistics with reasons.

882	8.5.  Requirements on Other Protocols

884	   Mechanisms defined in this document do not imply any new requirement=
s
885	   on other protocols.  Note that, Section 4 list possible discovery
886	   mechanism for support of PCEPS.

888	8.6.  Impact on Network Operation

890	   Mechanisms defined in this document do not have any significant
891	   impact on network operations in addition to those already listed in
892	   [RFC5440], and the policy and management implications discussed
893	   above.

895	9.  Acknowledgements

897	   This specification relies on the analysis and profiling of TLS
898	   included in [RFC6614] and the procedures described for the STARTTLS
899	   command in [RFC4513].

901	   We would like to thank Joe Touch for his suggestions and support
902	   regarding the StartTLS mechanisms.

904	   Thanks to Daniel King for reminding the authors about manageability
905	   considerations.

907	   Thanks to Cyril Margaria for shepherding this document.

909	   Thanks to David Mandelberg for early SECDIR review comments as well
910	   as re-reviewing during IETF last call.

912	   Thanks to Dan Frost for the RTGDIR review and comments.

914	   Thanks to Dale Worley for the Gen-ART review and comments.

916	   Also thanks to Tianran Zhou for OPSDIR review.

918	   Thanks to Deborah Brungard for being the responsible AD and guiding
919	   the authors as needed.

921	   Thanks to Mirja Kuhlewind, Eric Rescorla, Warren Kumari, Kathleen
922	   Moriarty, Suresh Krishnan, Ben Campbell and Alexey Melnikov for the
923	   IESG review and comments.

925	10.  References

927	10.1.  Normative References

929	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
930	              Requirement Levels", BCP 14, RFC 2119,
931	              DOI 10.17487/RFC2119, March 1997,
932	              <h=
ttps://www.rfc-editor.org/info/rfc2119>.

934	   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Sec=
urity
935	              (TLS) Protocol Version 1.2", RFC 5246,
936	              DOI 10.17487/RFC5246, August 2008,
937	              <h=
ttps://www.rfc-editor.org/info/rfc5246>.

939	   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
940	              Housley, R., and W. Polk, "Internet X.509 Public Key
941	              Infrastructure Certificate and Certificate Revocation Lis=
t
942	              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May =
2008,
943	              <h=
ttps://www.rfc-editor.org/info/rfc5280>.

945	   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Comput=
ation
946	              Element (PCE) Communication Protocol (PCEP)", RFC 54=
40,
947	              DOI 10.17487/RFC5440, March 2009,
948	              <h=
ttps://www.rfc-editor.org/info/rfc5440>.

950	   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
951	              Extensions: Extension Definitions", RFC 6066,
952	              DOI 10.17487/RFC6066, January 2011,
953	              <h=
ttps://www.rfc-editor.org/info/rfc6066>.

955	   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
956	              Verification of Domain-Based Application Service Identity
957	              within Internet Public Key Infrastructure Using X.509
958	              (PKIX) Certificates in the Context of Transport Layer
959	              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, Mar=
ch
960	              2011, <https://www.rfc-editor.org/info/rfc6125>.

962	   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authenti=
cation
963	              of Named Entities (DANE) Transport Layer Security (TLS)
964	              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, Aug=
ust
965	              2012, <https://www.rfc-editor.org/info/rfc6698>.

967	   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
968	              "Recommendations for Secure Use of Transport Layer
969	              Security (TLS) and Datagram Transport Layer Security
970	              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, Ma=
y
971	              2015, <https://www.rfc-editor.org/info/rfc7525>.

973	   [RFC7671]  Dukhovni, V. and W. Hardaker, "The DNS-Based
974	              Authentication of Named Entities (DANE) Protocol: Updates
975	              and Operational Guidance", RFC 7671, DOI 10.17487/RF=
C7671,
976	              October 2015, <https://www.rfc-editor.org/info/rfc7671>.

978	   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in R=
FC
979	              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8=
174,
980	              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

982	   [SHS]      National Institute of Standards and Technology, "Sec=
ure
983	              Hash Standard (SHS), FIPS PUB 180-4",
984	              DOI 10.6028/NIST.FIPS.180-4, August 2015,
985	              <ht=
tp://nvlpubs.nist.gov/nistpubs/FIPS/
986	              NIST.FIPS.180-4.pdf>.

988	10.2.  Informative References

990	   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B=
.
991	              Moeller, "Elliptic Curve Cryptography (ECC) Cipher S=
uites
992	              for Transport Layer Security (TLS)", RFC 4492,
993	              DOI 10.17487/RFC4492, May 2006,
994	              <h=
ttps://www.rfc-editor.org/info/rfc4492>.

996	   [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Pro=
tocol
997	              (LDAP): Authentication Methods and Security Mechanisms&qu=
ot;,
998	              RFC 4513, DOI 10.17487/RFC4513, June 2006,
999	              <h=
ttps://www.rfc-editor.org/info/rfc4513>.

1001	   [RFC5088]  Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R=
.
1002	              Zhang, "OSPF Protocol Extensions for Path Computati=
on
1003	              Element (PCE) Discovery", RFC 5088, DOI 10.17487/RF=
C5088,
1004	              January 2008, <https://www.rfc-editor.org/info/rfc5088>.

1006	   [RFC5089]  Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R=
.
1007	              Zhang, "IS-IS Protocol Extensions for Path Computat=
ion
1008	              Element (PCE) Discovery", RFC 5089, DOI 10.17487/RF=
C5089,
1009	              January 2008, <https://www.rfc-editor.org/info/rfc5089>.

1011	   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
1012	              Authentication Option", RFC 5925, DOI 10.17487/RFC5=
925,
1013	              June 2010, <https://www.rfc-editor.org/info/rfc5925>.

1015	   [RFC6460]  Salter, M. and R. Housley, "Suite B Profile for Tra=
nsport
1016	              Layer Security (TLS)", RFC 6460, DOI 10.17487/RFC64=
60,
1017	              January 2012, <https://www.rfc-editor.org/info/rfc6460>.

1019	   [RFC6614]  Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
1020	              "Transport Layer Security (TLS) Encryption for RADI=
US",
1021	              RFC 6614, DOI 10.17487/RFC6614, May 2012,
1022	              <=
https://www.rfc-editor.org/info/rfc6614>.

1024	   [RFC6952]  Jethanandani, M., Patel, K., and L. Zheng, "Analysi=
s of
1025	              BGP, LDP, PCEP, and MSDP Issues According to the Keying
1026	              and Authentication for Routing Protocols (KARP) Design
1027	              Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
1028	              <=
https://www.rfc-editor.org/info/rfc6952>.

1030	   [RFC7420]  Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
1031	              Hardwick, "Path Computation Element Communication P=
rotocol
1032	              (PCEP) Management Information Base (MIB) Module",
1033	              RFC 7420, DOI 10.17487/RFC7420, December 2014,
1034	              <=
https://www.rfc-editor.org/info/rfc7420>.

1036	   [RFC7457]  Sheffer, Y., Holz, R., and P. Saint-Andre, "Summari=
zing
1037	              Known Attacks on Transport Layer Security (TLS) and
1038	              Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC745=
7,
1039	              February 2015, <https://www.rfc-editor.org/info/rfc7457>.

1041	   [I-D.ietf-pce-stateful-sync-optimizations]
1042	              Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
1043	              and D. Dhody, "Optimizations of Label Switched Path=
 State
1044	              Synchronization Procedures for a Stateful PCE", dra=
ft-
1045	              ietf-pce-stateful-sync-optimizations-10 (work in
1046	              progress), March 2017.

1048	   [I-D.ietf-pce-pcep-yang]
1049	              Dhody, D., Hardwick, J., Beeram, V., and j.
1050	              jefftant@gmail.com=
, "A YANG Data Model for Path
1051	              Computation Element Communications Protocol (PCEP)"=
,
1052	              draft-ietf-pce-pcep-yang-05 (work in progress), June 201=
7.

1054	   [I-D.wu-pce-dns-pce-discovery]
1055	              Wu, Q., Dhody, D., King, D., Lopez, D., and J. Tantsura,
1056	              "Path Computation Element (PCE) Discovery using Dom=
ain
1057	              Name System(DNS)", draft-wu-pce-dns-pce-discovery-1=
0 (work
1058	              in progress), March 2017.

1060	   [I-D.wu-pce-discovery-pceps-support]
1061	              Lopez, D., Wu, Q., Dhody, D., and D. King, "IGP ext=
ension
1062	              for PCEP security capability support in the PCE
1063	              discovery", draft-wu-pce-discovery-pceps-support-07=
 (work
1064	              in progress), March 2017.

1066	Authors' Addresses

1068	   Diego R. Lopez
1069	   Telefonica I+D
1070	   Don Ramon de la Cruz, 82
1071	   Madrid  28006
1072	   Spain

1074	   Phone: +34 913 129 041
1075	   EMail: diego.r.lope=
z@telefonica.com
1076	   Oscar Gonzalez de Dios
1077	   Telefonica I+D
1078	   Don Ramon de la Cruz, 82
1079	   Madrid  28006
1080	   Spain

1082	   Phone: +34 913 129 041
1083	   EMail: oscar=
.gonzalezdedios@telefonica.com

1085	   Qin Wu
1086	   Huawei
1087	   101 Software Avenue, Yuhua District
1088	   Nanjing, Jiangsu  210012
1089	   China

1091	   EMail: sunseawq@huawei.com

1093	   Dhruv Dhody
1094	   Huawei
1095	   Divyashree Techno Park, Whitefield
1096	   Bangalore, KA  560066
1097	   India

1099	   EMail: dhruv.ietf@gmail.com=

On Mon, Sep 4, 2017 at 8:31 PM, Henrik Levkowetz <henrik@levkowetz.com= > wrote:

Hi,

This is an automatic notification about a new xml2rfc release,
v2.8.0, generated when running the mkrelease script.

Release notes:

xml2rfc (2.8.0) ietf; urgency=3Dlow
=C2=A0 This is a small feature release which changes URLs in boilerplate to=
=C2=A0 use https: instead of http:.=C2=A0 There are also some bugfixes.
=C2=A0 * Include notes when doing index processing.=C2=A0 Fixes issue #335.=
=C2=A0 * Include erefs with text equal to the URL in the URIs section.=C2= =A0 See
=C2=A0 =C2=A0 issue #334.
=C2=A0 * Changed the use of http: to https: in many places.=C2=A0 In the ge= neration
=C2=A0 =C2=A0 of RFCs, the code uses a switchover date of August 21, 2017 w= hen deciding
=C2=A0 =C2=A0 whether to insert http: or https: URLs.=C2=A0 In practice, th= is means that RFCs
=C2=A0 =C2=A0 with a date of September 2017 or later will get https:.=C2=A0= Also fixed URL
=C2=A0 =C2=A0 line-breaking prevention to apply to https: URLS.=C2=A0 Fixes= issue #333.
=C2=A0 * In urlkeep(), prevent breaking also for https:, not only http: URL= s

The new version is available through SVN checkout, with
=C2=A0 'svn checkout http://svn.tools.= ietf.org/svn/tools/xml2rfc/tags/cli/2.8.0'

Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (via the mkrelease script)

_______________________________________________
xml2rfc mailing list
xml2rfc@ietf.org
https://www.ietf.org/mailman/listinfo/xml2rfc<= br>

--94eb2c043d0c497447055861bcfa-- From nobody Mon Sep 4 13:26:42 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA4312EC30; Mon, 4 Sep 2017 13:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 O51ZQOGkqtpJ; Mon, 4 Sep 2017 13:26:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD026128D0F; Mon, 4 Sep 2017 13:26:10 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:64734 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1doxwc-0002Nb-G9; Mon, 04 Sep 2017 13:26:10 -0700 To: Dhruv Dhody References: Cc: xml2rfc@ietf.org, rfc-markdown@ietf.org, codesprints@ietf.org From: Henrik Levkowetz Message-ID: Date: Mon, 4 Sep 2017 22:25:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sa0HblPh5IIixmnm2f6edWaE0rTq0AT6B" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: codesprints@ietf.org, rfc-markdown@ietf.org, xml2rfc@ietf.org, dhruv.ietf@gmail.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] New xml2rfc release: v2.8.0 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 20:26:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sa0HblPh5IIixmnm2f6edWaE0rTq0AT6B Content-Type: multipart/mixed; boundary="DDgGFIVWIP295RsX47gLiNT5qn8VpAq2H"; protected-headers="v1" From: Henrik Levkowetz To: Dhruv Dhody Cc: xml2rfc@ietf.org, rfc-markdown@ietf.org, codesprints@ietf.org Message-ID: Subject: Re: [xml2rfc] New xml2rfc release: v2.8.0 References: In-Reply-To: --DDgGFIVWIP295RsX47gLiNT5qn8VpAq2H Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Dhruv, On 2017-09-04 21:01, Dhruv Dhody wrote: > Hi, >=20 > Because of this change idnits is failing and submission for draft is > getting blocked. > I am going to make manual change now, idnits output below for your > reference - Oops. Right. Preparing to release a new idnits now. Thanks, and best regards, Henrik > Thanks! >=20 > Dhruv >=20 > idnits 2.14.01 /var/www/.idnits >=20 >=20 > tmp/draft-ietf-pce-pceps-17.txt: >=20 > Checking boilerplate required by RFC 5378 and the IETF Trust (see > http://trustee.ietf.org/license-info): > ---------------------------------------------------------------------= ------- >=20 > ** The document seems to lack a License Notice according IETF Trust > Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2= 009 > Section 6.b -- however, there's a paragraph with a matching beginn= ing. > Boilerplate error? >=20 > IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragr= aph 3: > This document is subject to BCP 78 and the IETF Trust's Legal P= rovisions > Relating to IETF Documents (http://trustee.ietf.org/license-inf= o) > in effect on the date of publication of this document. Please > review these documents carefully, as they describe your rights > and restrictions with respect to this document. Code Component= s > extracted from this document must include Simplified BSD Licens= e > text as described in Section 4.e of the Trust Legal Provisions > and are provided without warranty as described in the Simplifie= d > BSD License. >=20 > ... text found in draft: > This document is subject to BCP 78 and the IETF Trust's Legal P= rovisions > Relating to IETF Documents > ..................................^ > (https://trustee.ietf.org/license-info) in effect on the date o= f > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with > respect to this document. Code Components extracted from this > document must include Simplified BSD License text as described = in > Section 4.e of the Trust Legal Provisions and are provided > without warranty as described in the Simplified BSD License. >=20 >=20 >=20 > Checking nits according to http://www.ietf.org/id-info/1id-guidelines= =2Etxt: > ---------------------------------------------------------------------= ------- >=20 > ** The document seems to lack a 1id_guidelines paragraph about > Internet-Drafts being working documents -- however, there's a para= graph > with a matching beginning. Boilerplate error? >=20 > 1id_guidelines, paragraph 1: > Internet-Drafts are working documents of the Internet Engineeri= ng Task > Force (IETF), its areas, and its working groups. Note that oth= er > groups may also distribute working documents as Internet-Drafts= =2E >=20 > ... text found in draft: > Internet-Drafts are working documents of the Internet Engineeri= ng Task > Force (IETF). Note that other groups may also distribute worki= ng > ....................^ > documents as Internet-Drafts. The list of current > Internet-Drafts is at > https://datatracker.ietf.org/drafts/current/. >=20 >=20 > ** The document seems to lack a 1id_guidelines paragraph about the li= st of > current Internet-Drafts. >=20 > 1id_guidelines, paragraph 3: > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/1id-abstracts.html >=20 > ** The document seems to lack a 1id_guidelines paragraph about the li= st of > Shadow Directories. >=20 > 1id_guidelines, paragraph 4: > The list of Internet-Draft Shadow Directories can be accessed a= t > http://www.ietf.org/shadow.html >=20 >=20 > Checking nits according to http://www.ietf.org/id-info/checklist : > ---------------------------------------------------------------------= ------- >=20 > No issues found here. >=20 > Miscellaneous warnings: > ---------------------------------------------------------------------= ------- >=20 > =3D=3D The document seems to lack the recommended RFC 2119 boilerplat= e, even if > it appears to use RFC 2119 keywords -- however, there's a paragrap= h with > a matching beginning. Boilerplate error? >=20 > RFC 2119, paragraph 2: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL N= OT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in= > this document are to be interpreted as described in RFC 2119. >=20 > ... text found in draft: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL N= OT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY"= , > ................................................^ > and "OPTIONAL" in this document are to be interpreted as > described in BCP 14 [RFC2119] [RFC8174] when, and only when, th= ey > appear in all capitals, as shown here. >=20 >=20 > (The document does seem to have the reference to RFC 2119 which th= e > ID-Checklist requires). > (Using the creation date from RFC5440, updated by this document, f= or > RFC5378 checks: 2007-11-16) >=20 > -- The document seems to contain a disclaimer for pre-RFC5378 work, a= nd may > have content which was first submitted before 10 November 2008. T= he > disclaimer is necessary when there are original authors that you h= ave > been unable to contact, or if some do not wish to grant the BCP78 = rights > to the IETF Trust. If you are able to get all authors (current an= d > original) to grant those rights, you can and should remove the > disclaimer; otherwise, the disclaimer is needed and you can ignore= this > comment. (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.) >=20 >=20 > Checking references for intended status: Proposed Standard > ---------------------------------------------------------------------= ------- >=20 > (See RFCs 3967 and 4897 for information about using normative refe= rences > to lower-maturity documents in RFCs) >=20 > -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' >=20 >=20 > Summary: 4 errors (**), 0 flaws (~~), 1 warning (=3D=3D), 2 commen= ts (--). >=20 > -----------------------------------------------------------------------= --------- >=20 >=20 > 2 PCE Working Group D. Lo= pez > 3 Internet-Draft O. Gonzalez de D= ios > 4 Updates: 5440 (if approved) Telefonica = I+D > 5 Intended status: Standards Track Q.= Wu > 6 Expires: March 8, 2018 D. Dh= ody > 7 Hua= wei > 8 September 4, 2= 017 >=20 > 10 Secure Transport for PCEP > 11 draft-ietf-pce-pceps-17 >=20 > 13 Abstract >=20 > 15 The Path Computation Element Communication Protocol (PCEP) define= s > 16 the mechanisms for the communication between a Path Computation > 17 Client (PCC) and a Path Computation Element (PCE), or among PCEs.= > 18 This document describes the usage of Transport Layer Security (TL= S) > 19 to enhance PCEP security, hence the PCEPS acronym proposed for it= =2E > 20 The additional security mechanisms are provided by the transport > 21 protocol supporting PCEP, and therefore they do not affect the > 22 flexibility and extensibility of PCEP. >=20 > 24 This document updates RFC 5440 in regards to the PCEP initializat= ion > 25 phase procedures. >=20 > 27 Status of This Memo >=20 > 29 This Internet-Draft is submitted in full conformance with the > 30 provisions of BCP 78 and BCP 79. >=20 > 32 Internet-Drafts are working documents of the Internet Engineering= > 33 Task Force (IETF). Note that other groups may also distribute > 34 working documents as Internet-Drafts. The list of current Intern= et- > 35 Drafts is at https://datatracker.ietf.org/drafts/current/. >=20 > 37 Internet-Drafts are draft documents valid for a maximum of six mo= nths > 38 and may be updated, replaced, or obsoleted by other documents at = any > 39 time. It is inappropriate to use Internet-Drafts as reference > 40 material or to cite them other than as "work in progress." >=20 > 42 This Internet-Draft will expire on March 8, 2018. >=20 > 44 Copyright Notice >=20 > 46 Copyright (c) 2017 IETF Trust and the persons identified as the > 47 document authors. All rights reserved. >=20 > 49 This document is subject to BCP 78 and the IETF Trust's Legal > 50 Provisions Relating to IETF Documents > 51 (https://trustee.ietf.org/license-info) in effect on the date of > 52 publication of this document. Please review these documents > 53 carefully, as they describe your rights and restrictions with res= pect > 54 to this document. Code Components extracted from this document m= ust > 55 include Simplified BSD License text as described in Section 4.e o= f > 56 the Trust Legal Provisions and are provided without warranty as > 57 described in the Simplified BSD License. >=20 > 59 This document may contain material from IETF Documents or IETF > 60 Contributions published or made publicly available before Novembe= r > 61 10, 2008. The person(s) controlling the copyright in some of thi= s > 62 material may not have granted the IETF Trust the right to allow > 63 modifications of such material outside the IETF Standards Process= =2E > 64 Without obtaining an adequate license from the person(s) controll= ing > 65 the copyright in such materials, this document may not be modifie= d > 66 outside the IETF Standards Process, and derivative works of it ma= y > 67 not be created outside the IETF Standards Process, except to form= at > 68 it for publication as an RFC or to translate it into languages ot= her > 69 than English. >=20 > 71 Table of Contents >=20 > 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .= 3 > 74 2. Requirements Language . . . . . . . . . . . . . . . . . . . .= 4 > 75 3. Applying PCEPS . . . . . . . . . . . . . . . . . . . . . . .= 4 > 76 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . .= 4 > 77 3.2. Initiating the TLS Procedures . . . . . . . . . . . . . .= 4 > 78 3.3. The StartTLS Message . . . . . . . . . . . . . . . . . .= 7 > 79 3.4. TLS Connection Establishment . . . . . . . . . . . . . .= 12 > 80 3.5. Peer Identity . . . . . . . . . . . . . . . . . . . . . .= 14 > 81 3.6. Connection Establishment Failure . . . . . . . . . . . .= 15 > 82 4. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . .= 15 > 83 4.1. DANE Applicability . . . . . . . . . . . . . . . . . . .= 16 > 84 5. Backward Compatibility . . . . . . . . . . . . . . . . . . .= 16 > 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .= 17 > 86 6.1. New PCEP Message . . . . . . . . . . . . . . . . . . . .= 17 > 87 6.2. New Error-Values . . . . . . . . . . . . . . . . . . . .= 17 > 88 7. Security Considerations . . . . . . . . . . . . . . . . . . .= 18 > 89 8. Manageability Considerations . . . . . . . . . . . . . . . .= 19 > 90 8.1. Control of Function and Policy . . . . . . . . . . . . .= 19 > 91 8.2. Information and Data Models . . . . . . . . . . . . . . .= 20 > 92 8.3. Liveness Detection and Monitoring . . . . . . . . . . . .= 20 > 93 8.4. Verifying Correct Operations . . . . . . . . . . . . . .= 20 > 94 8.5. Requirements on Other Protocols . . . . . . . . . . . . .= 20 > 95 8.6. Impact on Network Operation . . . . . . . . . . . . . . .= 21 > 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .= 21 > 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . .= 21 > 98 10.1. Normative References . . . . . . . . . . . . . . . . . .= 21 > 99 10.2. Informative References . . . . . . . . . . . . . . . . .= 23 > 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . = =2E 24 >=20 > 102 1. Introduction >=20 > 104 The Path Computation Element Communication Protocol (PCEP) [RFC5= 440] > 105 defines the mechanisms for the communication between a Path > 106 Computation Client (PCC) and a Path Computation Element (PCE), o= r > 107 between two PCEs. These interactions include requests and repli= es > 108 that can be critical for a sustainable network operation and ade= quate > 109 resource allocation, and therefore appropriate security becomes = a key > 110 element in the PCE infrastructure. As the applications of the P= CE > 111 framework evolves, and more complex service patterns emerge, the= > 112 definition of a secure mode of operation becomes more relevant. >=20 > 114 [RFC5440] analyzes in its section on security considerations the= > 115 potential threats to PCEP and their consequences, and discusses > 116 several mechanisms for protecting PCEP against security attacks,= > 117 without making a specific recommendation on a particular one or > 118 defining their application in depth. Moreover, [RFC6952] remark= s the > 119 importance of ensuring PCEP communication confidentiality, espec= ially > 120 when PCEP communication endpoints do not reside in the same > 121 Autonomous System (AS), as the interception of PCEP messages cou= ld > 122 leak sensitive information related to computed paths and resourc= es. >=20 > 124 Among the possible solutions mentioned in these documents, Trans= port > 125 Layer Security (TLS) [RFC5246] provides support for peer > 126 authentication, message encryption and integrity. TLS provides = well- > 127 known mechanisms to support key configuration and exchange, as w= ell > 128 as means to perform security checks on the results of PCE discov= ery > 129 procedures via Interior Gateway Protocol (IGP) ([RFC5088] and > 130 [RFC5089]). >=20 > 132 This document describes a security container for the transport o= f > 133 PCEP messages, and therefore it does not affect the flexibility = and > 134 extensibility of PCEP. >=20 > 136 This document describes how to apply TLS to secure interactions = with > 137 PCE, including initiation of the TLS procedures, the TLS handsha= ke > 138 mechanism, the TLS methods for peer authentication, the applicab= le > 139 TLS ciphersuites for data exchange, and the handling of errors i= n the > 140 security checks. In the rest of the document we will refer to t= his > 141 usage of TLS to provide a secure transport for PCEP as "PCEPS". >=20 > 143 Within this document, PCEP communications are described through = PCC- > 144 PCE relationship. The PCE architecture also supports the PCE-PC= E > 145 communication, this is achieved by requesting PCE fill the role = of a > 146 PCC, as usual. Thus, in this document, the PCC refers to a PCC = or a > 147 PCE initiating the PCEP session and acting as a client. >=20 > 149 2. Requirements Language >=20 > 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NO= T", > 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",= and > 153 "OPTIONAL" in this document are to be interpreted as described i= n BCP > 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all > 155 capitals, as shown here. >=20 > 157 3. Applying PCEPS >=20 > 159 3.1. Overview >=20 > 161 The steps involved in establishing a PCEPS session are as follow= s: >=20 > 163 1. Establishment of a TCP connection. >=20 > 165 2. Initiating the TLS procedures by the StartTLS message from P= CE to > 166 PCC and from PCC to PCE. >=20 > 168 3. Negotiation and establishment of TLS connection. >=20 > 170 4. Start exchanging PCEP messages as per [RFC5440]. >=20 > 172 This document uses the standard StartTLS procedure in PCEP, inst= ead > 173 of using a different port for the secured session. This is done= to > 174 avoid requesting allocation of another port number for the PCEPS= =2E > 175 The StartTLS procedure makes more efficient use of scarce port > 176 numbers and allow simpler configuration of PCEP. >=20 > 178 Implementations SHOULD follow the best practices and recommendat= ions > 179 for using TLS, as per [RFC7525]. >=20 > 181 It should be noted that this procedure updates what is defined i= n > 182 section 4.2.1 and section 6.7 of [RFC5440] regarding the > 183 initialization phase and the processing of messages prior to the= Open > 184 message. The details of processing, including backward > 185 compatibility, are discussed in the following sections. >=20 > 187 3.2. Initiating the TLS Procedures >=20 > 189 Since PCEP can operate either with or without TLS, it is necessa= ry > 190 for a PCEP speaker to indicate whether it wants to set up a TLS > 191 connection or not. For this purpose, this document specifies a = new > 192 PCEP message called StartTLS. Thus, the PCEP session is secured= via > 193 TLS from the start before exchange of any other PCEP message (th= at > 194 includes the Open message). This document thus updates [RFC5440= ], > 195 which required the Open message to be the first PCEP message tha= t is > 196 exchanged. In the case of a PCEP session using TLS, the StartTL= S > 197 message will be sent first. Also a PCEP speaker that supports P= CEPS > 198 MUST NOT start the OpenWait timer after the TCP establishment, > 199 instead it starts a StartTLSWait timer as described in Section 3= =2E3. >=20 > 201 The PCEP speaker MAY discover that the PCEP peer supports PCEPS = or > 202 can be preconfigured to use PCEPS for a given peer (see Section = 4 for > 203 more details). An existing PCEP session cannot be secured via T= LS, > 204 the session MUST be closed and re-established with TLS as per th= e > 205 procedure described in this document. >=20 > 207 The StartTLS message is a PCEP message sent by a PCC to a PCE an= d by > 208 a PCE to a PCC in order to initiate the TLS procedure for PCEP. = The > 209 PCC initiates the use of TLS by sending a StartTLS message. The= PCE > 210 agrees to the use of TLS by responding with its own StartTLS mes= sage. > 211 If the PCE is configured to only support TLS, it may send the > 212 StartTLS message immediately upon TCP connection establishment; > 213 otherwise it MUST wait for the PCC's first message to see whethe= r it > 214 is an Open or a StartTLS message. The TLS negotiation and > 215 establishment procedures are triggered once the PCEP speaker has= sent > 216 and received the StartTLS message. The Message-Type field of th= e > 217 PCEP common header for the StartTLS message is set to [TBA1 by I= ANA]. >=20 > 219 Once the TCP connection has been successfully established, the f= irst > 220 message sent by the PCC to the PCE and by the PCE to the PCC MUS= T be > 221 a StartTLS message for the PCEPS. Note that, this is a signific= ant > 222 change from [RFC5440], where the first PCEP message is the Open > 223 message. >=20 > 225 A PCEP speaker receiving a StartTLS message, after any other PCE= P > 226 exchange has taken place (by receiving or sending any other mess= ages > 227 from either side) MUST treat it as an unexpected message and rep= ly > 228 with a PCErr message with Error-Type set to [TBA2 by IANA] (PCEP= > 229 StartTLS failure) and Error-value set to 1 (reception of StartTL= S > 230 after any PCEP exchange), and MUST close the TCP connection. >=20 > 232 Any message received prior to StartTLS or Open message MUST trig= ger a > 233 protocol error condition causing a PCErr message to be sent with= > 234 Error-Type set to [TBA2 by IANA] (PCEP StartTLS failure) and Err= or- > 235 value set to 2 (reception of a message apart from StartTLS or Op= en) > 236 and MUST close the TCP connection. >=20 > 238 If the PCEP speaker that does not support PCEPS, receives a Star= tTLS > 239 message, it will behave according to the existing error mechanis= m > 240 described in section 6.2 of [RFC5440] (in case message is receiv= ed > 241 prior to an Open message) or section 6.9 of [RFC5440] (for the c= ase > 242 of reception of unknown message). See Section 5 for more detail= s. >=20 > 244 If the PCEP speaker that only supports PCEPS connection (as a lo= cal > 245 policy), receives an Open message, it MUST treat it as an unexpe= cted > 246 message and reply with a PCErr message with Error-Type set to 1 = (PCEP > 247 session establishment failure) and Error-value set to 1 (recepti= on of > 248 an invalid Open message or a non Open message), and MUST close t= he > 249 TCP connection. >=20 > 251 If a PCC supports PCEPS connections as well as allow non-PCEPS > 252 connection (as a local policy), it MUST first try to establish P= CEPS, > 253 by sending StartTLS message and in case it receives an PCErr mes= sage > 254 from the PCE, it MAY retry to establish connection without PCEPS= by > 255 sending an Open message. If a PCE supports PCEPS connections as= well > 256 as allow non-PCEPS connection (as a local policy), it MUST wait = to > 257 respond after TCP establishment, based on the message received f= rom > 258 the PCC. In case of StartTLS message, PCE MUST respond with sen= ding > 259 a StartTLS message and moving to TLS establishment procedures as= > 260 described in this document. In case of Open message, PCE MUST > 261 respond with Open message and move to PCEP session establishment= > 262 procedure as per [RFC5440]. If a PCE supports PCEPS connections= only > 263 (as a local policy), it MAY send StartTLS message to PCC without= > 264 waiting to receive a StartTLS message from PCC. >=20 > 266 If a PCEP speaker that is unwilling or unable to negotiate TLS > 267 receives a StartTLS messages, it MUST return a PCErr message (in= > 268 clear) with Error-Type set to [TBA2 by IANA] (PCEP StartTLS fail= ure) > 269 and Error-value set to: >=20 > 271 o 3 (Failure, connection without TLS is not possible) if it is = not > 272 willing to exchange PCEP messages without the solicited TLS > 273 connection, and it MUST close the TCP session. >=20 > 275 o 4 (Failure, connection without TLS is possible) if it is will= ing > 276 to exchange PCEP messages without the solicited TLS connectio= n, > 277 and it MUST close the TCP session. The receiver MAY choose t= o > 278 attempt to re-establish the PCEP session without TLS next. T= he > 279 attempt to re-establish the PCEP session without TLS SHOULD b= e > 280 limited to only once. >=20 > 282 If the PCEP speaker supports PCEPS and can establish a TLS conne= ction > 283 it MUST start the TLS connection negotiation and establishment s= teps > 284 described in Section 3.4 before the PCEP initialization procedur= e > 285 (section 4.2.1 of [RFC5440]). >=20 > 287 After the exchange of StartTLS messages, if the TLS negotiation = fails > 288 for some reason (e.g. the required mechanisms for certificate > 289 revocation checking are not available), both peers SHOULD immedi= ately > 290 close the connection. >=20 > 292 A PCEP speaker that does not support PCEPS sends the Open messag= e > 293 directly, as per [RFC5440]. A PCEP speaker that supports PCEPS,= but > 294 has learned in the last exchange the peer's willingness to > 295 reestablish session without TLS, MAY send the Open message direc= tly, > 296 as per [RFC5440]. The attempt to re-establish the PCEP session > 297 without TLS SHOULD be limited to only once. >=20 > 299 Given the asymmetric nature of TLS for connection establishment,= it > 300 is relevant to identify the roles of each of the PCEP peers in i= t. > 301 The PCC SHALL act as TLS client, and the PCE SHALL act as TLS se= rver > 302 as per [RFC5246]. >=20 > 304 As per the recommendation from [RFC7525] to avoid downgrade atta= cks, > 305 PCEP peers that support PCEPS, SHOULD default to strict TLS > 306 configuration i.e. do not allow non-TLS PCEP sessions to be > 307 established. PCEPS implementations MAY provide an option to all= ow > 308 the operator to manually override strict TLS configuration and a= llow > 309 unsecured connections. Execution of this override SHOULD trigge= r a > 310 warning about the security implications of permitting unsecured > 311 connections. >=20 > 313 3.3. The StartTLS Message >=20 > 315 The StartTLS message is used to initiate the TLS procedure for a= > 316 PCEPS session between the PCEP peers. A PCEP speaker sends the > 317 StartTLS message to request negotiation and establishment of TLS= > 318 connection for PCEP. On receiving a StartTLS message from the P= CEP > 319 peer (i.e. when the PCEP speaker has sent and received StartTLS= > 320 message) it is ready to start the negotiation and establishment = of > 321 TLS and move to steps described in Section 3.4. >=20 > 323 The collision resolution procedures described in [RFC5440] for t= he > 324 exchange of Open messages MUST be applied by the PCEP peers duri= ng > 325 the exchange of StartTLS messages. >=20 > 327 The format of a StartTLS message is as follows: >=20 > 329 ::=3D >=20 > 331 The StartTLS message MUST contain only the PCEP common header wi= th > 332 Message-Type field set to [TBA1 by IANA]. >=20 > 334 Once the TCP connection has been successfully established, the P= CEP > 335 speaker MUST start a timer called StartTLSWait timer, after the > 336 expiration of which, if neither StartTLS message has been receiv= ed, > 337 nor a PCErr/Open message (in case of failure and PCEPS not suppo= rted > 338 by the peer, respectively), it MUST send a PCErr message with Er= ror- > 339 Type set to [TBA2 by IANA] and Error-value set to 5 (no StartTLS= (nor > 340 PCErr/Open) message received before the expiration of the > 341 StartTLSWait timer) and it MUST release the TCP connection . A > 342 RECOMMENDED value for StartTLSWait timer is 60 seconds. The val= ue of > 343 StartTLSWait timer MUST NOT be less than OpenWait timer. >=20 > 345 +-+-+ +-+-+ > 346 |PCC| |PCE| > 347 +-+-+ +-+-+ > 348 | | > 349 | StartTLS | > 350 | msg | > 351 |------- | > 352 | \ StartTLS | > 353 | \ msg | > 354 | \ ---------| > 355 | \/ | > 356 | /\ | > 357 | / -------->| > 358 | / | > 359 |<------ | > 360 |:::::::::TLS:::::::::| > 361 |:::::Establishment:::| > 362 | | > 363 | | > 364 |:::::::PCEP::::::::::| > 365 | | >=20 > 367 Figure 1: Both PCEP Speaker supports PCEPS (strict) > 368 +-+-+ +-+-+ > 369 |PCC| |PCE| > 370 +-+-+ +-+-+ > 371 | | > 372 | StartTLS | > 373 | msg | > 374 |------- | > 375 | \ StartTLS | > 376 | \ msg | > 377 | \ ---------| > 378 | \/ | > 379 | /\ | > 380 | / -------->| > 381 | / | > 382 |<------ | > 383 |:::::::::TLS:::::::::| TLS Establishment > 384 |:::::Establishment:::| Failure, Both > 385 | | peers close > 386 session >=20 > 388 Figure 2: Both PCEP Speaker supports PCEPS (strict), but cann= ot > 389 establish TLS >=20 > 391 +-+-+ +-+-+ > 392 |PCC| |PCE| > 393 +-+-+ +-+-+ > 394 | | Does not support > 395 | StartTLS | PCEPS and thus > 396 | msg | sends Open > 397 |------- | > 398 | \ Open | > 399 | \ msg | > 400 | \ ---------| > 401 | \/ | > 402 | /\ | > 403 | / -------->| > 404 | / | > 405 |<------ | > 406 | | > 407 |<--------------------| Send Error > 408 | PCErr | Type=3D1,Value=3D1 > 409 | | (non-Open message > 410 |<--------------------| received) > 411 | Close | > 412 ///////// TCP ///////// > 413 //////re-establish///// > 414 Send Open | Open | > 415 this time | msg | > 416 |------- | > 417 | \ Open | > 418 | \ msg | > 419 | \ ---------| > 420 | \/ | > 421 | /\ | > 422 | / -------->| > 423 | / | > 424 |<------ | >=20 > 426 Figure 3: One PCEP Speaker (PCE) does not support PCEPS, while = PCC > 427 supports both with or without PCEPS >=20 > 429 +-+-+ +-+-+ > 430 |PCC| |PCE| > 431 +-+-+ +-+-+ > 432 | | > 433 | StartTLS | > 434 | msg | PCE waits > 435 |-------------------->| for PCC and > 436 | StartTLS | respond with > 437 |<--------------------| Start TLS > 438 | | > 439 |:::::::::TLS:::::::::| > 440 |:::::Establishment:::| > 441 | | > 442 | | > 443 |:::::::PCEP::::::::::| > 444 | | >=20 > 446 Figure 4: Both PCEP Speaker supports PCEPS as well as without P= CEPS >=20 > 448 +-+-+ +-+-+ > 449 |PCC| |PCE| > 450 +-+-+ +-+-+ > 451 | | > 452 | StartTLS | > 453 | msg | PCE waits > 454 |-------------------->| for PCC > 455 | PCErr | > 456 |<--------------------| Send Error > 457 | | Type=3DTBA2,Value=3D3 > 458 | | (Failure, connection > 459 |<--------------------| without TLS is not > 460 | Close | possible) >=20 > 462 Figure 5: Both PCEP Speaker supports PCEPS as well as without PC= EPS, > 463 but PCE cannot start TLS negotiation >=20 > 465 +-+-+ +-+-+ > 466 |PCC| |PCE| > 467 +-+-+ +-+-+ > 468 | | > 469 | Open | > 470 | msg | PCE waits > 471 |-------------------->| for PCC and > 472 | Open | respond with > 473 |<--------------------| Open > 474 | | > 475 |:::::::PCEP::::::::::| > 476 | | >=20 > 478 Figure 6: PCE supports PCEPS as well as without PCEPS, while PCC= does > 479 not support PCEPS >=20 > 481 3.4. TLS Connection Establishment >=20 > 483 Once the establishment of TLS has been agreed by the PCEP peers,= the > 484 connection establishment SHALL follow the following steps: >=20 > 486 1. Immediately negotiate a TLS session according to [RFC5246]. = The > 487 following restrictions apply: >=20 > 489 * Support for TLS v1.2 [RFC5246] or later is REQUIRED. >=20 > 491 * Support for certificate-based mutual authentication is > 492 REQUIRED. >=20 > 494 * Negotiation of a ciphersuite providing for integrity > 495 protection is REQUIRED. >=20 > 497 * Negotiation of a ciphersuite providing for confidentialit= y is > 498 RECOMMENDED. >=20 > 500 * Support for and negotiation of compression is OPTIONAL. >=20 > 502 * PCEPS implementations MUST, at a minimum, support negotia= tion > 503 of the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [RFC6460],= and > 504 SHOULD support TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as= > 505 well. Implementations SHOULD support the NIST P-256 > 506 (secp256r1) curve [RFC4492]. In addition, PCEPS > 507 implementations MUST support negotiation of the mandatory= -to- > 508 implement ciphersuites required by the versions of TLS th= at > 509 they support from TLS 1.3 onwards. >=20 > 511 2. Peer authentication can be performed in any of the following= two > 512 REQUIRED operation models: >=20 > 514 * TLS with X.509 certificates using Public-Key Infrastructu= re > 515 Exchange (PKIX) trust models: >=20 > 517 + Implementations MUST allow the configuration of a list= of > 518 trusted Certification Authorities (CAs) for incoming > 519 connections. >=20 > 521 + Certificate validation MUST include the verification r= ules > 522 as per [RFC5280]. >=20 > 524 + PCEPS implementations SHOULD incorporate revocation me= thods > 525 (CRL downloading, OCSP...) according to the trusted CA= > 526 policies. >=20 > 528 + Implementations SHOULD indicate their trusted CAs. Fo= r TLS > 529 1.2, this is done using [RFC5246], Section 7.4.4, > 530 "certificate_authorities" (server side) and [RFC6066],= > 531 Section 6 "Trusted CA Indication" (client side). >=20 > 533 + Implementations MUST follow the rules and guidelines f= or > 534 peer validation as defined in [RFC6125]. If an expect= ed > 535 DNS name or IP address for the peer is configured, the= n the > 536 implementations MUST check them against the values in = the > 537 presented certificate. The DNS names and the IP addre= sses > 538 can be contained in the CN-ID [RFC6125] (Common Name > 539 Identifier) or the subjectAltName entries. For > 540 verification, only one of these entries is considered.= The > 541 following precedence applies: for DNS name validation,= DNS- > 542 ID [RFC6125] has precedence over CN-ID; for IP address= > 543 validation, subjectAltName:iPAddr has precedence over = CN- > 544 ID. >=20 > 546 + Implementations MAY allow the configuration of a set o= f > 547 additional properties of the certificate to check for = a > 548 peer's authorization to communicate (e.g., a set of al= lowed > 549 values in URI-ID [RFC6125] or a set of allowed X509v3 > 550 Certificate Policies). The definition of these proper= ties > 551 are out of scope of this document. >=20 > 553 * TLS with X.509 certificates using certificate fingerprint= s: > 554 Implementations MUST allow the configuration of a list of= > 555 certificates that are trusted to identify peers, identifi= ed > 556 via fingerprint of the Distinguished Encoding Rules (DER)= > 557 encoded certificate octets. Implementations MUST support= > 558 SHA-256 as defined by [SHS] as the hash algorithm for the= > 559 fingerprint, but a later revision may demand support for = a > 560 stronger hash function. >=20 > 562 3. Start exchanging PCEP messages. >=20 > 564 * Once the TLS connection has been successfully established= , the > 565 PCEP speaker MUST start the OpenWait timer [RFC5440], aft= er > 566 the expiration of which, if no Open message has been rece= ived, > 567 it sends a PCErr message and releases the TCP/TLS connect= ion. >=20 > 569 3.5. Peer Identity >=20 > 571 Depending on the peer authentication method in use, PCEPS suppor= ts > 572 different operation modes to establish peer's identity and wheth= er it > 573 is entitled to perform requests or can be considered authoritati= ve in > 574 its replies. PCEPS implementations SHOULD provide mechanisms fo= r > 575 associating peer identities with different levels of access and/= or > 576 authoritativeness, and they MUST provide a mechanism for establi= shing > 577 a default level for properly identified peers. Any connection > 578 established with a peer that cannot be properly identified SHALL= be > 579 terminated before any PCEP exchange takes place. >=20 > 581 In TLS-X.509 mode using fingerprints, a peer is uniquely identif= ied > 582 by the fingerprint of the presented certificate. >=20 > 584 There are numerous trust models in PKIX environments, and it is > 585 beyond the scope of this document to define how a particular > 586 deployment determines whether a peer is trustworthy. Implementa= tions > 587 that want to support a wide variety of trust models should expos= e as > 588 many details of the presented certificate to the administrator a= s > 589 possible so that the trust model can be implemented by the > 590 administrator. At least the following parameters of the X.509 > 591 certificate SHOULD be exposed: >=20 > 593 o Peer's IP address >=20 > 595 o Peer's fully qualified domain name (FQDN) >=20 > 597 o Certificate Fingerprint >=20 > 599 o Issuer >=20 > 601 o Subject >=20 > 603 o All X509v3 Extended Key Usage >=20 > 605 o All X509v3 Subject Alternative Name >=20 > 607 o All X509v3 Certificate Policies > 608 Note that the remote IP address used for the TCP session > 609 establishment is also exposed. >=20 > 611 [I-D.ietf-pce-stateful-sync-optimizations] specify a Speaker Ent= ity > 612 Identifier TLV (SPEAKER-ENTITY-ID), as an optional TLV that is > 613 included in the OPEN Object. It contains a unique identifier fo= r the > 614 node that does not change during the lifetime of the PCEP speake= r. > 615 An implementation would thus expose the speaker entity identifie= r as > 616 part of the X509v3 certificate's subjectAltName:otherName, so th= at an > 617 implementation could use this identifier for the peer identifica= tion > 618 trust model. >=20 > 620 In addition, a PCC MAY apply the procedures described in [RFC669= 8] > 621 DNS-Based Authentication of Named Entities (DANE) to verify its = peer > 622 identity when using DNS discovery. See section Section 4.1 for > 623 further details. >=20 > 625 3.6. Connection Establishment Failure >=20 > 627 In case the initial TLS negotiation or the peer identity check f= ails, > 628 according to the procedures listed in this document, both peers > 629 SHOULD immediately close the connection. >=20 > 631 The initiator SHOULD follow the procedure listed in [RFC5440] to= > 632 retry session setup as per the exponential back-off session > 633 establishment retry procedure. >=20 > 635 4. Discovery Mechanisms >=20 > 637 This document does not specify any discovery mechanism for suppo= rt of > 638 PCEPS. Other documents, [I-D.wu-pce-discovery-pceps-support] an= d > 639 [I-D.wu-pce-dns-pce-discovery] have made proposals: >=20 > 641 o A PCE can advertise its capability to support PCEPS using the= > 642 IGP's advertisement mechanism of the PCE discovery informatio= n. > 643 The PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to adve= rtise > 644 PCE capabilities. It is present within the PCE Discovery (PC= ED) > 645 sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] pr= ovide > 646 the description and processing rules for this sub-TLV when ca= rried > 647 within OSPF and IS-IS, respectively. PCE capability bits are= > 648 defined in [RFC5088]. A new capability flag bit for the PCE-= CAP- > 649 FLAGS sub-TLV that can be announced as an attribute to distri= bute > 650 PCEP security support information is proposed in > 651 [I-D.wu-pce-discovery-pceps-support]. >=20 > 653 o A PCE can advertise its capability to support PCEPS using the= DNS > 654 [I-D.wu-pce-dns-pce-discovery] by identifying the support of = TLS. >=20 > 656 4.1. DANE Applicability >=20 > 658 DANE [RFC6698] defines a secure method to associate the certific= ate > 659 that is obtained from a TLS server with a domain name using DNS,= > 660 i.e., using the TLSA DNS resource record (RR) to associate a TLS= > 661 server certificate or public key with the domain name where the > 662 record is found, thus forming a "TLSA certificate association". = The > 663 DNS information needs to be protected by DNS Security (DNSSEC). = A > 664 PCC willing to apply DANE to verify server identity MUST conform= to > 665 the rules defined in section 4 of [RFC6698]. The implementation= MUST > 666 support Service certificate constraint (TLSA Certificate Usages = type > 667 1) with Matching type 2 (SHA2-256) as described in > 668 [RFC6698][RFC7671]. The server's domain name must be authorized= > 669 separately, as TLSA does not provide any useful authorization > 670 guarantees. >=20 > 672 5. Backward Compatibility >=20 > 674 The procedures described in this document define a security cont= ainer > 675 for the transport of PCEP requests and replies carried by a TLS > 676 connection initiated by means of a specific extended message > 677 (StartTLS) that does not interfere with PCEP speaker implementat= ions > 678 not supporting it. >=20 > 680 A PCC that does not support PCEPS will send Open message as the = first > 681 message on TCP establishment. A PCE that supports PCEPS only, w= ill > 682 send StartTLS message on TCP establishment. On receiving StartT= LS > 683 message, PCC would consider it as an error and behave according = to > 684 the existing error mechanism of [RFC5440] and send PCErr message= with > 685 Error-Type 1 (PCEP session establishment failure) and Error-Valu= e 1 > 686 (reception of an invalid Open message or a non Open message) and= > 687 close the session. >=20 > 689 A PCC that support PCEPS will send StartTLS message as the first= > 690 message on TCP establishment. A PCE that does not supports PCEP= S, > 691 would consider receiving StartTLS message as an error and respon= d > 692 with PCErr message (with Error-Type 1 and Error-Value 1) and clo= se > 693 the session. >=20 > 695 If a StartTLS message is received at any other time by a PCEP sp= eaker > 696 that does not implement PCEPS, it would consider it as an unknow= n > 697 message and would behave according to the existing error mechani= sm of > 698 [RFC5440] and send PCErr message with Error-Type 2 (Capability n= ot > 699 supported) and close the session. >=20 > 701 An existing PCEP session cannot be upgraded to PCEPS, the sessio= n > 702 needs to be terminated and reestablished as per the procedure > 703 described in this document. During the incremental upgrade, the= PCEP > 704 speaker SHOULD allow session establishment with and without TLS.= > 705 Once both PCEP speakers are upgraded to support PCEPS, the PCEP > 706 session is re-established with TLS, otherwise PCEP session witho= ut > 707 TLS is setup. A redundant PCE MAY also be used during the > 708 incremental deployment to take over the PCE undergoing upgrade. = Once > 709 the upgrade is completed, support for unsecured version SHOULD b= e > 710 removed. >=20 > 712 A PCE that accepts connections with or without PCEPS, it would > 713 respond based on the message received from PCC. A PCC that supp= orts > 714 connection with or without PCEPS, it would first attempt to conn= ect > 715 with PCEPS and in case of error, it MAY retry to establish conne= ction > 716 without PCEPS. For successful TLS operations with PCEP, both PC= EP > 717 peers in the network would need to be upgraded to support this > 718 document. >=20 > 720 Note that, a PCEP implementation that support PCEPS would respon= d > 721 with PCErr message with Error-Type set to [TBA2 by IANA] (PCEP > 722 StartTLS failure) and Error-value set to 2 if any other message = is > 723 sent before StartTLS or Open. If the sender of the invalid mess= age > 724 is a PCEP implementation that does not support PCEPS, it will no= t be > 725 able to understand this error. A PCEPS implementation could als= o > 726 send the PCErr message as per [RFC5440] with Error-Type "PCEP se= ssion > 727 establishment failure" and Error-value "reception of an invalid = Open > 728 message or a non Open message" before closing the session. >=20 > 730 6. IANA Considerations >=20 > 732 6.1. New PCEP Message >=20 > 734 IANA is requested to allocate new message types within the "PCEP= > 735 Messages" sub-registry of the PCEP Numbers registry, as follows:= >=20 > 737 Value Description Reference > 738 TBA1 The Start TLS Message (StartTLS) This document >=20 > 740 6.2. New Error-Values >=20 > 742 IANA is requested to allocate new Error Types and Error Values w= ithin > 743 the " PCEP-ERROR Object Error Types and Values" sub-registry of = the > 744 PCEP Numbers registry, as follows: >=20 > 746 Error- > 747 Type Meaning Error-value Reference >=20 > 749 TBA2 PCEP StartTLS 0:Unassigned This docum= ent > 750 failure 1:Reception of This docum= ent > 751 StartTLS after > 752 any PCEP exchange > 753 2:Reception of This docum= ent > 754 any other message > 755 apart from StartTLS, > 756 Open or PCErr > 757 3:Failure, connection This docum= ent > 758 without TLS is not > 759 possible > 760 4:Failure, connection This docum= ent > 761 without TLS is > 762 possible > 763 5:No StartTLS message This docum= ent > 764 (nor PCErr/Open) > 765 before StartTLSWait > 766 timer expiry >=20 > 768 7. Security Considerations >=20 > 770 While the application of TLS satisfies the requirement on > 771 confidentiality as well as fine-grained, policy-based peer > 772 authentication, there are security threats that it cannot addres= s. > 773 It may be advisable to apply additional protection measures, in > 774 particular in what relates to attacks specifically addressed to > 775 forging the TCP connection underpinning TLS, especially in the c= ase > 776 of long-lived connections. One of these measures is the applica= tion > 777 of TCP-AO (TCP Authentication Option [RFC5925]), which is fully > 778 compatible with and deemed as complementary to TLS. The mechani= sms > 779 to configure the requirements to use TCP-AO and other lower-laye= r > 780 protection measures with a particular peer are outside the scope= of > 781 this document. >=20 > 783 Since computational resources required by TLS handshake and > 784 ciphersuite are higher than unencrypted TCP, clients connecting = to a > 785 PCEPS server can more easily create high load conditions and a > 786 malicious client might create a Denial-of-Service attack more ea= sily. >=20 > 788 Some TLS ciphersuites only provide integrity validation of their= > 789 payload, and provide no encryption, such ciphersuites SHOULD NOT= be > 790 used by default. Administrators MAY allow the usage of these > 791 ciphersuites after careful weighting of the risk of relevant int= ernal > 792 data leakage, that can occur in such a case, as explicitly state= d by > 793 [RFC6952]. >=20 > 795 When using certificate fingerprints to identify PCEPS peers, any= two > 796 certificates that produce the same hash value will be considered= the > 797 same peer. Therefore, it is important to make sure that the has= h > 798 function used is cryptographically uncompromised, so that attack= ers > 799 are very unlikely to be able to produce a hash collision with a > 800 certificate of their choice. This document mandates support for= > 801 SHA-256 as defined by [SHS], but a later revision may demand sup= port > 802 for stronger functions if suitable attacks on it are known. >=20 > 804 PCEPS implementations that continue to accept connections withou= t TLS > 805 are susceptible to downgrade attacks as described in [RFC7457]. = An > 806 attacker could attempt to remove the use of StartTLS message tha= t > 807 request the use of TLS as it pass on the wire in clear, and furt= her > 808 inject a PCErr message that suggest to attempt PCEP connection > 809 without TLS. >=20 > 811 The guidance given in [RFC7525] SHOULD be followed to avoid atta= cks > 812 on TLS. >=20 > 814 8. Manageability Considerations >=20 > 816 All manageability requirements and considerations listed in [RFC= 5440] > 817 apply to PCEP protocol extensions defined in this document. In > 818 addition, requirements and considerations listed in this section= > 819 apply. >=20 > 821 8.1. Control of Function and Policy >=20 > 823 A PCE or PCC implementation SHOULD allow configuring the PCEP > 824 security via TLS capabilities as described in this document. >=20 > 826 A PCE or PCC implementation supporting PCEP security via TLS MUS= T > 827 support general TLS configuration as per [RFC5246]. At least th= e > 828 configuration of one of the trust models and its corresponding > 829 parameters, as described in Section 3.4 and Section 3.5, MUST be= > 830 supported by the implementation. >=20 > 832 A PCEP implementation SHOULD allow configuring the StartTLSWait = timer > 833 value. >=20 > 835 PCEPS implementations MAY provide an option to allow the operato= r to > 836 manually override strict TLS configuration and allow unsecure > 837 connections. Execution of this override SHOULD trigger a warnin= g > 838 about the security implications of permitting unsecure connectio= ns. >=20 > 840 Further, the operator needs to develop suitable security policie= s > 841 around PCEP within his network. The PCEP peers SHOULD provide w= ays > 842 for the operator to complete the following tasks in regards to a= PCEP > 843 session: >=20 > 845 o Determine if a session is protected via PCEPS. >=20 > 847 o Determine the version of TLS, the mechanism used for > 848 authentication, and the ciphersuite in use. >=20 > 850 o Determine if the certificate could not be verified, and the r= eason > 851 for this circumstance. >=20 > 853 o Inspect the certificate offered by the PCEP peer. >=20 > 855 o Be warned if StartTLS procedure fails for the PCEP peers, tha= t are > 856 known to support PCEPS via configurations or capability > 857 advertisements. >=20 > 859 8.2. Information and Data Models >=20 > 861 The PCEP MIB module is defined in [RFC7420]. The MIB module cou= ld be > 862 extended to include the ability to view the PCEPS capability, TL= S > 863 related information as well as TLS status for each PCEP peer. >=20 > 865 Further, to allow the operator to configure the PCEPS capability= and > 866 various TLS related parameters as well as to view the current TL= S > 867 status for a PCEP session, the PCEP YANG module > 868 [I-D.ietf-pce-pcep-yang] is extended to include TLS related > 869 information. >=20 > 871 8.3. Liveness Detection and Monitoring >=20 > 873 Mechanisms defined in this document do not imply any new livenes= s > 874 detection and monitoring requirements in addition to those alrea= dy > 875 listed in [RFC5440] and [RFC5246]. >=20 > 877 8.4. Verifying Correct Operations >=20 > 879 A PCEPS implementation SHOULD log error events and provide PCEPS= > 880 failure statistics with reasons. >=20 > 882 8.5. Requirements on Other Protocols >=20 > 884 Mechanisms defined in this document do not imply any new require= ments > 885 on other protocols. Note that, Section 4 list possible discover= y > 886 mechanism for support of PCEPS. >=20 > 888 8.6. Impact on Network Operation >=20 > 890 Mechanisms defined in this document do not have any significant > 891 impact on network operations in addition to those already listed= in > 892 [RFC5440], and the policy and management implications discussed > 893 above. >=20 > 895 9. Acknowledgements >=20 > 897 This specification relies on the analysis and profiling of TLS > 898 included in [RFC6614] and the procedures described for the START= TLS > 899 command in [RFC4513]. >=20 > 901 We would like to thank Joe Touch for his suggestions and support= > 902 regarding the StartTLS mechanisms. >=20 > 904 Thanks to Daniel King for reminding the authors about manageabil= ity > 905 considerations. >=20 > 907 Thanks to Cyril Margaria for shepherding this document. >=20 > 909 Thanks to David Mandelberg for early SECDIR review comments as w= ell > 910 as re-reviewing during IETF last call. >=20 > 912 Thanks to Dan Frost for the RTGDIR review and comments. >=20 > 914 Thanks to Dale Worley for the Gen-ART review and comments. >=20 > 916 Also thanks to Tianran Zhou for OPSDIR review. >=20 > 918 Thanks to Deborah Brungard for being the responsible AD and guid= ing > 919 the authors as needed. >=20 > 921 Thanks to Mirja Kuhlewind, Eric Rescorla, Warren Kumari, Kathlee= n > 922 Moriarty, Suresh Krishnan, Ben Campbell and Alexey Melnikov for = the > 923 IESG review and comments. >=20 > 925 10. References >=20 > 927 10.1. Normative References >=20 > 929 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > 930 Requirement Levels", BCP 14, RFC 2119, > 931 DOI 10.17487/RFC2119, March 1997, > 932 . >=20 > 934 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Secu= rity > 935 (TLS) Protocol Version 1.2", RFC 5246, > 936 DOI 10.17487/RFC5246, August 2008, > 937 . >=20 > 939 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., > 940 Housley, R., and W. Polk, "Internet X.509 Public Key > 941 Infrastructure Certificate and Certificate Revocation= List > 942 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2= 008, > 943 . >=20 > 945 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computa= tion > 946 Element (PCE) Communication Protocol (PCEP)", RFC 544= 0, > 947 DOI 10.17487/RFC5440, March 2009, > 948 . >=20 > 950 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) > 951 Extensions: Extension Definitions", RFC 6066, > 952 DOI 10.17487/RFC6066, January 2011, > 953 . >=20 > 955 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and > 956 Verification of Domain-Based Application Service Iden= tity > 957 within Internet Public Key Infrastructure Using X.509= > 958 (PKIX) Certificates in the Context of Transport Layer= > 959 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, Marc= h > 960 2011, . >=20 > 962 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentic= ation > 963 of Named Entities (DANE) Transport Layer Security (TL= S) > 964 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, Augu= st > 965 2012, . >=20 > 967 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, > 968 "Recommendations for Secure Use of Transport Layer > 969 Security (TLS) and Datagram Transport Layer Security > 970 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May= > 971 2015, . >=20 > 973 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based > 974 Authentication of Named Entities (DANE) Protocol: Upd= ates > 975 and Operational Guidance", RFC 7671, DOI 10.17487/RFC= 7671, > 976 October 2015, . >=20 > 978 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RF= C > 979 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC81= 74, > 980 May 2017, . >=20 > 982 [SHS] National Institute of Standards and Technology, "Secu= re > 983 Hash Standard (SHS), FIPS PUB 180-4", > 984 DOI 10.6028/NIST.FIPS.180-4, August 2015, > 985 986 NIST.FIPS.180-4.pdf>. >=20 > 988 10.2. Informative References >=20 > 990 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., a= nd B. > 991 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Su= ites > 992 for Transport Layer Security (TLS)", RFC 4492, > 993 DOI 10.17487/RFC4492, May 2006, > 994 . >=20 > 996 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Prot= ocol > 997 (LDAP): Authentication Methods and Security Mechanism= s", > 998 RFC 4513, DOI 10.17487/RFC4513, June 2006, > 999 . >=20 > 1001 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., a= nd R. > 1002 Zhang, "OSPF Protocol Extensions for Path Computatio= n > 1003 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC= 5088, > 1004 January 2008, . >=20 > 1006 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., a= nd R. > 1007 Zhang, "IS-IS Protocol Extensions for Path Computati= on > 1008 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC= 5089, > 1009 January 2008, . >=20 > 1011 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP > 1012 Authentication Option", RFC 5925, DOI 10.17487/RFC59= 25, > 1013 June 2010, = =2E >=20 > 1015 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for Tran= sport > 1016 Layer Security (TLS)", RFC 6460, DOI 10.17487/RFC646= 0, > 1017 January 2012, . >=20 > 1019 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wiereng= a, > 1020 "Transport Layer Security (TLS) Encryption for RADIU= S", > 1021 RFC 6614, DOI 10.17487/RFC6614, May 2012, > 1022 . >=20 > 1024 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis= of > 1025 BGP, LDP, PCEP, and MSDP Issues According to the Key= ing > 1026 and Authentication for Routing Protocols (KARP) Desi= gn > 1027 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, > 1028 . >=20 > 1030 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.= > 1031 Hardwick, "Path Computation Element Communication Pr= otocol > 1032 (PCEP) Management Information Base (MIB) Module", > 1033 RFC 7420, DOI 10.17487/RFC7420, December 2014, > 1034 . >=20 > 1036 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summariz= ing > 1037 Known Attacks on Transport Layer Security (TLS) and > 1038 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457= , > 1039 February 2015, . >=20 > 1041 [I-D.ietf-pce-stateful-sync-optimizations] > 1042 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang,= X., > 1043 and D. Dhody, "Optimizations of Label Switched Path = State > 1044 Synchronization Procedures for a Stateful PCE", draf= t- > 1045 ietf-pce-stateful-sync-optimizations-10 (work in > 1046 progress), March 2017. >=20 > 1048 [I-D.ietf-pce-pcep-yang] > 1049 Dhody, D., Hardwick, J., Beeram, V., and j. > 1050 jefftant@gmail.com, "A YANG Data Model for Path > 1051 Computation Element Communications Protocol (PCEP)",= > 1052 draft-ietf-pce-pcep-yang-05 (work in progress), June= 2017. >=20 > 1054 [I-D.wu-pce-dns-pce-discovery] > 1055 Wu, Q., Dhody, D., King, D., Lopez, D., and J. Tants= ura, > 1056 "Path Computation Element (PCE) Discovery using Doma= in > 1057 Name System(DNS)", draft-wu-pce-dns-pce-discovery-10= (work > 1058 in progress), March 2017. >=20 > 1060 [I-D.wu-pce-discovery-pceps-support] > 1061 Lopez, D., Wu, Q., Dhody, D., and D. King, "IGP exte= nsion > 1062 for PCEP security capability support in the PCE > 1063 discovery", draft-wu-pce-discovery-pceps-support-07 = (work > 1064 in progress), March 2017. >=20 > 1066 Authors' Addresses >=20 > 1068 Diego R. Lopez > 1069 Telefonica I+D > 1070 Don Ramon de la Cruz, 82 > 1071 Madrid 28006 > 1072 Spain >=20 > 1074 Phone: +34 913 129 041 > 1075 EMail: diego.r.lopez@telefonica.com > 1076 Oscar Gonzalez de Dios > 1077 Telefonica I+D > 1078 Don Ramon de la Cruz, 82 > 1079 Madrid 28006 > 1080 Spain >=20 > 1082 Phone: +34 913 129 041 > 1083 EMail: oscar.gonzalezdedios@telefonica.com >=20 > 1085 Qin Wu > 1086 Huawei > 1087 101 Software Avenue, Yuhua District > 1088 Nanjing, Jiangsu 210012 > 1089 China >=20 > 1091 EMail: sunseawq@huawei.com >=20 > 1093 Dhruv Dhody > 1094 Huawei > 1095 Divyashree Techno Park, Whitefield > 1096 Bangalore, KA 560066 > 1097 India >=20 > 1099 EMail: dhruv.ietf@gmail.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Mon, Sep 4, 2017 at 8:31 PM, Henrik Levkowetz = > wrote: >=20 >> >> Hi, >> >> This is an automatic notification about a new xml2rfc release, >> v2.8.0, generated when running the mkrelease script. >> >> Release notes: >> >> xml2rfc (2.8.0) ietf; urgency=3Dlow >> This is a small feature release which changes URLs in boilerplate to= >> use https: instead of http:. There are also some bugfixes. >> * Include notes when doing index processing. Fixes issue #335. >> * Include erefs with text equal to the URL in the URIs section. See= >> issue #334. >> * Changed the use of http: to https: in many places. In the generat= ion >> of RFCs, the code uses a switchover date of August 21, 2017 when >> deciding >> whether to insert http: or https: URLs. In practice, this means t= hat >> RFCs >> with a date of September 2017 or later will get https:. Also fixe= d URL >> line-breaking prevention to apply to https: URLS. Fixes issue #33= 3. >> * In urlkeep(), prevent breaking also for https:, not only http: URL= s >> >> The new version is available through SVN checkout, with >> 'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2= =2E8.0 >> ' >> >> Regards, >> >> Henrik >> (via the mkrelease script) >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc >> >=20 --DDgGFIVWIP295RsX47gLiNT5qn8VpAq2H-- --sa0HblPh5IIixmnm2f6edWaE0rTq0AT6B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZrbbVAAoJEE6bV0uPuxcaz8IQAKCCQwbZcOORdVriKeKgFmaC JR9UFtdtZzF+1FdWV1Gw/sAi+/E02KcvzUx+fUN7FW8iGh//s36deGx/96diFXLo 2gbwIW5z7LJkqaZZYiTEP5XL4EyP3n8PRQhrTh06vbDW5W9cYtxGELMyDEXKLMkz mdPpAwXv9UhNInQMuT1V4owQ4FejS+7TK1KhjBY5sT84ywCLq5Oz/7RpDzYfaQTk bCBZM4Pl7jm9h1zPnL+vSuo/ZkNgbkiYez9Tv8k2z3yE7Db6u5UZx2y/oyWJdfKM 2dIguErRt5BqqdgPy5ap7zUcb0oPjRdQKvRJqmyCIYSkhmo5lakXLjox75qSHBis iRyd3r0rUxKxV5s6Ew/mvlifliSLLayCuX1GYljUQWrWe+gnVebYC3oFrciRw+4y RIR7BniIgmmm4W1af76Ef2QjhaI+Ixbk/f9lupLFvdNM3bBJrYWmk6x27tqL5Df7 pAXuxlgm6lMet9zV+KzVSvKOl3moq7pSoNRfh/lyK8EzlJZzg+/eSaF1ryCiVGk3 izOTsgkCdt/p89tEw7gBqVc1iCs5+/EDghc6r1uImIPEhseNuoCuzdtuVhN2OCbR A9TrwTG08Y4nC25KwUmL0ecLtPyXpHtbbzqtQ5Qralgl7gvprZDco1lp/Dmfkk// P21MjNTd7bne0StvSKQ2 =yppq -----END PGP SIGNATURE----- --sa0HblPh5IIixmnm2f6edWaE0rTq0AT6B-- From nobody Tue Sep 5 07:42:27 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB5D132D42 for ; Tue, 5 Sep 2017 07:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 lBL1LYs7iCDu for ; Tue, 5 Sep 2017 07:42:23 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82CF4132D41 for ; Tue, 5 Sep 2017 07:42:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 88BC7620D7 for ; Tue, 5 Sep 2017 10:42:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id U4XcQkZLXtF6 for ; Tue, 5 Sep 2017 10:42:19 -0400 (EDT) Received: from lx120e.htt-consult.com (ip70-161-203-197.hr.hr.cox.net [70.161.203.197]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id A1B9E62071 for ; Tue, 5 Sep 2017 10:42:18 -0400 (EDT) To: "xml2rfc@ietf.org" From: Robert Moskowitz Message-ID: <06bde9bf-ad08-7e72-89b1-b50dd8d98088@htt-consult.com> Date: Tue, 5 Sep 2017 10:42:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [xml2rfc] Specifying a reference's author(s) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 14:42:26 -0000 How do I expand: ?? Minimally I want one author Nadia Heninger That that does not work. I would like to cite them all: Nadia Heninger Zakir Durumeric Eric Wustrow J. Alex Halderman No guide to this in FAQ. Thanks From nobody Tue Sep 5 07:43:51 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A7A132D43 for ; Tue, 5 Sep 2017 07:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 gZY_w9QpWOHE for ; Tue, 5 Sep 2017 07:43:43 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B289132D42 for ; Tue, 5 Sep 2017 07:43:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id AC48C620D7 for ; Tue, 5 Sep 2017 10:43:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zNrbQWqox7rK for ; Tue, 5 Sep 2017 10:43:39 -0400 (EDT) Received: from lx120e.htt-consult.com (ip70-161-203-197.hr.hr.cox.net [70.161.203.197]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 1ABEA62071 for ; Tue, 5 Sep 2017 10:43:38 -0400 (EDT) To: "xml2rfc@ietf.org" From: Robert Moskowitz Message-ID: <3de14686-3a6f-b101-13a5-99654a338c90@htt-consult.com> Date: Tue, 5 Sep 2017 10:43:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [xml2rfc] Also date in reference X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 14:43:45 -0000 It did not like: 2011 Actually would like July, 2011 thanks From nobody Tue Sep 5 08:08:28 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA96132D56 for ; Tue, 5 Sep 2017 08:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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 HE1JJQmljYbG for ; Tue, 5 Sep 2017 08:08:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 36B75132D54 for ; Tue, 5 Sep 2017 08:08:24 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MRSeC-1dvsD31zhI-00SeNX; Tue, 05 Sep 2017 17:08:17 +0200 To: Robert Moskowitz , "xml2rfc@ietf.org" References: <06bde9bf-ad08-7e72-89b1-b50dd8d98088@htt-consult.com> From: Julian Reschke Message-ID: Date: Tue, 5 Sep 2017 17:08:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <06bde9bf-ad08-7e72-89b1-b50dd8d98088@htt-consult.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:xs73sw+0Tx6v3DfzeB1oV9wY3dl66quQxJBJjlCJ+TCEx/G/1K4 ccdpPepGp/saXw0YHdDTlOSxyoRdsOdEYwq/xdagoqEJx+Trrarz9U5agZJoD+NufqCxNta OdSsqHi1j7k719bj11osdWOYoWx611chbfD3ER9JTtnaKUzcyVyTN5BE7bjitRsk0WfyL4h cVEsAn9vx9BnC0uU2B40A== X-UI-Out-Filterresults: notjunk:1;V01:K0:a5u8djT1x4w=:OfmIudjoXf64I3Y3JxpYtw tzPjFAi6xdwolB3IADtct6IEjXEJBPBO8UHHRm8oVVEh7atibpnh4BvQMUvw8d05V8HuEf6Ac PTon96AOX80luHA545acU8STfi3k1P0kWa+vjgv9BEDvr8u2eUWK4oxsK7U7jeaCZ+pB3Ruoz tszjp5+8yprztBXELWkphvQpHU7qD4CjIzwTsrrlLhXAM6Yya+8dgpF0uu6n4GnVqeVWk9Izq zUzKJNL1n/iWE612WX2pI0sAB6eyYTlXG9TQf+Ff0NZDT7wM57nISWWeHublEny2KRrbkQUfA zmQl0nCaDqTTqAvMBmUjYCJl6qz95m24GKiXOY5Er9d8/XwoT0t/A7vyDfxjwTmPJ5gq0kbV/ Kb97JDQ2XWm+atExadWcLLg8Zu2f+xLz+nWPn9IVvMz76cR2BZjL44GhTdonVlwZ0mQEsZFkb I8YIt5KtDmXAmCSErflYYfsCvzVzlGjgoJAUv9mjxqbUiWrY9mkaKa3YF3DDL4WsXAdIVFyfK gVO39a+2xJ036xWlWH/DjQRMzdA+Hp7Evrzczk8opWJBz20I53cpmQNN+eHQU13RLX7SJwPki kUT2F5ZI8Ejj+z3AP4Y9R9lZd+/UCCdIwx53hGg8tDuq8JiPMyzl3DjaS716MbA93Svm4NiSI x3i/PfxDnZDKrYRet9rXaqednXkkw7C9pihVUZtEITINKfkJgfsH9AbjdD+N6bXLhMCIIyq30 Ke6ZZEYLW2InaO3wxPhpt4UK2GPh57pwq/Pvy96IYsTmaRHwKFqC+tDWZaesm5VJpcZ4WREJM nqo7PDENo76toCAW4+Kxu4uVFuzS8Q5u8BVUwOXnRiJPXgcGg0= Archived-At: Subject: Re: [xml2rfc] Specifying a reference's author(s) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 15:08:27 -0000 On 2017-09-05 16:42, Robert Moskowitz wrote: > How do I expand: > > > > ?? > > Minimally I want one author > >     Nadia Heninger > > That that does not work. > > I would like to cite them all: > >     >     Nadia Heninger >     Zakir Durumeric >     Eric Wustrow >     J. Alex Halderman >     > > No guide to this in FAQ. Spec: Example: Best regards, Julian From nobody Tue Sep 5 08:15:04 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931A9132D52 for ; Tue, 5 Sep 2017 08:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 ku2gP0Iilo85 for ; Tue, 5 Sep 2017 08:15:00 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 6ABFA124207 for ; Tue, 5 Sep 2017 08:15:00 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id h70so26601685oic.1 for ; Tue, 05 Sep 2017 08:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F+VKTsYom2OeLq94dlG5y5CUdbUY26L8UdSS4eURJRo=; b=KN7829MNYpix00g/EB/hlW1/5s1fnkyMIqjXXnQztT6i0pOiB95FO9zrzafmIh87Of sywsSEkT4LiOVyuTpLmHeN2foV3W77Jq72aFCvCDDLVeBJnb3YB2lwg6CQKbeJXMFZs+ xhWNNu60XMzUPdfeu6DgF1FUH1mDOyfflYgrqxcgwstocBgKXQ3iUVN1Zwv1rba3pVqz KogLULP9M64LIJdxTZfP/7XzB98K7QRQ05RK5RQxTJGQJH1n66HKwHILDJrQ4nlULGgh 4ddJKHulH3YGFygl49CFb8HFkdntsw8SI/lJ+q+VtZlFr62eUccE4RZF+3fo4Llu+Hpm JXKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F+VKTsYom2OeLq94dlG5y5CUdbUY26L8UdSS4eURJRo=; b=itaUmRGBDxf6Sz6yVYDrQ6fctVD7B7HhWhPNdzJL/6STBOaGYaiswppL6Umm59HFMh xblZpyEmu4LWCBwF1wsZEtA9SFQSxyZ8P7Wz83/j6eOA52ShVjIVouHgc/CX/rYRe6MV qZ8QA1peJCg0AJbSozx6zryi7b9IkijkSEqh6qt3U+sr9cM8TLLQc0iDrwp4bCnwI/DM GvyVm/hny3WIMVTCOPAo3hxwUiY3al9cm+kRURsZuyffGVzGelv6KMlF5NOUP7OI5juS t23AwZNTFpkoKJk55eBgv1etKwn+mKauEyLUsbshzki0rudyhaR/TwZBuN3NqS5MP+P2 5umg== X-Gm-Message-State: AHPjjUhoUUITm14ppHNRUFRVg3Ux+MIrAlbHQ1ijni12v3IeohhS+WAW yj0WHZbg4sJJbQ== X-Google-Smtp-Source: ADKCNb6VGw2Ux4LTwxNxUgt789Yv4KofzB0WOyJXw5UpgG5gyL0lwhtSj8/D7bRmEZcGehOccw9D3A== X-Received: by 10.202.72.201 with SMTP id v192mr4331630oia.128.1504624499704; Tue, 05 Sep 2017 08:14:59 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::1f43? ([2600:8802:5600:e::1f43]) by smtp.gmail.com with ESMTPSA id f187sm684675oig.24.2017.09.05.08.14.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 08:14:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: Fred Baker In-Reply-To: <06bde9bf-ad08-7e72-89b1-b50dd8d98088@htt-consult.com> Date: Tue, 5 Sep 2017 08:14:57 -0700 Cc: "xml2rfc@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <06bde9bf-ad08-7e72-89b1-b50dd8d98088@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [xml2rfc] Specifying a reference's author(s) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 15:15:02 -0000 Last I checked, it was something like
Santa Barbara 93117 California USA FredBaker.IETF@gmail.com
And multiple blocks like that for multiple authors. Did I miss something? > On Sep 5, 2017, at 7:42 AM, Robert Moskowitz wrote: > > How do I expand: > > > > ?? > > Minimally I want one author > > Nadia Heninger > > That that does not work. > > I would like to cite them all: > > > Nadia Heninger > Zakir Durumeric > Eric Wustrow > J. Alex Halderman > > > No guide to this in FAQ. > > Thanks > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Tue Sep 5 08:23:06 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9F8132D5B for ; Tue, 5 Sep 2017 08:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 OTgprGSWQLUt for ; Tue, 5 Sep 2017 08:23:03 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CE91132D52 for ; Tue, 5 Sep 2017 08:23:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id E1EA06211A; Tue, 5 Sep 2017 11:22:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Pt2gmdca5Xce; Tue, 5 Sep 2017 11:22:51 -0400 (EDT) Received: from lx120e.htt-consult.com (ip70-161-203-197.hr.hr.cox.net [70.161.203.197]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id DD10562119; Tue, 5 Sep 2017 11:22:47 -0400 (EDT) To: Fred Baker Cc: "xml2rfc@ietf.org" References: <06bde9bf-ad08-7e72-89b1-b50dd8d98088@htt-consult.com> From: Robert Moskowitz Message-ID: <9fdc8434-cc24-7a73-c55c-b5f44f7ded5a@htt-consult.com> Date: Tue, 5 Sep 2017 11:22:41 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] Specifying a reference's author(s) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 15:23:04 -0000 Julian pointed me to: 2.6. Provides information about a document's author. This is used both for the document itself (at the beginning of the document) and for referenced documents (inside of ). So references does not use a different structure from doc authors... OK. On 09/05/2017 11:14 AM, Fred Baker wrote: > Last I checked, it was something like > > > >
> > > Santa Barbara > 93117 > California > USA > > FredBaker.IETF@gmail.com >
> > > And multiple blocks like that for multiple authors. Did I miss something? > >> On Sep 5, 2017, at 7:42 AM, Robert Moskowitz wrote: >> >> How do I expand: >> >> >> >> ?? >> >> Minimally I want one author >> >> Nadia Heninger >> >> That that does not work. >> >> I would like to cite them all: >> >> >> Nadia Heninger >> Zakir Durumeric >> Eric Wustrow >> J. Alex Halderman >> >> >> No guide to this in FAQ. >> >> Thanks >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc > From nobody Tue Sep 5 08:33:32 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFBA132D5A for ; Tue, 5 Sep 2017 08:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 IJFITWzQyLZX for ; Tue, 5 Sep 2017 08:33:28 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896DF132D52 for ; Tue, 5 Sep 2017 08:33:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 44FCD6211D; Tue, 5 Sep 2017 11:33:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mSijCVWZN7gq; Tue, 5 Sep 2017 11:33:23 -0400 (EDT) Received: from lx120e.htt-consult.com (ip70-161-203-197.hr.hr.cox.net [70.161.203.197]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 86EA66211B; Tue, 5 Sep 2017 11:33:22 -0400 (EDT) To: Fred Baker Cc: "xml2rfc@ietf.org" References: <06bde9bf-ad08-7e72-89b1-b50dd8d98088@htt-consult.com> From: Robert Moskowitz Message-ID: <266e56a8-b4a8-f4ed-7897-4942a616c9ec@htt-consult.com> Date: Tue, 5 Sep 2017 11:33:19 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] Specifying a reference's author(s) X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 15:33:30 -0000 OK. Got this fixed. thanks On 09/05/2017 11:14 AM, Fred Baker wrote: > Last I checked, it was something like > > > >
> > > Santa Barbara > 93117 > California > USA > > FredBaker.IETF@gmail.com >
> > > And multiple blocks like that for multiple authors. Did I miss something? > >> On Sep 5, 2017, at 7:42 AM, Robert Moskowitz wrote: >> >> How do I expand: >> >> >> >> ?? >> >> Minimally I want one author >> >> Nadia Heninger >> >> That that does not work. >> >> I would like to cite them all: >> >> >> Nadia Heninger >> Zakir Durumeric >> Eric Wustrow >> J. Alex Halderman >> >> >> No guide to this in FAQ. >> >> Thanks >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc > From nobody Tue Sep 5 08:36:23 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A460132D4C for ; Tue, 5 Sep 2017 08:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wz2esQQBqt-D for ; Tue, 5 Sep 2017 08:36:17 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E14132D62 for ; Tue, 5 Sep 2017 08:36:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 1312562121 for ; Tue, 5 Sep 2017 11:36:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NtosGtGBN0iI for ; Tue, 5 Sep 2017 11:36:12 -0400 (EDT) Received: from lx120e.htt-consult.com (ip70-161-203-197.hr.hr.cox.net [70.161.203.197]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 6646862120 for ; Tue, 5 Sep 2017 11:36:11 -0400 (EDT) To: "xml2rfc@ietf.org" References: <3de14686-3a6f-b101-13a5-99654a338c90@htt-consult.com> From: Robert Moskowitz Message-ID: <16336299-b9a2-8c0a-52c5-a9227eca75ca@htt-consult.com> Date: Tue, 5 Sep 2017 11:36:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <3de14686-3a6f-b101-13a5-99654a338c90@htt-consult.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] Also date in reference X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 15:36:19 -0000 And got this: On 09/05/2017 10:43 AM, Robert Moskowitz wrote: > It did not like: > > 2011 > > Actually would like July, 2011 > > thanks > > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc > From nobody Tue Sep 5 10:19:30 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7D4132DD6 for ; Tue, 5 Sep 2017 10:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ilKZaDEqgp_J for ; Tue, 5 Sep 2017 10:19:26 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD8C132DA2 for ; Tue, 5 Sep 2017 10:19:26 -0700 (PDT) Received: from [10.0.0.6] (24-241-4-237.dhcp.buft.sc.charter.com [24.241.4.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id F18E71C4; Tue, 5 Sep 2017 13:19:09 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tom Pusateri In-Reply-To: <16336299-b9a2-8c0a-52c5-a9227eca75ca@htt-consult.com> Date: Tue, 5 Sep 2017 13:19:23 -0400 Cc: "xml2rfc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3411AB4B-EB97-40E2-9840-25D1EFB669B5@bangj.com> References: <3de14686-3a6f-b101-13a5-99654a338c90@htt-consult.com> <16336299-b9a2-8c0a-52c5-a9227eca75ca@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] Also date in reference X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 17:19:28 -0000 Which reminds me: Why isn=E2=80=99t the year optional? This works: and it fills in the day and month. Why can=E2=80=99t this work? It should fill in the day, month, and year. Tom > On Sep 5, 2017, at 11:36 AM, Robert Moskowitz = wrote: >=20 > And got this: >=20 > >=20 > On 09/05/2017 10:43 AM, Robert Moskowitz wrote: >> It did not like: >>=20 >> 2011 >>=20 >> Actually would like July, 2011 >>=20 >> thanks >>=20 >>=20 >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc >>=20 >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Tue Sep 5 10:59:53 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804CF132DFE for ; Tue, 5 Sep 2017 10:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 eTZ2TDKa4Ewq for ; Tue, 5 Sep 2017 10:59:50 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC898132DA2 for ; Tue, 5 Sep 2017 10:59:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3025462121; Tue, 5 Sep 2017 13:59:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QVT67hOcNwxG; Tue, 5 Sep 2017 13:59:43 -0400 (EDT) Received: from lx120e.htt-consult.com (148.sub-174-226-9.myvzw.com [174.226.9.148]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id CB90461FDA; Tue, 5 Sep 2017 13:59:42 -0400 (EDT) To: Tom Pusateri Cc: "xml2rfc@ietf.org" References: <3de14686-3a6f-b101-13a5-99654a338c90@htt-consult.com> <16336299-b9a2-8c0a-52c5-a9227eca75ca@htt-consult.com> <3411AB4B-EB97-40E2-9840-25D1EFB669B5@bangj.com> From: Robert Moskowitz Message-ID: Date: Tue, 5 Sep 2017 13:59:37 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <3411AB4B-EB97-40E2-9840-25D1EFB669B5@bangj.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] Also date in reference X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 17:59:51 -0000 On 09/05/2017 01:19 PM, Tom Pusateri wrote: > Which reminds me: > > Why isn’t the year optional? > > This works: > > and it fills in the day and month. > > Why can’t this work? > > > > It should fill in the day, month, and year. Then what indicates you do not want a date? Changing the behavior so that the date option with no sub-fields results in today's date would cause a lot of existing xml to suddenly start adding the date when none was wanted. Perhaps something like: Bob > > Tom > > >> On Sep 5, 2017, at 11:36 AM, Robert Moskowitz wrote: >> >> And got this: >> >> >> >> On 09/05/2017 10:43 AM, Robert Moskowitz wrote: >>> It did not like: >>> >>> 2011 >>> >>> Actually would like July, 2011 >>> >>> thanks >>> >>> >>> _______________________________________________ >>> xml2rfc mailing list >>> xml2rfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/xml2rfc >>> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc > From nobody Tue Sep 5 11:06:55 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82C6132E08 for ; Tue, 5 Sep 2017 11:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 grMWRNF3VQaa for ; Tue, 5 Sep 2017 11:06:52 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 BA349132E07 for ; Tue, 5 Sep 2017 11:06:52 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id h70so29384770oic.1 for ; Tue, 05 Sep 2017 11:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HlKgCfvD2FpCpOzLO7dr3q2y+yUjycPoQCcxEQYqGdk=; b=lGWB0nG07DqAB3XxQtpMHV7w/nedoUrnW9tuV3uvDrNYPv+c4ouLuG532J74lV0vWS IHV+Vc/86OTdaGq1UPN4lN2C6GpAtI7ijsWwZOrC6XeCvjunq01/NL/HqX94PbH/1jSR 5UyWj2EIVYU/s/EXtbm9eEEFj48bPQ4TzOItgYkzmgxQk25s/4YiBTJ1OdfB5FCXpAxA ii/UWDy90WFF0lr3WuHHBylQ9EmEuGBeje9SSPGQS21BKwVyzpZU93wcE8TakP2DWVnY eGEJSsFXFRhUxKh/GwtaT2Vf7S3fuU36XNF+YufIBa0X5V5QcKCcVGbopHB+PZGbp2gn qplA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HlKgCfvD2FpCpOzLO7dr3q2y+yUjycPoQCcxEQYqGdk=; b=ZA5TGgA0Nsh5DBkYivc5DpjP43NVchbqWVNJL7QZdNaYFR7GqeJ025OMGbErTQXThF pNyfC+jgS+EuEdpN1k+ni3rojWNezRQHyGhfWwl0I14NPczmPGrDvEJtyauRYa0y7eAs YdlDDq4wMKmCnNK/wxihmYQweG8Ee7J5jBLAdesR87DuIcgcpHxlRLTJRh4CcIE0ACV6 upLPQCpFjGXc7j6mnSMgPqiGN63n/vDwOUAqbceSmzXEhnO485qdZWcEtqrwgcPovmOb qye/wk5HgNUf0zBkgTjCEFG3iP6ylqhm96zz0jfIISxLFZfFVaGaSbU1d7amCjXBZXft J/5A== X-Gm-Message-State: AHPjjUgYKyadiCKRWjhHlzSRCfLPsUIXEdTmZDJhkSGVPijrVF0cMlld Phz5x+oaV/ZVSw== X-Google-Smtp-Source: ADKCNb7gWXI8VIPdL6cQ6Iflpjgwl+/QQO2Nu6D/rOAGOHXEw2qMLnbdztQ5HEiHsrDBkMeCcUHdhw== X-Received: by 10.202.10.22 with SMTP id 22mr4844286oik.102.1504634812012; Tue, 05 Sep 2017 11:06:52 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::1f43? ([2600:8802:5600:e::1f43]) by smtp.gmail.com with ESMTPSA id e18sm1499341oih.38.2017.09.05.11.06.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 11:06:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: Fred Baker In-Reply-To: Date: Tue, 5 Sep 2017 11:06:49 -0700 Cc: Tom Pusateri , "xml2rfc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <3de14686-3a6f-b101-13a5-99654a338c90@htt-consult.com> <16336299-b9a2-8c0a-52c5-a9227eca75ca@htt-consult.com> <3411AB4B-EB97-40E2-9840-25D1EFB669B5@bangj.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [xml2rfc] Also date in reference X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 18:06:54 -0000 > On Sep 5, 2017, at 10:59 AM, Robert Moskowitz = wrote: >=20 >> Why can=E2=80=99t this work? >>=20 >> >>=20 >> It should fill in the day, month, and year. >=20 > Then what indicates you do not want a date? Changing the behavior so = that the date option with no sub-fields results in today's date would = cause a lot of existing xml to suddenly start adding the date when none = was wanted. Perhaps something like: Current (v2) xml2rfc accepts as "insert today's date", in the = metadata for the draft. I'm OK with , but that means I have = to change every XML file I'm using.= From nobody Tue Sep 5 11:17:16 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FCF132E01 for ; Tue, 5 Sep 2017 11:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OF4ebMqzQRwz for ; Tue, 5 Sep 2017 11:17:13 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49435132D61 for ; Tue, 5 Sep 2017 11:17:13 -0700 (PDT) Received: from [10.84.164.162] (mobile-166-170-55-220.mycingular.net [166.170.55.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id DD2001D7; Tue, 5 Sep 2017 14:16:57 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Tom Pusateri X-Mailer: iPhone Mail (15A5370a) In-Reply-To: Date: Tue, 5 Sep 2017 14:17:10 -0400 Cc: "xml2rfc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9ADC7325-70F9-4323-A8C0-BC29E07B76BA@bangj.com> References: <3de14686-3a6f-b101-13a5-99654a338c90@htt-consult.com> <16336299-b9a2-8c0a-52c5-a9227eca75ca@htt-consult.com> <3411AB4B-EB97-40E2-9840-25D1EFB669B5@bangj.com> To: Robert Moskowitz Archived-At: Subject: Re: [xml2rfc] Also date in reference X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 18:17:14 -0000 I remember trying And it didn=E2=80=99t give me Today=E2=80=99s date but I=E2=80=99ll try it a= gain. I don=E2=80=99t care about not having a date on a draft. Why would you= want that? Tom > On Sep 5, 2017, at 1:59 PM, Robert Moskowitz wrote: >=20 >=20 >=20 >> On 09/05/2017 01:19 PM, Tom Pusateri wrote: >> Which reminds me: >>=20 >> Why isn=E2=80=99t the year optional? >>=20 >> This works: >>=20 >> and it fills in the day and month. >>=20 >> Why can=E2=80=99t this work? >>=20 >> >>=20 >> It should fill in the day, month, and year. >=20 > Then what indicates you do not want a date? Changing the behavior so that= the date option with no sub-fields results in today's date would cause a lo= t of existing xml to suddenly start adding the date when none was wanted. P= erhaps something like: >=20 > >=20 > Bob >>=20 >> Tom >>=20 >>=20 >>> On Sep 5, 2017, at 11:36 AM, Robert Moskowitz wrot= e: >>>=20 >>> And got this: >>>=20 >>> >>>=20 >>>> On 09/05/2017 10:43 AM, Robert Moskowitz wrote: >>>> It did not like: >>>>=20 >>>> 2011 >>>>=20 >>>> Actually would like July, 2011 >>>>=20 >>>> thanks >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> xml2rfc mailing list >>>> xml2rfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/xml2rfc >>>>=20 >>> _______________________________________________ >>> xml2rfc mailing list >>> xml2rfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/xml2rfc >>=20 >=20 From nobody Tue Sep 5 11:33:46 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AA4132E01 for ; Tue, 5 Sep 2017 11:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 a3xt6AXv7XBh for ; Tue, 5 Sep 2017 11:33:42 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD97120720 for ; Tue, 5 Sep 2017 11:33:42 -0700 (PDT) Received: from [10.84.164.162] (mobile-166-170-55-220.mycingular.net [166.170.55.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id AC4FC1DB; Tue, 5 Sep 2017 14:33:26 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Tom Pusateri Mime-Version: 1.0 (1.0) Date: Tue, 5 Sep 2017 14:24:20 -0400 Message-Id: <10E424CC-A480-455B-8AF2-953511772226@bangj.com> References: <3de14686-3a6f-b101-13a5-99654a338c90@htt-consult.com> <16336299-b9a2-8c0a-52c5-a9227eca75ca@htt-consult.com> <3411AB4B-EB97-40E2-9840-25D1EFB669B5@bangj.com> <9ADC7325-70F9-4323-A8C0-BC29E07B76BA@bangj.com> Cc: "xml2rfc@ietf.org" In-Reply-To: <9ADC7325-70F9-4323-A8C0-BC29E07B76BA@bangj.com> To: Robert Moskowitz X-Mailer: iPhone Mail (15A5370a) Archived-At: Subject: Re: [xml2rfc] Also date in reference X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 18:33:44 -0000 Plus, if you don=E2=80=99t want a date, then don=E2=80=99t put a date object= in your document at all.=20 Tom > On Sep 5, 2017, at 2:17 PM, Tom Pusateri wrote: >=20 > I remember trying >=20 > >=20 > And it didn=E2=80=99t give me Today=E2=80=99s date but I=E2=80=99ll try it= again. I don=E2=80=99t care about not having a date on a draft. Why would y= ou want that? >=20 > Tom >=20 >> On Sep 5, 2017, at 1:59 PM, Robert Moskowitz wrote:= >>=20 >>=20 >>=20 >>> On 09/05/2017 01:19 PM, Tom Pusateri wrote: >>> Which reminds me: >>>=20 >>> Why isn=E2=80=99t the year optional? >>>=20 >>> This works: >>>=20 >>> and it fills in the day and month.= >>>=20 >>> Why can=E2=80=99t this work? >>>=20 >>> >>>=20 >>> It should fill in the day, month, and year. >>=20 >> Then what indicates you do not want a date? Changing the behavior so tha= t the date option with no sub-fields results in today's date would cause a l= ot of existing xml to suddenly start adding the date when none was wanted. P= erhaps something like: >>=20 >> >>=20 >> Bob >>>=20 >>> Tom >>>=20 >>>=20 >>>> On Sep 5, 2017, at 11:36 AM, Robert Moskowitz wro= te: >>>>=20 >>>> And got this: >>>>=20 >>>> >>>>=20 >>>>> On 09/05/2017 10:43 AM, Robert Moskowitz wrote: >>>>> It did not like: >>>>>=20 >>>>> 2011 >>>>>=20 >>>>> Actually would like July, 2011 >>>>>=20 >>>>> thanks >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> xml2rfc mailing list >>>>> xml2rfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/xml2rfc >>>>>=20 >>>> _______________________________________________ >>>> xml2rfc mailing list >>>> xml2rfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/xml2rfc >>>=20 >>=20 >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Tue Sep 5 13:13:26 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A46B129A89 for ; Tue, 5 Sep 2017 13:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, 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 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 gkN9HKYMuQer for ; Tue, 5 Sep 2017 13:13:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 4FF1513202D for ; Tue, 5 Sep 2017 13:13:24 -0700 (PDT) Received: from [192.168.178.20] ([93.217.72.42]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MNq4h-1dqj7i1zkB-007VYz; Tue, 05 Sep 2017 22:13:13 +0200 To: Tom Pusateri , Robert Moskowitz Cc: "xml2rfc@ietf.org" References: <3de14686-3a6f-b101-13a5-99654a338c90@htt-consult.com> <16336299-b9a2-8c0a-52c5-a9227eca75ca@htt-consult.com> <3411AB4B-EB97-40E2-9840-25D1EFB669B5@bangj.com> <9ADC7325-70F9-4323-A8C0-BC29E07B76BA@bangj.com> <10E424CC-A480-455B-8AF2-953511772226@bangj.com> From: Julian Reschke Message-ID: <8882ecbf-89b7-a7fe-3657-fdd55437ef9a@gmx.de> Date: Tue, 5 Sep 2017 22:13:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <10E424CC-A480-455B-8AF2-953511772226@bangj.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:uRLxAWgS+hJun5pR85pvFKJ4iFwbR7xgWZtlLOWZPUY4Gue4h7p PqkDncCCnpJkqGNaS7ojwermIemoOcb4u/i6ZTPEjnOvyh5IZUsh+Jup8hM4FuV1h5ev/Eb flUx3+mmoZebIpORY2BZZRlAyPQaN0yOKuXQ59hjTDbfjCe2PT3AGUNhthdXhWf2xc8xHLV +cZQRcoWv4HI8pyhmOW5w== X-UI-Out-Filterresults: notjunk:1;V01:K0:8eQONYtUGJE=:8WRVfCa13Sl1XTRCzIGKYw oOAgV2QDOMDIsTVTsCnNfAoKx1KbsRcGkeA9iccplV5kgTYXLQ6vd/bmD512QLnTItPGLAhrA Xng2JEy7OURzdXjZuf4SS3h3Kx5Dq4o2Yl2xUvMCjspq/IJaNLJ+mjJXzCBmY18R3C/gs4ehj /IZvu/MzfvommOQs8SS3L8IyYbVqP4y2Cv6KenN1eMbXA7t+HVmvYLkAqcVNRRtqZe9NRmISt EribhO173dMiHyRrhnZ0qo/9eAJsI9MSrfS+LpNHePehONcje1EFIxlk+8NazLyP/vFz4EA9y exGzic9CxIU+7ed9YPcT2AzZGS6nczwn6HSB96TNxBIlz3tkXAm09mswo76zXoNp1Wy7Up9w0 WrcfgE9UsXaEukeQYbPXOKpNM+WR0RProwxbzZzeAfdSQ5K0z37XT3XtMi7//iX5AxeitZTIr Qp6HXCQHPn3QcMLd3YmPx86QxALeVRBUel/z1/KkpycsCrVxOlUD48VDROa2PMM0EEiYVVJy8 ZcfhDRb/vz6ljOfPzUtSVaxCM3dCHPJ6NteTYwWvWjT+7SC2HfY7PgxFKBa1eZ6hVMq3iF9B8 SEjF7xKO0zHZMQl1jiFpZpyVcyBxf4TRIbY/K5hZWnk5v0WgX7ms1s4JFwhewflIwbnZ1bkQq MqIrRlK/D26QrKAhAyR8wOfGeNrVYcearLnO3Ktkc61ExWoyche5PI8dwYAMtbcuWfUMzsi/0 a4jTwm8hra3gjFKOG3P3/QQ25ePAdzZVOy8JJZhcV/cAQ0IHkiDbXjUAP6PB+jFtuT6K0uT4z Qcpcbzt0MFvBJadqAiWmogwNxxO2mOBr1GMlOCCjkQMLhWQhRQ= Archived-At: Subject: Re: [xml2rfc] Also date in reference X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 20:13:26 -0000 On 2017-09-05 20:24, Tom Pusateri wrote: > Plus, if you don’t want a date, then don’t put a date object in your document at all. > > Tom In XML2RFC, the date object is required but can be empty. Yes, that's silly. See . Best regards, Julian From nobody Wed Sep 6 02:18:04 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EE8132623 for ; Wed, 6 Sep 2017 02:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=messagingengine.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 iPtt1iOKQuwJ for ; Wed, 6 Sep 2017 02:18:01 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795E41323B4 for ; Wed, 6 Sep 2017 02:18:01 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C6D1E20BF9 for ; Wed, 6 Sep 2017 05:18:00 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute1.internal (MEProxy); Wed, 06 Sep 2017 05:18:00 -0400 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; s=fm1; bh=POVknTJS8AD7Nh7EcdFlUINkNKB6w 9rKqOHxRBdumKA=; b=rBuvQzYonF+vzb+BhpgFROJ50t/J3XreDaEJAXm4816I/ YkjjQRv1K5EcBt5sR7EOnFC4dPxylz45/QsIl9lMYETmTGvFD3/Wvu6LcvUeStEv DEUujIwgNq4xhxzSPAQ8Zn9lD01xDFZQuoCx10qwp8tFTp9e8Y7OdHEUEONU2M7e o9QQuyLd1b2+Ckkre543fpvJnDfWVA5OMHtIg1s5ye0WT2QrrMfRkgxQnE74yQ84 hFPnim45xP8K9RsLNcKIXxs8NzBdLKXHDzd6Yhr03Y9DtouRkgj3W0PCvaMn5hul fcgTpeoeYWQZAvxEPJU8AAmq0XWUziHazunuitrqQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8C4119578C; Wed, 6 Sep 2017 05:18:00 -0400 (EDT) Message-Id: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> From: Robert Stepanek To: xml2rfc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/mixed; boundary="_----------=_150468948015110332" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f7b75467 Date: Wed, 06 Sep 2017 11:18:00 +0200 Archived-At: Subject: [xml2rfc] Spacing between texttable cells X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 09:18:03 -0000 This is a multi-part message in MIME format. --_----------=_150468948015110332 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi, I am new to xml2rfc and look for help on a how to format the spacing between cells. All RFC documents, drafts and examples on the IETF site seem to insert an empty line between two rows within a table. Yet, when I run the XML source of these examples through my local xml2rfc installation (version 2.5.1) or the web version, there are *no* spaces inserted between consecutive rows in the table. I wouldn't fret about layout that much, but my tables are rather long and have multi-line cells. Without spacing it would diminish legibility up to a point that I might switch to using sections. E.g. I tested it with this example of the IETF presentation on RFC editing tools [1]. Note how the example in the PDF has empty lines between rows. The same table in XML IETF # City # of Attendees 62Minneapolis1133 63Paris1450 64Vancouver1240 Data from http://www.ietf.org/meeting/past.html doesn't insert spaces in my xml2rfc installation. There's also an example in section 2.3.1.4. in the RFC draft on RFC XML formatting [2]. I attached a complete XML draft document to this mail which includes both examples and reproduces the missing spaces in the online xml2rfc tool. What am I missing? Thanks, Robert [1] https://www.rfc-editor.org/materials/tools_ids_rfcs_94.pdf [2] https://xml2rfc.tools.ietf.org/authoring/xml2rfc-1.32/draft-mrose-writing-rfcs.txt --_----------=_150468948015110332 Content-Disposition: attachment; filename="test.xml" Content-Id: <1504689251.1510311.c5fd46b52728ed1ea18408e431d7030a444511ab.428EAEC5@content.messagingengine.com> Content-Transfer-Encoding: base64 Content-Type: text/xml; name="test.xml" PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NU WVBFIHJmYyBTWVNURU0gInJmYzI2MjkuZHRkIj4KPHJmYyBpcHI9InRydXN0 MjAwOTAyIiBjYXRlZ29yeT0ic3RkIiBkb2NOYW1lPSJkcmFmdC10ZXh0dGFi bGUtdGVzdCI+CiAgICA8P3JmYyB0b2M9InllcyI/PgogICAgPD9yZmMgc3lt cmVmcz0ieWVzIj8+CiAgICA8P3JmYyBzb3J0cmVmcz0ieWVzIj8+CiAgICA8 P3JmYyBjb21wYWN0PSJ5ZXMiPz4KICAgIDw/cmZjIHN1YmNvbXBhY3Q9Im5v Ij8+CiAgICA8P3JmYyBwcml2YXRlPSIiPz4KICAgIDw/cmZjIHRvcGJsb2Nr PSJ5ZXMiPz4KICAgIDw/cmZjIGNvbW1lbnRzPSJubyI/PgoKICAgIDxmcm9u dD4KICAgICAgICA8dGl0bGUgYWJicmV2PSJ0ZXN0Ij5BIHRlc3Qgb2YgdGV4 dHRhYmxlPC90aXRsZT4KICAgICAgICA8YXV0aG9yIGluaXRpYWxzPSJSLiIg c3VybmFtZT0iU3RlcGFuZWsiIGZ1bGxuYW1lPSJSb2JlcnQgU3RlcGFuZWsi PgogICAgICAgICAgICA8b3JnYW5pemF0aW9uPnRlc3Q8L29yZ2FuaXphdGlv bj4KICAgICAgICA8L2F1dGhvcj4KICAgICAgICA8ZGF0ZSB5ZWFyPSIyMDE3 IiBtb250aD0iU2VwdGVtYmVyIiBkYXk9IjUiLz4KICAgICAgICA8YWJzdHJh Y3Q+CiAgICAgICAgICAgIDx0PlRoaXMgdGVzdHMgc3BhY2luZyBpbiB0ZXh0 dGFibGUgZm9ybWF0dGluZzwvdD4KICAgICAgICA8L2Fic3RyYWN0PgogICAg PC9mcm9udD4KCiAgICA8bWlkZGxlPgogICAgICA8c2VjdGlvbiBhbmNob3I9 ImludHJvZHVjdGlvbiIgdGl0bGU9IkludHJvZHVjdGlvbiI+CiAgICAgICAg PHRleHR0YWJsZSBhbmNob3I9InRhYmxlX2V4IiB0aXRsZT0iSUVURiBNZWV0 aW5ncyBpbiAyMDA1Ij4KICAgICAgICAgIDx0dGNvbCBhbGlnbj0iY2VudGVy Ij5JRVRGICM8L3R0Y29sPgogICAgICAgICAgPHR0Y29sIGFsaWduPSJjZW50 ZXIiPkNpdHk8L3R0Y29sPgogICAgICAgICAgPHR0Y29sIGFsaWduPSJjZW50 ZXIiPiMgb2YgQXR0ZW5kZWVzPC90dGNvbD4KICAgICAgICAgIDxjPjYyPC9j PjxjPk1pbm5lYXBvbGlzPC9jPjxjPjExMzM8L2M+CiAgICAgICAgICA8Yz42 MzwvYz48Yz5QYXJpczwvYz48Yz4xNDUwPC9jPgogICAgICAgICAgPGM+NjQ8 L2M+PGM+VmFuY291dmVyPC9jPjxjPjEyNDA8L2M+CiAgICAgICAgICA8cG9z dGFtYmxlPkRhdGEgZnJvbSBodHRwOi8vd3d3LmlldGYub3JnL21lZXRpbmcv cGFzdC5odG1sPC9wb3N0YW1ibGU+CiAgICAgICAgPC90ZXh0dGFibGU+CiAg ICAgICAgPHRleHR0YWJsZSBhbmNob3I9J3RhYmxlX2V4YW1wbGUnPgogICAg ICAgICAgPHByZWFtYmxlPlNvLAogICAgICAgICAgICBwdXR0aW5nIGl0IGFs bCB0b2dldGhlciwgd2UgaGF2ZSwgZS5nLiw8L3ByZWFtYmxlPgogICAgICAg ICAgPHR0Y29sIGFsaWduPSdjZW50ZXInPnR0Y29sICMxPC90dGNvbD4KICAg ICAgICAgIDx0dGNvbCBhbGlnbj0nY2VudGVyJz50dGNvbCAjMjwvdHRjb2w+ CiAgICAgICAgICA8Yz5jICMxPC9jPgogICAgICAgICAgPGM+YyAjMjwvYz4K ICAgICAgICAgIDxjPmMgIzM8L2M+CiAgICAgICAgICA8Yz5jICM0PC9jPgog ICAgICAgICAgPGM+YyAjNTwvYz4KICAgICAgICAgIDxjPmMgIzY8L2M+CiAg ICAgICAgICA8cG9zdGFtYmxlPndoaWNoIGlzIGEgdmVyeSBzaW1wbGUgZXhh bXBsZS48L3Bvc3RhbWJsZT4KICAgICAgICA8L3RleHR0YWJsZT4KICAgICAg PC9zZWN0aW9uPgogICAgPC9taWRkbGU+CgogICAgPGJhY2svPgo8L3JmYz4K --_----------=_150468948015110332-- From nobody Wed Sep 6 02:37:04 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453D313247A for ; Wed, 6 Sep 2017 02:37:03 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 7oKBVwXj_k61 for ; Wed, 6 Sep 2017 02:37:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 509CA1323B4 for ; Wed, 6 Sep 2017 02:37:00 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Ltqmn-1dNaLL3kPt-0117yW; Wed, 06 Sep 2017 11:36:54 +0200 To: Robert Stepanek , xml2rfc@ietf.org References: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> From: Julian Reschke Message-ID: <42bef5c2-ba8d-9e27-6332-be6329e0fd48@gmx.de> Date: Wed, 6 Sep 2017 11:36:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:GAp/k9quEwV8C9Zqtzx4lIlrf7L2zzfvTv0sUDaliIMEAEh1kTX kRIIbGc5aIYNWrS78ipRgEiLPHLkF/utIvaw6DRLOzxemsbufoJyzN/f/WxGMElWitDmcp0 nibjOWL/xb9xgV+GnLCBlYk+UKvw4u212JI3yAN2uiRpBv0K+jkB+ffJURrBXdD7gIUtheY tFMOkOpZqkGDjY2puI0cA== X-UI-Out-Filterresults: notjunk:1;V01:K0:u+SFjKuhg8A=:mFWhBpOAMrAUXHQNGPbhws hOglTU1GzRX//2GimZ/yFZAjNSkzp70yBAiPwKKJYxrB0DlJcLDCipAv8OrI3n0sd7xUXwI36 5EwBjCLhlJYyddv17Dv4VkhmhkNTpOdAabuCTNt5tKrdyzElrKqSTkLWgHecLXJWQsqDmIZMI IDeKeq6FWceFbsnpOS3N1DO5QjKLw1xAd8SeD6wEH2B/CvJ4YSc8KsyBqn8t71dTGaVKSkMFU 0O0BH0FjZ6ctD0tu/yEAbEzcddTaGUa8Z3SEyd8UI8Gpe3p1aUANZLodQdTDmSDZFeawsRZ+Q 1np/RsLn3C4lbNCjvgQX1oLVEZgJD7IY5Oe0F+6TTEt0/1zBYkRIJO/Q1eEk82P6GqmPEmU7g u42ZvOON2+LzcZNmhCS4eH7MMCfe1yjTp33FUtoDsq0j8tRQLmUCEBClZ27t3Pcbi8XxHxGkM OWmbXUcWEzapTock5IqCXv+yvyh++g0Fx61OvdIsee1UjnQ+pv0PbYTOOc7oBudptA+h6adlA 0S2ja7XkGAbbVW6JK5AiOOy7W/zLPHYKOWQj/VBWHo+0z0zJmnu/LyMJQZWn2QNyxbwisQ91H TG1eiaWghEkMycfTZZrghIZpFPb/G5Kgs/epTdPMfoyWpZyy3TtwVH3Nf0Eu54xi9cKMp6/S2 mu4l7NiTaUzIIdDzoUXA4kwz8ZrbxVTlQa4joMIobehAK0OoNC7rZXN5xBnUCe4xtz8FXTOVA 4jf5Zgnyu5BRqHhJs6n6ugVNLappVgIiZ+3eUvh38wGdQHanyGG5ucVqKgs2RK/IuEMc1+Ase luaswd7X5fwhX/57VhKNCpzMiCP0eZBBFc7v42x5bqrX1nqQ9A= Archived-At: Subject: Re: [xml2rfc] Spacing between texttable cells X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 09:37:03 -0000 On 2017-09-06 11:18, Robert Stepanek wrote: > Hi, > > I am new to xml2rfc and look for help on a how to format the spacing > between cells. > > All RFC documents, drafts and examples on the IETF site seem to insert > an empty line between two rows within a table. Yet, when I run the XML Example? > source of these examples through my local xml2rfc installation (version > 2.5.1) or the web version, there are *no* spaces inserted between > consecutive rows in the table. The current version is 2.8, FWIW... > I wouldn't fret about layout that much, but my tables are rather long > and have multi-line cells. Without spacing it would diminish legibility > up to a point that I might switch to using sections. > ... You should be able to get separator lines using . Best regards, Julian From nobody Wed Sep 6 02:42:45 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE47132707 for ; Wed, 6 Sep 2017 02:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 SFuSSZR8BAnz for ; Wed, 6 Sep 2017 02:42:42 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B10132386 for ; Wed, 6 Sep 2017 02:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v869gLRZ016677; Wed, 6 Sep 2017 11:42:21 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xnJXF1w6qzDKvw; Wed, 6 Sep 2017 11:42:21 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> Date: Wed, 6 Sep 2017 11:42:20 +0200 Cc: xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 526383740.081826-83d19393edf71c075f7cf7d40c91b6dd Content-Transfer-Encoding: quoted-printable Message-Id: <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> References: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> To: Robert Stepanek X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] Spacing between texttable cells X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 09:42:44 -0000 Hi Robert, > Yet, when I run the XML > source of these examples through my local xml2rfc installation = (version > 2.5.1) or the web version, there are *no* spaces inserted between > consecutive rows in the table. To make our life easier answering questions, please upgrade, e.g.: pip2 install =E2=80=94upgrade xml2rfc (pip2 may be called pip on your machine.) While we are talking about upgrades: The current XML2RFC v2 spec (soon = to be superseded by v3) is in RFC 7749. No need to consult = Internet-Drafts from 2006 :-) (Yes, we have to get better in hiding these historically interesting, = but misleading documents.) Now to the table spacing: In XML2RFC v2, some presentation features are controlled by PIs (XML = processing instructions). Depending on whether the PI =E2=80=98compact=E2=80=99 is set to yes or = no, a blank row is inserted between rows of table cells. Example (in kramdown-rfc, because I don=E2=80=99t write XML any more): | Length ll | uint | sint | float *foo* | | 0 | *uint8* | sint8 | binary16 | | 1 | uint16 | sint16 | binary32 | | 2 | uint32 | sint32 | binary64 | | 3 | uint64 | sint64 | binary128 | {: #lengths-compact title=3D"Length values"} | Length ll | uint | sint | float *foo* | | 0 | *uint8* | sint8 | binary16 | | 1 | uint16 | sint16 | binary32 | | 2 | uint32 | sint32 | binary64 | | 3 | uint64 | sint64 | binary128 | {: #lengths-spacey title=3D"Length values"} generates: +-----------+---------+--------+-----------+ | Length ll | uint | sint | float | +-----------+---------+--------+-----------+ | 0 | _uint8_ | sint8 | binary16 | | 1 | uint16 | sint16 | binary32 | | 2 | uint32 | sint32 | binary64 | | 3 | uint64 | sint64 | binary128 | +-----------+---------+--------+-----------+ Table 1: Length values +-----------+---------+--------+-----------+ | Length ll | uint | sint | float | +-----------+---------+--------+-----------+ | 0 | _uint8_ | sint8 | binary16 | | | | | | | 1 | uint16 | sint16 | binary32 | | | | | | | 2 | uint32 | sint32 | binary64 | | | | | | | 3 | uint64 | sint64 | binary128 | +-----------+---------+--------+-----------+ Table 2: Length values Right, this is not said anywhere in RFC 7749. But of course we have the source of the xml2rfc formatter :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Sep 6 02:49:19 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025A4132707 for ; Wed, 6 Sep 2017 02:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=messagingengine.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 ea_b2PhUuvkD for ; Wed, 6 Sep 2017 02:49:16 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3C4D1323B4 for ; Wed, 6 Sep 2017 02:49:16 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1539E20F02 for ; Wed, 6 Sep 2017 05:49:16 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute1.internal (MEProxy); Wed, 06 Sep 2017 05:49:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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; s=fm1; bh=JHXURj EDFaOt7e/Am0txGqQxj7OtQvamW6/+FAUpdJI=; b=eZw3tHehpEQlgarTbbOP71 WreDs+50HG/HjRP06RqxgGTuEJxU4M9SRITkx4h2ILW37UHLmpHW7y7XNYlbNO2m eTK0q39ZMyOyD8ejmn6fAEwgPnFbZGKQGUl91hY+Hvd/M63M4vQ5bP27zdK/dSqG xS7FwTgQlnubrc7JNVjI1QzB6nhnvVldul1kxGebpzEdSEyrpWUKR45t+7Ea/N1m aHsldWVB3AX28Qvtg06hV1ku1s2Om+lU9qmUfGjYaG/zb3BXIWH0pAD751j0ySES SmVGb/+GfgcQk//cnz5lZGzpLQP1B3jwDBjR7EtQuLwmBsoLf5w7RI2sdlSSP/dA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E2DD79578C; Wed, 6 Sep 2017 05:49:15 -0400 (EDT) Message-Id: <1504691355.1516197.1096854952.2532D682@webmail.messagingengine.com> From: Robert Stepanek To: xml2rfc@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f7b75467 Date: Wed, 06 Sep 2017 11:49:15 +0200 References: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> In-Reply-To: <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> Archived-At: Subject: Re: [xml2rfc] Spacing between texttable cells X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 09:49:18 -0000 Thanks Carsten! did the trick. Cheers, Robert On Wed, Sep 6, 2017, at 11:42, Carsten Bormann wrote: > Hi Robert, >=20 > > Yet, when I run the XML > > source of these examples through my local xml2rfc installation (version > > 2.5.1) or the web version, there are *no* spaces inserted between > > consecutive rows in the table. >=20 > To make our life easier answering questions, please upgrade, e.g.: >=20 > pip2 install =E2=80=94upgrade xml2rfc >=20 > (pip2 may be called pip on your machine.) >=20 > While we are talking about upgrades: The current XML2RFC v2 spec (soon to > be superseded by v3) is in RFC 7749. No need to consult Internet-Drafts > from 2006 :-) >=20 > (Yes, we have to get better in hiding these historically interesting, but > misleading documents.) >=20 > Now to the table spacing: >=20 > In XML2RFC v2, some presentation features are controlled by PIs (XML > processing instructions). > Depending on whether the PI =E2=80=98compact=E2=80=99 is set to yes or no= , a blank row is > inserted between rows of table cells. >=20 > Example (in kramdown-rfc, because I don=E2=80=99t write XML any more): >=20 >=20 > >=20 > | Length ll | uint | sint | float *foo* | > | 0 | *uint8* | sint8 | binary16 | > | 1 | uint16 | sint16 | binary32 | > | 2 | uint32 | sint32 | binary64 | > | 3 | uint64 | sint64 | binary128 | > {: #lengths-compact title=3D"Length values"} >=20 > >=20 > | Length ll | uint | sint | float *foo* | > | 0 | *uint8* | sint8 | binary16 | > | 1 | uint16 | sint16 | binary32 | > | 2 | uint32 | sint32 | binary64 | > | 3 | uint64 | sint64 | binary128 | > {: #lengths-spacey title=3D"Length values"} >=20 >=20 > generates: >=20 > +-----------+---------+--------+-----------+ > | Length ll | uint | sint | float | > +-----------+---------+--------+-----------+ > | 0 | _uint8_ | sint8 | binary16 | > | 1 | uint16 | sint16 | binary32 | > | 2 | uint32 | sint32 | binary64 | > | 3 | uint64 | sint64 | binary128 | > +-----------+---------+--------+-----------+ >=20 > Table 1: Length values >=20 > +-----------+---------+--------+-----------+ > | Length ll | uint | sint | float | > +-----------+---------+--------+-----------+ > | 0 | _uint8_ | sint8 | binary16 | > | | | | | > | 1 | uint16 | sint16 | binary32 | > | | | | | > | 2 | uint32 | sint32 | binary64 | > | | | | | > | 3 | uint64 | sint64 | binary128 | > +-----------+---------+--------+-----------+ >=20 > Table 2: Length values >=20 >=20 > Right, this is not said anywhere in RFC 7749. > But of course we have the source of the xml2rfc formatter :-) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 From nobody Wed Sep 6 03:45:26 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822511323A3 for ; Wed, 6 Sep 2017 03:45:25 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Wj5Orl9OVvF6 for ; Wed, 6 Sep 2017 03:45:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 A49E31321C9 for ; Wed, 6 Sep 2017 03:45:23 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LnxVE-1dIOru18lU-00g35k; Wed, 06 Sep 2017 12:45:10 +0200 To: Carsten Bormann , Robert Stepanek Cc: xml2rfc@ietf.org References: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> From: Julian Reschke Message-ID: Date: Wed, 6 Sep 2017 12:45:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:qedQM2bneEO+o7e/fI7iRmtABrF5d60Zu+IOGwNwEgv076wug1D HRj01tEyRhrzx5YBUG0c1g/glQpPOr+XOtmBDhwswUwsUZ9iO7OCyv2D/MAvM6T+sKPjJMI u9xjx8lXOP+oNkuZZ9FdwQkmz9S7qhsODMiVQWyCGqF1AS+LL+Mwv9QykQz96RC4c8eABMv BMBOw2P4mGYfowh+9416w== X-UI-Out-Filterresults: notjunk:1;V01:K0:LSX0PGt5Prw=:FjmA20lS/mxmC9xmroJZSe 5SJw8uBpC/TqOh91CVfbH2L8CkBDMRkLQ8HMl6tybjanvCrDUsZ9SOPy5+AmUptDIKLmM1e5b NrqjRXq0ZETmS5x9aHMUOyfqqAnJZarthSS2OUSVsixX7DpXDUH6GrkE3UXIIsrvrRM/rhTpt o1nLQVPXJyHkN0bYzz5GmssDFElYsdxedOitTt/Skb3Kjk4R2bg23Rm8ZexBt+NUh5rP+tZKG oGO90/2AdsTuvxD/pTajNx31Fca/bO78q9Omi9fxtnJsF2PBMmiC/3gCkODzgCuMJXeY3jJo3 rynTzzuYWLRw6C2XFIFAss6mw7FZARJ7IJXf6zz4G+t1dy44LUwJSIOWt+yKsgxlraCHPuu87 w/1TWJ9aSqzVfib5PBEcFDJ4vHAmEgs7FZ2o6D4SxhuNoE5x85iraX1qu2Afdx7QsBPCPOtbc 41DTBNKkl6LMRdBvXsSCjQL3dx5hoNFZy1wZNx4yH9J0TwVtf1jg8Af/1Y+rx72ICLphCatQ3 fUHXp7IQHTcVliQXAqDpjT24m94ZFJqhjYGx7UE63mVlCQRbRA7sS9v45UU5RB/bjxPImS7KC DyGRWpcrhlMTyQkE+4xMOH0kbbZLTpjTcQcwvlufIMG5J1FPQWKRkBwJH6clP4BYZfxVzkrit I2U+JT/R9ngnYXKBRjGY3haKpHgstOtMF//trZvByDUD9JwZ6QsniUWvzotckDaU5phsBxa8a CuB+NEwCKkL4zLOFiNja+2c5Q6Y+LmChhkUqGU2HZqc5sVAFoAmJqyQTtuFXC3bF++/8y8ikD bRv30qLFXIznfFTzxhn6LGWKlllP2KvUl06P0R5H3N4w+QrSBA= Archived-At: Subject: Re: [xml2rfc] Spacing between texttable cells X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 10:45:25 -0000 On 2017-09-06 11:42, Carsten Bormann wrote: > Hi Robert, > >> Yet, when I run the XML >> source of these examples through my local xml2rfc installation (version >> 2.5.1) or the web version, there are *no* spaces inserted between >> consecutive rows in the table. > > To make our life easier answering questions, please upgrade, e.g.: > > pip2 install —upgrade xml2rfc > > (pip2 may be called pip on your machine.) > > While we are talking about upgrades: The current XML2RFC v2 spec (soon to be superseded by v3) is in RFC 7749. No need to consult Internet-Drafts from 2006 :-) > > (Yes, we have to get better in hiding these historically interesting, but misleading documents.) > > Now to the table spacing: > > In XML2RFC v2, some presentation features are controlled by PIs (XML processing instructions). > Depending on whether the PI ‘compact’ is set to yes or no, a blank row is inserted between rows of table cells. I wasn't aware that PIs affect table formatting; interesting. > Example (in kramdown-rfc, because I don’t write XML any more): > > > > > | Length ll | uint | sint | float *foo* | > | 0 | *uint8* | sint8 | binary16 | > | 1 | uint16 | sint16 | binary32 | > | 2 | uint32 | sint32 | binary64 | > | 3 | uint64 | sint64 | binary128 | > {: #lengths-compact title="Length values"} > > > > | Length ll | uint | sint | float *foo* | > | 0 | *uint8* | sint8 | binary16 | > | 1 | uint16 | sint16 | binary32 | > | 2 | uint32 | sint32 | binary64 | > | 3 | uint64 | sint64 | binary128 | > {: #lengths-spacey title="Length values"} > > > generates: > > +-----------+---------+--------+-----------+ > | Length ll | uint | sint | float | > +-----------+---------+--------+-----------+ > | 0 | _uint8_ | sint8 | binary16 | > | 1 | uint16 | sint16 | binary32 | > | 2 | uint32 | sint32 | binary64 | > | 3 | uint64 | sint64 | binary128 | > +-----------+---------+--------+-----------+ > > Table 1: Length values > > +-----------+---------+--------+-----------+ > | Length ll | uint | sint | float | > +-----------+---------+--------+-----------+ > | 0 | _uint8_ | sint8 | binary16 | > | | | | | > | 1 | uint16 | sint16 | binary32 | > | | | | | > | 2 | uint32 | sint32 | binary64 | > | | | | | > | 3 | uint64 | sint64 | binary128 | > +-----------+---------+--------+-----------+ > > Table 2: Length values > > > Right, this is not said anywhere in RFC 7749. RFC 7749 describes the vocabulary, not processor-specific processing instructions... Also note that V3 deprecates in favor of , removing *all* styling options. Feedback on that should be sent before it's too late :-) > But of course we have the source of the xml2rfc formatter :-) Yup. Best regards, Julian From nobody Wed Sep 6 04:01:39 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446251323A3 for ; Wed, 6 Sep 2017 04:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 3b6RCPMS0xrk for ; Wed, 6 Sep 2017 04:01:37 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63DA1321AC for ; Wed, 6 Sep 2017 04:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v86B1Wfb021633; Wed, 6 Sep 2017 13:01:32 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xnLHc36GTzDKxP; Wed, 6 Sep 2017 13:01:32 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Wed, 6 Sep 2017 13:01:31 +0200 Cc: XML2RFC Interest Group X-Mao-Original-Outgoing-Id: 526388491.778971-b50c5e0881bb9fb3d9e47b884158c9d9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> To: Julian Reschke X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] Spacing between texttable cells X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 11:01:38 -0000 On Sep 6, 2017, at 12:45, Julian Reschke wrote: >=20 > RFC 7749 describes the vocabulary, not processor-specific processing = instructions=E2=80=A6 Well, it is more or less random what went into the element/attribute = structure (including =E2=80=9Cstyles=E2=80=9D) and what went into PIs. = I don=E2=80=99t think XML2RFC is particularly usable without what is now = in the PIs. > Also note that V3 deprecates in favor of
, removing = *all* styling options. Feedback on that should be sent before it's too = late :-) Hmm, feedback will come once people are trying to get their documents = done with the new toys. By definition, it cannot be =E2=80=9Ctoo late=E2=80=9D then =E2=80=94 = any feedback before that is speculative. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Sep 6 04:33:48 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED69613291C for ; Wed, 6 Sep 2017 04:33:46 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 zw-6Wal3O2ox for ; Wed, 6 Sep 2017 04:33:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 35709132707 for ; Wed, 6 Sep 2017 04:33:44 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MGnPx-1dktl30p5l-00DbUN; Wed, 06 Sep 2017 13:33:36 +0200 To: Carsten Bormann Cc: XML2RFC Interest Group References: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> From: Julian Reschke Message-ID: Date: Wed, 6 Sep 2017 13:33:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:my6d8Pqc45mJChKnjj6FpjUrPyghZTppIk9xyVwq7387HUCz99j UjpVivyKfFn4Vdu3zMdsX+6z4ojYek64ncGJFycpkp3ZdYuf2mgWe/IbVnv/JTWreXKLO8L JEp7pB9ETJErBcS7kpQwqBz2dp1oSVy8r5qNYNI+XlaQmI3KE7izfsaq3Px0WUabuP8uPRB 1cu6187agf8MXlX1gZ7sA== X-UI-Out-Filterresults: notjunk:1;V01:K0:2sQh9Qc7OG4=:oUcjvZXyjrnFcjatiPAV9q wNdiveg59naNlPFp70x808mS5Mnos7t79CY2u89/Vjg2oyvY7Eh+sEwOe0X4Gh9qWmIRnSD8k w5mDK5CAfwCw745cH7gH8VHRPolBhUBp3WVQTVrGcsnL9i1lb/Ditp/q0tpQUoid5oOih58UB hg5Tol/bbpib6xwyolXv2tfYuAqQ0QttANKif2sznSD7hv76g6nOwyYZQGwhfaElB/DdfsNNx 8K7vcS2J509t92oblMSocu1WfPEVF3/Ovvu6sIem8IVOf56sqZ3BnwNqMxWDatQp49e327loc 0fmMP3RSv/pobbYKKycB1t2u9HKjvRQ/VwxnBPjCu5X/xjHjKlIjFwPNu7jw3wWFhnAEqFkmZ H/AeI+lbT+hJ/H2qVS1OiQbmI60AdUtLl85cJ9323T+URAC5kxcwtNQ/dSTDFEDDhgzoD9qsl oJI676GhqEIQZdJXjoZK2lDz9O60A49djUNlsbcFf4zpCykQbTQSpve9qX1eR0tfUBWuAiJqY R6n3jcCIyqM3TuOzEeMwI7bX+8uaZo9Wjjym5S0Czxz9x5fVwDaxB6yWKA2CyUgB8pfCBTS2v ee90+QFX8B/m77zxmBJ5RLtMO8Chvy/F98tivGGIof09G1mJ4icmH1kWdX+37nHvgsODOFzgC kuJss1idjPhSp1BpQTemF/PnUL5XEqjg7mQAY2FEw2GiQuOlqAaa5goJHuq29Wslxk7t4qi+k SzGGA6dMoZoqYd4mfV5JjAQztR5GI0ucQj2EDGYtqKp7ieyjJalL5Q/RvNQW1SoCOrb0t3duh l4Zz/4lkOa6E66cWxstDLfk6GbzB1xSVnjrTP0YsXbbaX6Yrmk= Archived-At: Subject: Re: [xml2rfc] Spacing between texttable cells X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 11:33:47 -0000 On 2017-09-06 13:01, Carsten Bormann wrote: > On Sep 6, 2017, at 12:45, Julian Reschke wrote: >> >> RFC 7749 describes the vocabulary, not processor-specific processing instructions… > > Well, it is more or less random what went into the element/attribute structure (including “styles”) and what went into PIs. I don’t think XML2RFC is particularly usable without what is now in the PIs. What went into PIs were usually "ad hoc" changes that never got any review, and most of these got too little documentation. >> Also note that V3 deprecates in favor of
, removing *all* styling options. Feedback on that should be sent before it's too late :-) > > Hmm, feedback will come once people are trying to get their documents done with the new toys. > By definition, it cannot be “too late” then — any feedback before that is speculative. Of course it's a bit of speculation; but we do have a corpus of existing documents, no? Best regards, Julian From nobody Wed Sep 6 05:17:50 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AEB132932 for ; Wed, 6 Sep 2017 05:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 DouaP7swifke for ; Wed, 6 Sep 2017 05:17:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2819613291C for ; Wed, 6 Sep 2017 05:17:47 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:60127 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dpZH5-0004DU-HG; Wed, 06 Sep 2017 05:17:44 -0700 To: Julian Reschke , Carsten Bormann References: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> Cc: XML2RFC Interest Group From: Henrik Levkowetz Message-ID: <2b7e6306-92a0-840e-039b-abc9d1423fd8@levkowetz.com> Date: Wed, 6 Sep 2017 14:17:35 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TVDWSPbGwhNQHQSKwepguuDvNrOqgIFNf" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, cabo@tzi.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Spacing between texttable cells X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 12:17:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TVDWSPbGwhNQHQSKwepguuDvNrOqgIFNf Content-Type: multipart/mixed; boundary="pUqchrhPD2ROdw0LM8G4gAnkoQcv9EPgq"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , Carsten Bormann Cc: XML2RFC Interest Group Message-ID: <2b7e6306-92a0-840e-039b-abc9d1423fd8@levkowetz.com> Subject: Re: [xml2rfc] Spacing between texttable cells References: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> In-Reply-To: --pUqchrhPD2ROdw0LM8G4gAnkoQcv9EPgq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2017-09-06 13:33, Julian Reschke wrote: > On 2017-09-06 13:01, Carsten Bormann wrote: >> On Sep 6, 2017, at 12:45, Julian Reschke wrote= : >>> >>> RFC 7749 describes the vocabulary, not processor-specific processing = instructions=E2=80=A6 >>=20 >> Well, it is more or less random what went into the element/attribute s= tructure (including =E2=80=9Cstyles=E2=80=9D) and what went into PIs. I = don=E2=80=99t think XML2RFC is particularly usable without what is now in= the PIs. >=20 > What went into PIs were usually "ad hoc" changes that never got any=20 > review, and most of these got too little documentation. True, but in many cases things went into the PIs because there was a need= =2E I'm convinced that there are more than one case where the first issue of the v3 vocabulary does not provide for the needs that drove the PIs. Best regards, Henrik >>> Also note that V3 deprecates in favor of
, removin= g *all* styling options. Feedback on that should be sent before it's too = late :-) >>=20 >> Hmm, feedback will come once people are trying to get their documents = done with the new toys. >> By definition, it cannot be =E2=80=9Ctoo late=E2=80=9D then =E2=80=94 = any feedback before that is speculative. >=20 > Of course it's a bit of speculation; but we do have a corpus of existin= g=20 > documents, no? >=20 > Best regards, Julian >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc >=20 --pUqchrhPD2ROdw0LM8G4gAnkoQcv9EPgq-- --TVDWSPbGwhNQHQSKwepguuDvNrOqgIFNf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZr+dfAAoJEE6bV0uPuxcaT3cP/0N7vpu14jzl1XRrWJSfPjUj oRRiOlg4chMhPzKFSHMdSckIYuKAT+iLDW0SyEwc9gcR5WNYE46m7IhxNancaANT PYo8LeZaTPs+vVT0fJH+3JzADbGJWJluubRVkKBUwrJNfPS63EKqA8LwJ0FlV3Oq N8C1MM3odtI4aix5iyOxLHwguoY90/b7c/mo1wLcaghRxr9+nKrsbW5L8NkAyFxm Di0ILkjNaOmiJGQqplwKCH7gUsN+Zziyr0tcB12V/aMUg2tKgmRhbUa+OkLx4ilt bjZ+O5u+H7h49NErndTwRZkk8CrJ0UO7ZwLexypheXY0Lc5uk3pk+eiowy2+XdkD aYElCg6ng4vyWgnhxI9vQGstKz8ciLf6ZpyUyTBmx6drOG7hB4EqjGPEaOJ1RCGe UZkFghmO8F6DbiOPO2w0EbOtojah6kBHR4aGVfABkTN1g4tcg/z4kJHmLA4i6g50 iUBWOOoWx0D/fLdBmn6S5bBQlq1loN8pbEyRMBkXIYY+0do1CAmzmmf2qicm6dg2 cpm1pcMl8d0XHingEECvUxZJ2bqPQ6yPW6Dxs6pegj/5cN+LkETBLEsdv4Q7aCCM njqeKTueSFCcDfNgPY3OBxwuilsNUwbvAqKS1nNLN3hmYqLKNEedZkF2c0L8atBH QoCm8pWsyGZ27u+ejtJ2 =xS/h -----END PGP SIGNATURE----- --TVDWSPbGwhNQHQSKwepguuDvNrOqgIFNf-- From nobody Wed Sep 6 05:21:33 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E23132E17 for ; Wed, 6 Sep 2017 05:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 oTP2iqEhlZlu for ; Wed, 6 Sep 2017 05:21:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CB21326BB for ; Wed, 6 Sep 2017 05:21:30 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:60282 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1dpZKk-00062v-2K; Wed, 06 Sep 2017 05:21:30 -0700 To: Carsten Bormann , Julian Reschke References: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> Cc: XML2RFC Interest Group From: Henrik Levkowetz Message-ID: <39ad8841-8c47-7c2e-fb94-310093ec9d7e@levkowetz.com> Date: Wed, 6 Sep 2017 14:21:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OWCB6sM4SxbfSo5icOxwCr8sCMdeKuLE5" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, julian.reschke@gmx.de, cabo@tzi.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Spacing between texttable cells X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 12:21:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OWCB6sM4SxbfSo5icOxwCr8sCMdeKuLE5 Content-Type: multipart/mixed; boundary="rGhJB8X39VqFr639FehCoLbHekU5gPaJ7"; protected-headers="v1" From: Henrik Levkowetz To: Carsten Bormann , Julian Reschke Cc: XML2RFC Interest Group Message-ID: <39ad8841-8c47-7c2e-fb94-310093ec9d7e@levkowetz.com> Subject: Re: [xml2rfc] Spacing between texttable cells References: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> In-Reply-To: --rGhJB8X39VqFr639FehCoLbHekU5gPaJ7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2017-09-06 13:01, Carsten Bormann wrote: > On Sep 6, 2017, at 12:45, Julian Reschke wrote:= >>=20 >> RFC 7749 describes the vocabulary, not processor-specific processing i= nstructions=E2=80=A6 >=20 > Well, it is more or less random what went into the element/attribute st= ructure (including =E2=80=9Cstyles=E2=80=9D) and what went into PIs. I d= on=E2=80=99t think XML2RFC is particularly usable without what is now in = the PIs. >=20 >> Also note that V3 deprecates in favor of
, removing= *all* styling options. Feedback on that should be sent before it's too l= ate :-) >=20 > Hmm, feedback will come once people are trying to get their documents > done with the new toys. Right. I hope to make the first release of the preptool during September= , and then the v3 xml2rfc text converter next. At that point, real feedbac= k should be possible not only on the tool implementation, but on the vocabu= lary. > By definition, it cannot be =E2=80=9Ctoo late=E2=80=9D then =E2=80=94 a= ny feedback before > that is speculative. I agree. Henrik --rGhJB8X39VqFr639FehCoLbHekU5gPaJ7-- --OWCB6sM4SxbfSo5icOxwCr8sCMdeKuLE5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZr+hCAAoJEE6bV0uPuxcameAQALa1stJrovLFt2rl+LP6Qd7n 5yI/8nvXXKDebdsLhL6rxNuzJAdpF3japzum81aP+FV7J7g96105PB0vzKkeuB/y ZM1+NVpqvuN3hjADTyVk13P9JGeb1su36638J9BizRcUzmcT3Is+5FwG6/AQwVY1 rZz7hh+mT29ga+1ZgKQ6qFJ14Uxd/95r6uXkflXeQKAlyzwT8ZMQkCTn8gTyW9bJ EoRdhO5Wk2XIp23GsFihqcEZ1re8/E1cmJ7VJ/rQpEpJZM97q+lUFLyI0v+vBReC 6aZL1s1/kHgFT5zYSy9Su6hn93XGvfw0NxICXdDTIHLOijQajeFJexA5VGEiJENv gw4KzQ8yVHOIIP7c0Ijrm1GVy/QTEpr/l0wyi2RJPg44ofI2Gw/yFd5OrYSpJDAE snUpvDOH3wTG/JhwWHEVRzctNyfrT44UIt2Im/Q7nCFBUX3SUyrKZBxGyWiruhEO isa6i2NpTNzHjRyKKvGM/0feB5OmJP/JcUXDoiG4AQe2gyXWQfSMmM2+KzNhFgkp MlBxbDGJTBHb2gx/ARAy15uU9/+jxWObxBLDs4w3txW5j8yrB0V6uMe+vhrQMst8 mo/sx7BCzgswrPgyHjsxIIyl87tX1sQEtKEMEcHTe1dMeyFEu4KB9iy6qZ5dvV8A sUzRKrNcwp1zJfOMEosx =GJF/ -----END PGP SIGNATURE----- --OWCB6sM4SxbfSo5icOxwCr8sCMdeKuLE5-- From nobody Wed Sep 6 07:34:16 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98644132FC1 for ; Wed, 6 Sep 2017 07:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 cUZMuxa-dY9b for ; Wed, 6 Sep 2017 07:34:07 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A106D132FC0 for ; Wed, 6 Sep 2017 07:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v86EY4F6013037; Wed, 6 Sep 2017 16:34:04 +0200 (CEST) Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xnR0r0kY6zDL2v; Wed, 6 Sep 2017 16:34:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Wed, 6 Sep 2017 16:34:03 +0200 Cc: XML2RFC Interest Group X-Mao-Original-Outgoing-Id: 526401243.16691-9c635062d2b4712ec171f7353a39abd1 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> To: Julian Reschke X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] Spacing between texttable cells X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 14:34:15 -0000 > On Sep 6, 2017, at 13:33, Julian Reschke = wrote: >=20 > On 2017-09-06 13:01, Carsten Bormann wrote: >> On Sep 6, 2017, at 12:45, Julian Reschke = wrote: >>>=20 >>> RFC 7749 describes the vocabulary, not processor-specific processing = instructions=E2=80=A6 >> Well, it is more or less random what went into the element/attribute = structure (including =E2=80=9Cstyles=E2=80=9D) and what went into PIs. = I don=E2=80=99t think XML2RFC is particularly usable without what is now = in the PIs. >=20 > What went into PIs were usually "ad hoc" changes that never got any = review, and most of these got too little documentation. It got a lot of review from the people using it=E2=80=A6 >>> Also note that V3 deprecates in favor of
, = removing *all* styling options. Feedback on that should be sent before = it's too late :-) >> Hmm, feedback will come once people are trying to get their documents = done with the new toys. >> By definition, it cannot be =E2=80=9Ctoo late=E2=80=9D then =E2=80=94 = any feedback before that is speculative. >=20 > Of course it's a bit of speculation; but we do have a corpus of = existing documents, no? Well, yes, but that doesn=E2=80=99t help much here. (The fact that we are discussing the =E2=80=98compact' PI here as if its = use were unusual =E2=80=94 although it occurs about 3000 times in the = corpus of ~ 2000 documents I have =E2=80=94 should be ample = demonstration.) Where v3 just uses established techniques from v2 or there is a = straightforward translation, the corpus helps. But nobody has gone ahead and translated all the texttables in the = corpus from v2 into v3 tables. Nobody knows whether the results of = applying v3 tables will look good (as opposed to confusing readers). = I=E2=80=99d say each new design in v3 is speculative and needs to be = subject to an iterative improvement process based on real usage = experience. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Sep 6 07:46:51 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9924A132CE7 for ; Wed, 6 Sep 2017 07:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.38 X-Spam-Level: X-Spam-Status: No, score=-4.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 joElHRZmBzph for ; Wed, 6 Sep 2017 07:46:48 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF4F132C2A for ; Wed, 6 Sep 2017 07:46:48 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v86Ejr8o021272 for ; Wed, 6 Sep 2017 10:46:39 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 2ctj6mjphu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 06 Sep 2017 10:46:39 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v86EkciG007687 for ; Wed, 6 Sep 2017 10:46:38 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v86EkYP8007578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 6 Sep 2017 10:46:36 -0400 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi408.sfdc.sbc.com (RSA Interceptor) for ; Wed, 6 Sep 2017 14:46:24 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.116]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0361.001; Wed, 6 Sep 2017 10:46:23 -0400 From: "HANSEN, TONY L" CC: XML2RFC Interest Group Thread-Topic: [xml2rfc] Spacing between texttable cells Thread-Index: AQHTJx0voXUWdQZtj0GqwCX5qI5EIaKn75UA Date: Wed, 6 Sep 2017 14:46:23 +0000 Message-ID: <738FC80F-6F92-4B8B-BAEA-EE5ABA1E933A@att.com> References: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.210.13.22] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-06_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709060207 Archived-At: Subject: Re: [xml2rfc] Spacing between texttable cells X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 14:46:49 -0000 T24gOS82LzE3LCAxMDozNCBBTSwgInhtbDJyZmMgb24gYmVoYWxmIG9mIENhcnN0ZW4gQm9ybWFu biIgPHhtbDJyZmMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2Fib0B0emkub3JnPiB3 cm90ZToNCg0KICAgIA0KICAgID4gT24gU2VwIDYsIDIwMTcsIGF0IDEzOjMzLCBKdWxpYW4gUmVz Y2hrZSA8anVsaWFuLnJlc2Noa2VAZ214LmRlPiB3cm90ZToNCiAgICA+IA0KICAgID4gT24gMjAx Ny0wOS0wNiAxMzowMSwgQ2Fyc3RlbiBCb3JtYW5uIHdyb3RlOg0KICAgID4+IE9uIFNlcCA2LCAy MDE3LCBhdCAxMjo0NSwgSnVsaWFuIFJlc2Noa2UgPGp1bGlhbi5yZXNjaGtlQGdteC5kZT4gd3Jv dGU6DQogICAgPj4+IA0KICAgID4+PiBSRkMgNzc0OSBkZXNjcmliZXMgdGhlIHZvY2FidWxhcnks IG5vdCBwcm9jZXNzb3Itc3BlY2lmaWMgcHJvY2Vzc2luZyBpbnN0cnVjdGlvbnPigKYNCiAgICA+ PiBXZWxsLCBpdCBpcyBtb3JlIG9yIGxlc3MgcmFuZG9tIHdoYXQgd2VudCBpbnRvIHRoZSBlbGVt ZW50L2F0dHJpYnV0ZSBzdHJ1Y3R1cmUgKGluY2x1ZGluZyDigJxzdHlsZXPigJ0pIGFuZCB3aGF0 IHdlbnQgaW50byBQSXMuICBJIGRvbuKAmXQgdGhpbmsgWE1MMlJGQyBpcyBwYXJ0aWN1bGFybHkg dXNhYmxlIHdpdGhvdXQgd2hhdCBpcyBub3cgaW4gdGhlIFBJcy4NCiAgICA+IA0KICAgID4gV2hh dCB3ZW50IGludG8gUElzIHdlcmUgdXN1YWxseSAiYWQgaG9jIiBjaGFuZ2VzIHRoYXQgbmV2ZXIg Z290IGFueSByZXZpZXcsIGFuZCBtb3N0IG9mIHRoZXNlIGdvdCB0b28gbGl0dGxlIGRvY3VtZW50 YXRpb24uDQogICAgDQogICAgSXQgZ290IGEgbG90IG9mIHJldmlldyBmcm9tIHRoZSBwZW9wbGUg dXNpbmcgaXTigKYNCiAgICANCiAgICA+Pj4gQWxzbyBub3RlIHRoYXQgVjMgZGVwcmVjYXRlcyA8 dGV4dHRhYmxlPiBpbiBmYXZvciBvZiA8dGFibGU+LCByZW1vdmluZyAqYWxsKiBzdHlsaW5nIG9w dGlvbnMuIEZlZWRiYWNrIG9uIHRoYXQgc2hvdWxkIGJlIHNlbnQgYmVmb3JlIGl0J3MgdG9vIGxh dGUgOi0pDQogICAgPj4gSG1tLCBmZWVkYmFjayB3aWxsIGNvbWUgb25jZSBwZW9wbGUgYXJlIHRy eWluZyB0byBnZXQgdGhlaXIgZG9jdW1lbnRzIGRvbmUgd2l0aCB0aGUgbmV3IHRveXMuDQogICAg Pj4gQnkgZGVmaW5pdGlvbiwgaXQgY2Fubm90IGJlIOKAnHRvbyBsYXRl4oCdIHRoZW4g4oCUIGFu eSBmZWVkYmFjayBiZWZvcmUgdGhhdCBpcyBzcGVjdWxhdGl2ZS4NCiAgICA+IA0KICAgID4gT2Yg Y291cnNlIGl0J3MgYSBiaXQgb2Ygc3BlY3VsYXRpb247IGJ1dCB3ZSBkbyBoYXZlIGEgY29ycHVz IG9mIGV4aXN0aW5nIGRvY3VtZW50cywgbm8/DQogICAgDQogICAgV2VsbCwgeWVzLCBidXQgdGhh dCBkb2VzbuKAmXQgaGVscCBtdWNoIGhlcmUuDQogICAgDQogICAgKFRoZSBmYWN0IHRoYXQgd2Ug YXJlIGRpc2N1c3NpbmcgdGhlIOKAmGNvbXBhY3QnIFBJIGhlcmUgYXMgaWYgaXRzIHVzZSB3ZXJl IHVudXN1YWwg4oCUIGFsdGhvdWdoIGl0IG9jY3VycyBhYm91dCAzMDAwIHRpbWVzIGluIHRoZSBj b3JwdXMgb2YgfiAyMDAwIGRvY3VtZW50cyBJIGhhdmUg4oCUIHNob3VsZCBiZSBhbXBsZSBkZW1v bnN0cmF0aW9uLikNCiAgICANCiAgICBXaGVyZSB2MyBqdXN0IHVzZXMgZXN0YWJsaXNoZWQgdGVj aG5pcXVlcyBmcm9tIHYyIG9yIHRoZXJlIGlzIGEgc3RyYWlnaHRmb3J3YXJkIHRyYW5zbGF0aW9u LCB0aGUgY29ycHVzIGhlbHBzLg0KICAgIA0KICAgIEJ1dCBub2JvZHkgaGFzIGdvbmUgYWhlYWQg YW5kIHRyYW5zbGF0ZWQgYWxsIHRoZSB0ZXh0dGFibGVzIGluIHRoZSBjb3JwdXMgZnJvbSB2MiBp bnRvIHYzIHRhYmxlcy4gIE5vYm9keSBrbm93cyB3aGV0aGVyIHRoZSByZXN1bHRzIG9mIGFwcGx5 aW5nIHYzIHRhYmxlcyB3aWxsIGxvb2sgZ29vZCAoYXMgb3Bwb3NlZCB0byBjb25mdXNpbmcgcmVh ZGVycykuICBJ4oCZZCBzYXkgZWFjaCBuZXcgZGVzaWduIGluIHYzIGlzIHNwZWN1bGF0aXZlIGFu ZCBuZWVkcyB0byBiZSBzdWJqZWN0IHRvIGFuIGl0ZXJhdGl2ZSBpbXByb3ZlbWVudCBwcm9jZXNz IGJhc2VkIG9uIHJlYWwgdXNhZ2UgZXhwZXJpZW5jZS4NCg0KDQpUaGUgdjMgZGVzaWduIGlzIG9y aWVudGVkIGF3YXkgZnJvbSBwYXBlciBwcmVzZW50YXRpb24gYW5kIHRvd2FyZHMgbmV3ZXIgZm9y bWF0czogaHRtbCBhbmQsIGluIHRoZSBmdXR1cmUsIHRoaW5ncyBsaWtlIGVQdWIuIFNvIGZlYXR1 cmVzIHRoYXQgYXJlIHZlcnkgc3BlY2lmaWMgdG8gaG93IHRoZSBsYXlvdXQgd29ya3Mgb24gcGFw ZXIgaGF2ZSBiZWVuIGRvd25wbGF5ZWQuIFRoZSDigJxjb21wYWN04oCdIFBJIGlzIGFuIGV4YW1w bGUgb2YgdGhhdDogaXQgYWZmZWN0cyB0aGUgbGF5b3V0IG9uIHBhcGVyIGFuZCBub3RoaW5nIGVs c2UuDQoNCglUb255IEhhbnNlbiAgDQoNCg== From nobody Wed Sep 6 08:00:41 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3C8132CE7 for ; Wed, 6 Sep 2017 08:00:40 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Id3CqUoXj3sP for ; Wed, 6 Sep 2017 08:00:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 A6D39132A65 for ; Wed, 6 Sep 2017 08:00:32 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MSIf1-1e1Ws142tn-00TSYu; Wed, 06 Sep 2017 17:00:23 +0200 To: Carsten Bormann Cc: XML2RFC Interest Group References: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> From: Julian Reschke Message-ID: <3b8c47e6-8a58-050a-f139-3bf1b6af90f4@gmx.de> Date: Wed, 6 Sep 2017 17:00:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:FWrks0aioCmbCh7wmXuHo/AwTj1G9Z85el+ObQefzt5CUM6LS88 pCgAkZWBnlD0dp8bqy7BT9iS9Tbse/oe8dn24wRJHQJs2bmxPS7+rcCXXMewfaoM4QjgW0G 9Jjru2pjAp4/fe7Ef5YHP95IWAAEg8dsJFziBhtSMEpXA2O/nmcFKnFeqbMa1OokwVa6NPi Vmz5swc0mKjXe1PeLXzKA== X-UI-Out-Filterresults: notjunk:1;V01:K0:a+jXsh/zGXM=:DX23b8yW3BKiHDvE1dXnmM 2diMXvW0eYYM0KIWOqMDXsHLMEKcse7r4IdJwCYBGIeRo5zaPd4uiGYYZ7E37L7jfBjVTMsT8 SG7i+wo0KA4rjwg/M3tKJpNGJdtbR55L8UXmGLi3bvQMc24CEUpoGeoY+mNTbii4zLSyH1yt9 vshkVfpJ8OrStnjt+SvpPAv2c0u4JDsAwCFEIzkVTz++UkPOf7tNQk2chrJfOni4OWGd1H8+r qyDEtUX85bkAHT3YrMgfbcl2kcSwpadCZcrP+RHLHBpfhbcofYIL2zYbuEDJr7hZfeSinbP0v ssfgtxzJgbWGRqBlkAhD6cj0iBvLJkJh8bzaJyxLvwfzCsknkO/nOXU4k81I2cOfjGoTOTuBy MaIvt/lKZSrv5NsC1iFExYK54S5PCGJFH4O/kJ8xCXdDAeHinUXA4BMJWMP5pxRu26t62knvM /ihZni2edK+fuWm2EUNkm5NmYBd0JgafH+9qPtbSImlEjJau4rqQ0WqXl/8pyIgSkTVQQRDC3 yh3ZCvZrOkmA6j4zuUn1+Sv0FdkcQKZUvYauuSy+Jcjth3lwB0r7VARWvoU9YJwC6fr0VzR84 8NBYYgDmS1opfHbWk1Cx78EWAeZvFA04rrt6Y0ujVWCHOtYhg1xqL5GZBbTrDg2iXWHWI3HRd +8L8AhrHwFLPOWSPk+XYlAGtZ1NxT+oV66+yGp4LQdmsQbHLvi40SGeQazDimZBWjLz7LC45j RSYtkptmaUVVLVjN89zwvbWkwPkr2S6Br9WXwqwJhgzWus1xwbqzlZW0s6Nbw2BgmK3n2DotL +slMy9DhF0roY4iiPfDHkdtowxx81Qs25IloD5rBGcRv1MzWVo= Archived-At: Subject: Re: [xml2rfc] Spacing between texttable cells X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 15:00:40 -0000 On 2017-09-06 16:34, Carsten Bormann wrote: > >> On Sep 6, 2017, at 13:33, Julian Reschke wrote: >> >> On 2017-09-06 13:01, Carsten Bormann wrote: >>> On Sep 6, 2017, at 12:45, Julian Reschke wrote: >>>> >>>> RFC 7749 describes the vocabulary, not processor-specific processing instructions… >>> Well, it is more or less random what went into the element/attribute structure (including “styles”) and what went into PIs. I don’t think XML2RFC is particularly usable without what is now in the PIs. >> >> What went into PIs were usually "ad hoc" changes that never got any review, and most of these got too little documentation. > > It got a lot of review from the people using it… > >>>> Also note that V3 deprecates in favor of
, removing *all* styling options. Feedback on that should be sent before it's too late :-) >>> Hmm, feedback will come once people are trying to get their documents done with the new toys. >>> By definition, it cannot be “too late” then — any feedback before that is speculative. >> >> Of course it's a bit of speculation; but we do have a corpus of existing documents, no? > > Well, yes, but that doesn’t help much here. > > (The fact that we are discussing the ‘compact' PI here as if its use were unusual — although it occurs about 3000 times in the corpus of ~ 2000 documents I have — should be ample demonstration.) The problem with "compact" (and "subcompact") is that it does many things at once, and has little documentation at all. > Where v3 just uses established techniques from v2 or there is a straightforward translation, the corpus helps. > > But nobody has gone ahead and translated all the texttables in the corpus from v2 into v3 tables. Nobody knows whether the results of applying v3 tables will look good (as opposed to confusing readers). I’d say each new design in v3 is speculative and needs to be subject to an iterative improvement process based on real usage experience. Well, we know that it'll be ugly. What complicates things is that the primary target of the V3 vocab is HTML output, while for V2 it was plain text (where micro-managing whitespace is way more popular). Best regards, Julian From nobody Wed Sep 6 09:08:00 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BEB132031 for ; Wed, 6 Sep 2017 09:07:59 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 WcC-pQsmg80H for ; Wed, 6 Sep 2017 09:07:57 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 598EB132C49 for ; Wed, 6 Sep 2017 09:07:57 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MAhTr-1djsVn0elf-00BvLg; Wed, 06 Sep 2017 18:07:52 +0200 To: "HANSEN, TONY L" Cc: XML2RFC Interest Group References: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> <738FC80F-6F92-4B8B-BAEA-EE5ABA1E933A@att.com> From: Julian Reschke Message-ID: Date: Wed, 6 Sep 2017 18:07:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <738FC80F-6F92-4B8B-BAEA-EE5ABA1E933A@att.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:p/AKBLpH69UlxYXHubBr90V1aMvFAVgz5BAkPXbwH+Ie9zJ9H0y PUUeZZUta1zrTTU7jHGQb4DBdjKzqpSnze44Id8mRkvYNn/VIyHIvOgHlE3Sh4Nq8nQ6T4l SSyG5ajpE3foNt0AkFTNIOQsFLZvLjYyIQOW98aogVTnyYhgcJWvzO12+eaRhZ36XHObJSn TJF2XwLNf5lnJOVRxzm8w== X-UI-Out-Filterresults: notjunk:1;V01:K0:OztmHCt93qI=:7hpnRVYdad+rnScTHtQYke q/AeUkvO48HTelt65P55NvlQJC3wlCr/gSU/E+FnJXaWXVFwxmSjwfpMtfn03LqD3N3EpyqVU 58Gfh2hmtCgwGIvd+/njNvkp7rS1qSXvifatqqhCxvSTfXj0SeX/dbAejrUFTFFAnWmm2dmDI RFmA85E8iN+r7yQroc2s21lEIMohpoefhtCVPZmLhh6OtZ+cBBPr8UJL9glZC7mZPjU0BBGSM KqGk0/+RZSgLV8weAylLy2gOYnw5JGRalUhGwmJ3fWA9sxNsopFY6rJMS6ZAOZWDFee+FkuKi y16pBtNDTyew/RVgYXOOYTOQ4B2cCYUjGXDxdE1OrDlprV2/ku6HYwwyku1SUDjiVMX/3Xyjq 5BUvYYnD9Cd1KUPM2U+wP2SQx8eIXuWbF4vswZR7BcubEtLaPlXArMSfp7l5Ek2GXyw3m4l5S d/kAu2JnMUmQRdOYsBuZ55wPjdDDLdA21iOFqiltMfh3DH6QimOGyOsT/3fFLyudG1gkDe4KF NipKjLHCC2YTZKNiSNTx+Jt8KFcIR0ShiJMAPeIY1OfmKrfMyCJX9JtaQHr9wcVPKBCaRQZMT j5cZjByCQVdtYGy93B2N8wfwMLTjQZCq2I2ek2biks0S81XYR3OskKv449n/7SCcANOIqcvE9 YG9iJxUP2G1u9RaIsDkeooWeoiIHmVYEa1gNec1wsapB83NjRCnC7uFqUqd5zQm9vljf14i5o 28WSSZ1YDOaq0ScYkhnaSDBpB8ifwxfMBFOVdzea3tSb7j82CGwgSpC16WbU0cNSjCAHIw/9k B0RABOD75bUtd5PN3Wp3ya5BXcaCjJg4ZLBFhenY3XGSGg0Xo8= Archived-At: Subject: Re: [xml2rfc] Spacing between texttable cells X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 16:07:59 -0000 On 2017-09-06 16:46, HANSEN, TONY L wrote: > ... > The v3 design is oriented away from paper presentation and towards newer formats: html and, in the future, things like ePub. So features that are very specific to how the layout works on paper have been downplayed. The “compact” PI is an example of that: it affects the layout on paper and nothing else. > ... Hm, when you say "on paper" you mean in plain text, I assume? It certainly affects the HTML output of rfc2629.xslt (for lists), and I *believe* it does that in xml2rfc's HTML output as well (maybe not in V2, though). Best regards, Julian From nobody Wed Sep 6 10:20:50 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F38F13294B for ; Wed, 6 Sep 2017 10:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 5rSFKsZDMk85 for ; Wed, 6 Sep 2017 10:20:48 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5385513243E for ; Wed, 6 Sep 2017 10:20:18 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v86DPjCL018280; Wed, 6 Sep 2017 09:37:23 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 2ctgssbmuj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Sep 2017 09:37:23 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v86DbMUk021695; Wed, 6 Sep 2017 09:37:23 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v86DbCAc021342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Sep 2017 09:37:17 -0400 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 6 Sep 2017 13:37:02 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.116]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0361.001; Wed, 6 Sep 2017 09:37:02 -0400 From: "HANSEN, TONY L" To: Henrik Levkowetz , Julian Reschke , Carsten Bormann CC: XML2RFC Interest Group Thread-Topic: [xml2rfc] Spacing between texttable cells Thread-Index: AQHTJvEfoXUWdQZtj0GqwCX5qI5EIaKn3gkAgAARjwCAAASRgIAACPcAgAAMSoD//9MvgA== Date: Wed, 6 Sep 2017 13:37:01 +0000 Message-ID: <3D80E89B-9DE0-44F6-A866-27E0474BDE28@att.com> References: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> <2b7e6306-92a0-840e-039b-abc9d1423fd8@levkowetz.com> In-Reply-To: <2b7e6306-92a0-840e-039b-abc9d1423fd8@levkowetz.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.210.4.106] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-06_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709060187 Archived-At: Subject: Re: [xml2rfc] Spacing between texttable cells X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 17:20:49 -0000 T24gOS82LzE3LCA4OjE3IEFNLCAieG1sMnJmYyBvbiBiZWhhbGYgb2YgSGVucmlrIExldmtvd2V0 eiIgPHhtbDJyZmMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaGVucmlrQGxldmtvd2V0 ei5jb20+IHdyb3RlOg0KDQogICAgDQogICAgT24gMjAxNy0wOS0wNiAxMzozMywgSnVsaWFuIFJl c2Noa2Ugd3JvdGU6DQogICAgPiBPbiAyMDE3LTA5LTA2IDEzOjAxLCBDYXJzdGVuIEJvcm1hbm4g d3JvdGU6DQogICAgPj4gT24gU2VwIDYsIDIwMTcsIGF0IDEyOjQ1LCBKdWxpYW4gUmVzY2hrZSA8 anVsaWFuLnJlc2Noa2VAZ214LmRlPiB3cm90ZToNCiAgICA+Pj4NCiAgICA+Pj4gUkZDIDc3NDkg ZGVzY3JpYmVzIHRoZSB2b2NhYnVsYXJ5LCBub3QgcHJvY2Vzc29yLXNwZWNpZmljIHByb2Nlc3Np bmcgaW5zdHJ1Y3Rpb25z4oCmDQogICAgPj4gDQogICAgPj4gV2VsbCwgaXQgaXMgbW9yZSBvciBs ZXNzIHJhbmRvbSB3aGF0IHdlbnQgaW50byB0aGUgZWxlbWVudC9hdHRyaWJ1dGUgc3RydWN0dXJl IChpbmNsdWRpbmcg4oCcc3R5bGVz4oCdKSBhbmQgd2hhdCB3ZW50IGludG8gUElzLiAgSSBkb27i gJl0IHRoaW5rIFhNTDJSRkMgaXMgcGFydGljdWxhcmx5IHVzYWJsZSB3aXRob3V0IHdoYXQgaXMg bm93IGluIHRoZSBQSXMuDQogICAgPiANCiAgICA+IFdoYXQgd2VudCBpbnRvIFBJcyB3ZXJlIHVz dWFsbHkgImFkIGhvYyIgY2hhbmdlcyB0aGF0IG5ldmVyIGdvdCBhbnkgDQogICAgPiByZXZpZXcs IGFuZCBtb3N0IG9mIHRoZXNlIGdvdCB0b28gbGl0dGxlIGRvY3VtZW50YXRpb24uDQogICAgDQog ICAgVHJ1ZSwgYnV0IGluIG1hbnkgY2FzZXMgdGhpbmdzIHdlbnQgaW50byB0aGUgUElzIGJlY2F1 c2UgdGhlcmUgd2FzIGEgbmVlZC4NCiAgICANCiAgICBJJ20gY29udmluY2VkIHRoYXQgdGhlcmUg YXJlIG1vcmUgdGhhbiBvbmUgY2FzZSB3aGVyZSB0aGUgZmlyc3QgaXNzdWUNCiAgICBvZiB0aGUg djMgdm9jYWJ1bGFyeSBkb2VzIG5vdCBwcm92aWRlIGZvciB0aGUgbmVlZHMgdGhhdCBkcm92ZSB0 aGUgUElzLg0KDQpZZWFoLCBJ4oCZdmUgYmVlbiBsb25nIGNvbnZpbmNlZCBvZiB0aGF0IHRvby4N Cg0KCVRvbnkNCg0K From nobody Wed Sep 6 10:38:59 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFAF13243E for ; Wed, 6 Sep 2017 10:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no 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 C9RyyP2N9Ecv for ; Wed, 6 Sep 2017 10:38:57 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2311321A2 for ; Wed, 6 Sep 2017 10:38:57 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v86HZg3m039314 for ; Wed, 6 Sep 2017 13:38:56 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 2ctn8h9eg1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 06 Sep 2017 13:38:55 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v86HcsNJ009281 for ; Wed, 6 Sep 2017 13:38:54 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v86HcmpG009123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 6 Sep 2017 13:38:52 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for ; Wed, 6 Sep 2017 17:38:37 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.116]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0361.001; Wed, 6 Sep 2017 13:38:36 -0400 From: "HANSEN, TONY L" CC: XML2RFC Interest Group Thread-Topic: [xml2rfc] Spacing between texttable cells Thread-Index: AQHTJx0voXUWdQZtj0GqwCX5qI5EIaKn75UAgABZ1AD//9ZKgA== Date: Wed, 6 Sep 2017 17:38:36 +0000 Message-ID: References: <1504689480.1511033.1096810000.15C3604A@webmail.messagingengine.com> <2CDCE397-11B5-41CE-9DE5-BE46DACBABB8@tzi.org> <738FC80F-6F92-4B8B-BAEA-EE5ABA1E933A@att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.210.13.137] Content-Type: text/plain; charset="utf-8" Content-ID: <1F195FFBC797C5479CA884270B77E566@LOCAL> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-06_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709060249 Archived-At: Subject: Re: [xml2rfc] Spacing between texttable cells X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 17:38:59 -0000 T24gOS82LzE3LCAxMjowNyBQTSwgIkp1bGlhbiBSZXNjaGtlIiA8anVsaWFuLnJlc2Noa2VAZ214 LmRlPiB3cm90ZToNCg0KICAgIE9uIDIwMTctMDktMDYgMTY6NDYsIEhBTlNFTiwgVE9OWSBMIHdy b3RlOg0KICAgID4gLi4uDQogICAgPiBUaGUgdjMgZGVzaWduIGlzIG9yaWVudGVkIGF3YXkgZnJv bSBwYXBlciBwcmVzZW50YXRpb24gYW5kIHRvd2FyZHMgbmV3ZXIgZm9ybWF0czogaHRtbCBhbmQs IGluIHRoZSBmdXR1cmUsIHRoaW5ncyBsaWtlIGVQdWIuIFNvIGZlYXR1cmVzIHRoYXQgYXJlIHZl cnkgc3BlY2lmaWMgdG8gaG93IHRoZSBsYXlvdXQgd29ya3Mgb24gcGFwZXIgaGF2ZSBiZWVuIGRv d25wbGF5ZWQuIFRoZSDigJxjb21wYWN04oCdIFBJIGlzIGFuIGV4YW1wbGUgb2YgdGhhdDogaXQg YWZmZWN0cyB0aGUgbGF5b3V0IG9uIHBhcGVyIGFuZCBub3RoaW5nIGVsc2UuDQogICAgPiAuLi4N CiAgICANCiAgICBIbSwgd2hlbiB5b3Ugc2F5ICJvbiBwYXBlciIgeW91IG1lYW4gaW4gcGxhaW4g dGV4dCwgSSBhc3N1bWU/DQoNCltUSF0geWVzDQogICAgDQogICAgSXQgY2VydGFpbmx5IGFmZmVj dHMgdGhlIEhUTUwgb3V0cHV0IG9mIHJmYzI2MjkueHNsdCAoZm9yIGxpc3RzKSwgYW5kIEkgDQog ICAgKmJlbGlldmUqIGl0IGRvZXMgdGhhdCBpbiB4bWwycmZjJ3MgSFRNTCBvdXRwdXQgYXMgd2Vs bCAobWF5YmUgbm90IGluIA0KICAgIFYyLCB0aG91Z2gpLg0KDQpbVEhdIEkgZGlkbuKAmXQgdGhp bmsgdGhlIFBJIGFmZmVjdGVkIHYyIHhtbDJyZmPigJlzIEhUTUwgb3V0cHV0LCBidXQgSSBtYXkg YmUgbWlzdGFrZW4uDQoNClRoZSBwb2ludCBpczogaW4gdjEgYW5kIHYyLCBwYXBlci9wbGFpbiB0 ZXh0IHJ1bGVkLiBJbiB2MiwgaXQgZG9lc27igJl0Lg0KDQoJVG9ueSBIYW5zZW4NCg0K From nobody Mon Sep 18 05:50:11 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228A3129A89; Mon, 18 Sep 2017 05:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 vFD5BXU9vp3R; Mon, 18 Sep 2017 05:49:56 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82DF124F57; Mon, 18 Sep 2017 05:49:56 -0700 (PDT) Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from ) id 1dtvUq-000106-SM; Mon, 18 Sep 2017 05:49:56 -0700 To: xml2rfc@ietf.org Cc: codesprints@ietf.org, rfc-markdown@ietf.org Message-Id: From: Henrik Levkowetz Date: Mon, 18 Sep 2017 05:49:56 -0700 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: codesprints@ietf.org, rfc-markdown@ietf.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc] New xml2rfc release: v2.8.1 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 12:49:58 -0000 Hi, This is an automatic notification about a new xml2rfc release, v2.8.1, generated when running the mkrelease script. Release notes: xml2rfc (2.8.1) ietf; urgency=low This release improves the v2 to v3 conversion of elements which contains ; these are now converted to elements. The preferred way to install xml2rfc is by doing 'pip install xml2rfc', and 'pip install --upgrade xml2rfc' to upgrade. The new version is also available through SVN checkout, with 'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.8.1' Regards, Henrik (via the mkrelease script) From nobody Sat Sep 23 07:16:34 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A3E132025; Sat, 23 Sep 2017 07:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 gS30voE7FS12; Sat, 23 Sep 2017 07:16:20 -0700 (PDT) Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C332312EC30; Sat, 23 Sep 2017 07:16:20 -0700 (PDT) Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from ) id 1dvlEC-0006jC-Nk; Sat, 23 Sep 2017 07:16:20 -0700 To: xml2rfc@ietf.org Cc: codesprints@ietf.org, rfc-markdown@ietf.org Message-Id: From: Henrik Levkowetz Date: Sat, 23 Sep 2017 07:16:20 -0700 X-SA-Exim-Connect-IP: X-SA-Exim-Rcpt-To: codesprints@ietf.org, rfc-markdown@ietf.org, xml2rfc@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: [xml2rfc] New xml2rfc release: v2.8.2 X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 14:16:22 -0000 Hi, This is an automatic notification about a new xml2rfc release, v2.8.2, generated when running the mkrelease script. Release notes: xml2rfc (2.8.2) ietf; urgency=low * Modified the V2v3 conversion writer to work with generic lxml.etree instances, and fixed a failure that could occur for hanging style lists without hangText attributes. * Tweaked mkrelease to work without the old tools control files and tools feeds being present. The preferred way to install xml2rfc is by doing 'pip install xml2rfc', and 'pip install --upgrade xml2rfc' to upgrade. The new version is also available through SVN checkout, with 'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.8.2' Regards, Henrik (via the mkrelease script) From nobody Sun Sep 24 15:27:38 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC9D132355 for ; Sun, 24 Sep 2017 15:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 EWvWAtjWXzZA for ; Sun, 24 Sep 2017 15:27:34 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BF712421A for ; Sun, 24 Sep 2017 15:27:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D494462259 for ; Sun, 24 Sep 2017 18:27:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AIdhJ1NtYj9W for ; Sun, 24 Sep 2017 18:27:27 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id A7C1C621C8 for ; Sun, 24 Sep 2017 18:27:26 -0400 (EDT) To: "xml2rfc@ietf.org" From: Robert Moskowitz Message-ID: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> Date: Sun, 24 Sep 2017 18:27:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 22:27:37 -0000 I need a couple FIPS and SP800 references: SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions National Institute of Standards and Technology SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash National Institute of Standards and Technology Can these be added to http://xml2rfc.tools.ietf.org/public/rfc/bibxml2/ ? Note the URL change for where FIPS docs are from the 'old' http://csrc.nist.gov/publications/fips Currently, I cannot find any SP in the bibxml area. Maybe someone can talk to Tim Polk about this... Bob From nobody Sun Sep 24 17:22:04 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA2913235C for ; Sun, 24 Sep 2017 17:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 wR6xuF5qDVj1 for ; Sun, 24 Sep 2017 17:21:59 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5258E13213D for ; Sun, 24 Sep 2017 17:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v8P0LmwI029845; Mon, 25 Sep 2017 02:21:48 +0200 (CEST) Received: from [172.20.10.9] (ip-109-45-1-12.web.vodafone.de [109.45.1.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3y0lBg6yXZzDMC6; Mon, 25 Sep 2017 02:21:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> Date: Mon, 25 Sep 2017 02:21:46 +0200 Cc: "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 527991706.77947-315f4ad13ef8195aed37055e7bd3394b Content-Transfer-Encoding: quoted-printable Message-Id: <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 00:22:02 -0000 On Sep 25, 2017, at 00:27, Robert Moskowitz wrote: >=20 > I need a couple FIPS and SP800 references: >=20 > > > SHA-3 Standard: Permutation-Based Hash and Extendable-Output = Functions > > National Institute of Standards and = Technology > > > FIPS.202.2015: DOI.10.6028/NIST.FIPS.202 > > > SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and = ParallelHash > > National Institute of Standards and = Technology > > > SP800-185: DOI.10.6028/NIST.SP.800-185 Paste this into your markdown source. Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > Can these be added to = http://xml2rfc.tools.ietf.org/public/rfc/bibxml2/ ? >=20 > Note the URL change for where FIPS docs are from the 'old' >=20 > http://csrc.nist.gov/publications/fips >=20 > Currently, I cannot find any SP in the bibxml area. >=20 > Maybe someone can talk to Tim Polk about this... >=20 > Bob >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc >=20 From nobody Sun Sep 24 18:00:37 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A4B132D42 for ; Sun, 24 Sep 2017 18:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 wd-9hv9rMDqs for ; Sun, 24 Sep 2017 18:00:34 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B20120720 for ; Sun, 24 Sep 2017 18:00:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 3C3D862280; Sun, 24 Sep 2017 21:00:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jagZD-e8XSyu; Sun, 24 Sep 2017 21:00:28 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 550926223C; Sun, 24 Sep 2017 21:00:26 -0400 (EDT) To: Carsten Bormann Cc: "xml2rfc@ietf.org" References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> From: Robert Moskowitz Message-ID: <8fb2f6de-5694-c02a-50fc-17b23f6b3c66@htt-consult.com> Date: Sun, 24 Sep 2017 21:00:23 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 01:00:36 -0000 On 09/24/2017 08:21 PM, Carsten Bormann wrote: > On Sep 25, 2017, at 00:27, Robert Moskowitz wrote: >> I need a couple FIPS and SP800 references: >> >> >> >> SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions >> >> National Institute of Standards and Technology >> >> >> > FIPS.202.2015: DOI.10.6028/NIST.FIPS.202 > >> >> >> SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash >> >> National Institute of Standards and Technology >> >> >> > SP800-185: DOI.10.6028/NIST.SP.800-185 > > Paste this into your markdown source. I'm stubborn and use xml. So I need an xml source... > > Grüße, Carsten > > >> >> Can these be added to http://xml2rfc.tools.ietf.org/public/rfc/bibxml2/ ? >> >> Note the URL change for where FIPS docs are from the 'old' >> >> http://csrc.nist.gov/publications/fips >> >> Currently, I cannot find any SP in the bibxml area. >> >> Maybe someone can talk to Tim Polk about this... >> >> Bob >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc >> > From nobody Sun Sep 24 21:19:56 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F0A13209C for ; Sun, 24 Sep 2017 21:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 5iIhQECduX7J for ; Sun, 24 Sep 2017 21:19:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 5B684124F57 for ; Sun, 24 Sep 2017 21:19:53 -0700 (PDT) Received: from [192.168.178.20] ([93.217.120.208]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LaXmV-1dVZID0abf-00mMMA; Mon, 25 Sep 2017 06:19:46 +0200 To: Robert Moskowitz , "xml2rfc@ietf.org" References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> From: Julian Reschke Message-ID: Date: Mon, 25 Sep 2017 06:19:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:DW34WTkQsMLDpVck84wn5rcHhtTKoaweAH+uziVoqVAOVYUxyGq dxeouZUTCTFwOiSgDK8mDgpFdf9FVYHiEGevpIPD9f3JfHuVAfmy6okwhK1ghpkEQy9aa2y 5VaTIRhpMnlq+eX9zUjlgY3FqhIAHaS7QU1jHNmWUVMzIdwMEh0Apa1jIESQwLn0DjZ00X/ ajeJGiqNkisIh0lOo557w== X-UI-Out-Filterresults: notjunk:1;V01:K0:Tzl4MoMmTJ8=:PfyUD8MoUbAkWJvmaBuceX JD+F/Ey8NUZHz3xdtV3IvQSTErnRqBik0LPXy/3k0SZhEIG2jRynNB5TvRgOcY+KxFO6nKAbQ 7pa6rRAAVWeX+59dD93zThg1mq7X2Dp6qC3hvbxRJn1EbwWQcguLvcggn7s6nfN8UAcQMGMrV zxuE5bDM/T2csVUfRhXrfLLgydn3y65aiwi+Mxjpu/dV2qGF2bl7IiLeUtT3vv6Z9N3rPxRzl NvrdWHhbkAfRT3xQ2dhdma8XPK/PTdWg5vaQj9dZ+Ugv+5azVC/iK5t+ZjxM3SBvneypMx3RK 2q7bE3Jx8Wg1Kgk3U08vLDECP5mIbZbMebPvIin09fJGphjLFNXKkS4x0ilk10y739IbkvlsI dTTnnWEs44aQ0ovnWgXGjsuFHk/FME2GS/6vNHswRq/bVMVXD57R0br5gGMKsO3v450fs9L/L nPJsMLaXSBjIdTVg22/41weKsPVWv30k0ttSyf+/33B2DVYEgHorx/bgRAvjFG4BF08AGkJUy AIiRuXfNYe18eatlo31sU+dwuKmTCngR0uycwZC84DKtcpV9d7N1RQmpL1PBXi4EYHQWMKoRk OKzAoJ4isPlXEnH08el8QAD0MI4AOtbxVzpkOwEratlDOyU0DvTsnz50TGlY0Avwv2NkTTN2O mztenrYXwsyrqDKaw9MdkqyQaLadR8LhloWDDYgBIYNouq2EAgHhe5lcSDeN9+sVvF6Ij2mFp 6HLfpttzdzyPZDCo4SwWlrT5T2x0AREjzZ9AAvJgyd5BMx8cs9HR4ouE+9E9pvDeZGBmJSXo/ WL7SnRQuQnS6R9bJGFO7rPUA1Lhdn6UsXG9BH/kkJWEasWn9Zs= Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 04:19:55 -0000 On 2017-09-25 00:27, Robert Moskowitz wrote: > ... > Can these be added to http://xml2rfc.tools.ietf.org/public/rfc/bibxml2/ ? > > Note the URL change for where FIPS docs are from the 'old' > > http://csrc.nist.gov/publications/fips > > Currently, I cannot find any SP in the bibxml area. > ... There's nothing wrong in just having the referenced data inlined into your XML source. Best regards, Julian From nobody Sun Sep 24 23:02:21 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DBE126B6D for ; Sun, 24 Sep 2017 23:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 K5xjRo_0ewuG for ; Sun, 24 Sep 2017 23:02:17 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CD2912426E for ; Sun, 24 Sep 2017 23:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v8P62BjE025958; Mon, 25 Sep 2017 08:02:11 +0200 (CEST) Received: from [172.20.10.9] (ip-109-45-1-12.web.vodafone.de [109.45.1.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3y0tlR21xqzDMF9; Mon, 25 Sep 2017 08:02:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <8fb2f6de-5694-c02a-50fc-17b23f6b3c66@htt-consult.com> Date: Mon, 25 Sep 2017 08:02:08 +0200 Cc: "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 528012128.437585-69ae0b97aef227520938d5979f64b1b1 Content-Transfer-Encoding: quoted-printable Message-Id: References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> <8fb2f6de-5694-c02a-50fc-17b23f6b3c66@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 06:02:19 -0000 > On Sep 25, 2017, at 03:00, Robert Moskowitz = wrote: >=20 >=20 >=20 > On 09/24/2017 08:21 PM, Carsten Bormann wrote: >> On Sep 25, 2017, at 00:27, Robert Moskowitz = wrote: >>> I need a couple FIPS and SP800 references: >>>=20 >>> >>> >>> SHA-3 Standard: Permutation-Based Hash and Extendable-Output = Functions >>> >>> National Institute of Standards and = Technology >>> >>> >>> >> FIPS.202.2015: DOI.10.6028/NIST.FIPS.202 >>=20 >>> >>> >>> SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and = ParallelHash >>> >>> National Institute of Standards and = Technology >>> >>> >>> >> SP800-185: DOI.10.6028/NIST.SP.800-185 >>=20 >> Paste this into your markdown source. >=20 > I'm stubborn I don=E2=80=99t know how to help you with that :-) > and use xml. So I need an xml source=E2=80=A6 The doilit tool that comes with kramdown-rfc2629 spits out xml if you = want: $ doilit -x=3DFIPS.202.2015 10.6028/NIST.FIPS.202 SHA-3 Standard: Permutation-Based Hash and Extendable-Output = Functions As Julian says, you don=E2=80=99t lose anything by pasting this in, as = the info behind the DOI is not really going to change. You also can fix = weirdness in the database (or, this time, in the tool: the series info = with []; haven=E2=80=99t seen that before, to be fixed). Or, if pasting XML like that is too radical, you can use bibxml7: But then you have to live with any weirdness that may come up. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Sep 25 10:33:19 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5CA134530 for ; Mon, 25 Sep 2017 10:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 7AgLOs048mnC for ; Mon, 25 Sep 2017 10:33:13 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16D9413451F for ; Mon, 25 Sep 2017 10:33:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 550FE6228F; Mon, 25 Sep 2017 13:33:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nNhEbRjEG3nj; Mon, 25 Sep 2017 13:33:04 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 8A75162247; Mon, 25 Sep 2017 13:33:03 -0400 (EDT) To: Carsten Bormann Cc: "xml2rfc@ietf.org" References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> From: Robert Moskowitz Message-ID: Date: Mon, 25 Sep 2017 13:32:55 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> Content-Type: multipart/alternative; boundary="------------55B87F4C137A8F0A295A5099" Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 17:33:18 -0000 This is a multi-part message in MIME format. --------------55B87F4C137A8F0A295A5099 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 09/24/2017 08:21 PM, Carsten Bormann wrote: > On Sep 25, 2017, at 00:27, Robert Moskowitz wrote: >> I need a couple FIPS and SP800 references: >> >> >> >> SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions >> >> National Institute of Standards and Technology >> >> >> > FIPS.202.2015: DOI.10.6028/NIST.FIPS.202 I don't see how to include this in my xml. I tried putting it the normative references section and got: ERROR: Unable to validate the XML document: INPUT : Line 242: Element references content does not follow the DTD, expecting (reference)+, got (CDATA reference) > >> >> >> SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash >> >> National Institute of Standards and Technology >> >> >> > SP800-185: DOI.10.6028/NIST.SP.800-185 > > Paste this into your markdown source. > > Grüße, Carsten > > >> >> Can these be added to http://xml2rfc.tools.ietf.org/public/rfc/bibxml2/ ? >> >> Note the URL change for where FIPS docs are from the 'old' >> >> http://csrc.nist.gov/publications/fips >> >> Currently, I cannot find any SP in the bibxml area. >> >> Maybe someone can talk to Tim Polk about this... >> >> Bob >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc >> > --------------55B87F4C137A8F0A295A5099 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 09/24/2017 08:21 PM, Carsten Bormann wrote:
On Sep 25, 2017, at 00:27, Robert Moskowitz <rgm@htt-consult.com> wrote:

I need a couple FIPS and SP800 references:

<reference anchor="FIPS.202.2015" target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf">
<front>
<title>SHA-3 Standard:  Permutation-Based Hash and Extendable-Output Functions</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="August" year="2015"/>
</front><seriesInfo name="FIPS" value="PUB 202"/></reference>

    FIPS.202.2015: DOI.10.6028/NIST.FIPS.202

I don't see how to include this in my xml.  I tried putting it the normative references section and got:

ERROR: Unable to validate the XML document: INPUT
 <string>: Line 242: Element references content does not follow the DTD, expecting (reference)+, got (CDATA reference)








<reference anchor="SP.800_185.2016" target="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf">
<front>
<title>SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="December" year="2016"/>
</front><seriesInfo name="Special Publication" value="SP 800-185"/></reference>

   SP800-185: DOI.10.6028/NIST.SP.800-185

Paste this into your markdown source.

Grüße, Carsten




Can these be added to http://xml2rfc.tools.ietf.org/public/rfc/bibxml2/ ?

Note the URL change for where FIPS docs are from the 'old'

http://csrc.nist.gov/publications/fips

Currently, I cannot find any SP in the bibxml area.

Maybe someone can talk to Tim Polk about this...

Bob

_______________________________________________
xml2rfc mailing list
xml2rfc@ietf.org
https://www.ietf.org/mailman/listinfo/xml2rfc

--------------55B87F4C137A8F0A295A5099-- From nobody Mon Sep 25 11:48:02 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B8013453F for ; Mon, 25 Sep 2017 11:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 x3DkJ1T0j4Ok for ; Mon, 25 Sep 2017 11:48:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 ACA0C134526 for ; Mon, 25 Sep 2017 11:47:59 -0700 (PDT) Received: from [192.168.178.20] ([93.217.120.208]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LqV4f-1dRdS22ULJ-00e6fw; Mon, 25 Sep 2017 20:47:43 +0200 To: Robert Moskowitz , Carsten Bormann Cc: "xml2rfc@ietf.org" References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> From: Julian Reschke Message-ID: Date: Mon, 25 Sep 2017 20:47:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:8rD2Feu7p/B53VFuP8pQT0bV3y5TCaK/m3T+BSWZoZPrhV4Kq6C j+QfLqXJYuOYMiKJuZH7Zw3PimM95oOSTt1t1daJGM70y/BTOcuWf8CupyIXubo2ZeBYsSh i61m4jdRr5gxOXCfeBB1EHHYzUsVJM3c0Ggw4NcmN+sKl5hKwtleZtWYZ4QcjrpsPsz79SB f8N0vgm7L89gkUY6EA1Gw== X-UI-Out-Filterresults: notjunk:1;V01:K0:gg3GcO1mXEg=:jSjkoMMARKuevEe1+PPPKr j/F8ndhBoSRHTqAuTp9QIgZVfd0M7ZVSNQw2lz8XIjGbSGlZdYUpPIKsjqIn8Rk+iixo9lnE2 1OSWv224g000tSUJb+f0JJJUNcLOiKR9toK9x7rVh2RDchEBflJYTbxFC8knxbZVrdayvnqlh 23moQ7wZfrWoFwS9Mo2NYEV5owwQV5HCg9ACyNppg44o80xw25wdN82bguWAGU6dDVBqIFjQH ptVUQoHXywWk+qCGYTzb4ijUA8aHJnT0I9yZ1isBY00inmwYpLenxUexITDr6XqfnouQU10r6 RUK5LzfHf9MUiRVCcYyOg04PLvJN8+YsOXR+eTjqc4KyZ0Qs4u8tb61uc/FVjGjU/atQuVZTg m9v5WvjIcdKosX+x9OMHRuC+8Lm6bMN7g1JH/kmB4zeSYTTGbaobfnsCiwn54jabtXnhYdVGx 046T5PzoqZCu/SEaKziCUGR8lPcRfevkpyEwp/XYsi9p4qJvGrh17j13NlUqK6ZOqhq9HFub8 wWv19Ae8ZJudFYktU8wfA7wysgyiljaIWx41fkndFicHh4+TTVAVfBkeXeuZObCcxTAgbtZ9B 1IprOkv+yfZKSskoId/fJ/+nXSKi8dfGpaUaPsewwbq7n+c5Bt+a+iALb7mJAD5R+mJtnFPOM Yn3eOF9yuwRXUtROekvUMp50dFKE9xccJ9Uxwx9zxU8hx82OAeKuvBadFeOoVir5cPtqJkC86 4tPQ33lgMGeLKGi+VJ7XLejKswJwEVvVrSCiH8iFYX+hcv4XtgnjTVZ3rD1KtjkJS68jnLs3B RA38m4sMwLFW+Rs44Bu5KK6ksJonzsqrd6wwTa5pseBR4i5fu4= Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 18:48:02 -0000 On 2017-09-25 19:32, Robert Moskowitz wrote: > > > On 09/24/2017 08:21 PM, Carsten Bormann wrote: >> On Sep 25, 2017, at 00:27, Robert Moskowitz wrote: >>> I need a couple FIPS and SP800 references: >>> >>> >>> >>> SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions >>> >>> National Institute of Standards and Technology >>> >>> >>> >> FIPS.202.2015: DOI.10.6028/NIST.FIPS.202 > > I don't see how to include this in my xml.  I tried putting it the > normative references section and got: > > ERROR: Unable to validate the XML document: INPUT > : Line 242: Element references content does not follow the DTD, expecting (reference)+, got (CDATA reference) Please provide the full file, or at least an excerpt that shows what you are doing... From nobody Mon Sep 25 12:02:07 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A90134552 for ; Mon, 25 Sep 2017 12:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 A4Z3PP0qznJW for ; Mon, 25 Sep 2017 12:02:02 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A9C013454E for ; Mon, 25 Sep 2017 12:02:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0F61162247; Mon, 25 Sep 2017 15:02:00 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6zgttbUGg66J; Mon, 25 Sep 2017 15:01:46 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id F406062150; Mon, 25 Sep 2017 15:01:44 -0400 (EDT) To: Julian Reschke , Carsten Bormann Cc: "xml2rfc@ietf.org" References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> From: Robert Moskowitz Message-ID: <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> Date: Mon, 25 Sep 2017 15:01:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------0366386443E51207D4AAF720" Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 19:02:05 -0000 This is a multi-part message in MIME format. --------------0366386443E51207D4AAF720 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 09/25/2017 02:47 PM, Julian Reschke wrote: > On 2017-09-25 19:32, Robert Moskowitz wrote: >> >> >> On 09/24/2017 08:21 PM, Carsten Bormann wrote: >>> On Sep 25, 2017, at 00:27, Robert Moskowitz >>> wrote: >>>> I need a couple FIPS and SP800 references: >>>> >>>> >>> target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf"> >>>> >>>> SHA-3 Standard: Permutation-Based Hash and >>>> Extendable-Output Functions >>>> >>>> National Institute of Standards and >>>> Technology >>>> >>>> >>>> >>> FIPS.202.2015: DOI.10.6028/NIST.FIPS.202 >> >> I don't see how to include this in my xml. I tried putting it the >> normative references section and got: >> >> ERROR: Unable to validate the XML document: INPUT >> : Line 242: Element references content does not follow the >> DTD, expecting (reference)+, got (CDATA reference) > > Please provide the full file, or at least an excerpt that shows what > you are doing... > Here is the full xml. I want to add the reference for FIPS 202 and SP 800-185. I can just add the xml to the normative reference section. I would like to use a public standing xml. Also I looked at the xml at: https://xml2rfc.tools.ietf.org/public/rfc/bibxml7/reference.DOI.10.6028/NIST.FIPS.202.xml?anchor=FIPS.202.2015%E2%80%9D and the reference anchor is rather not nice to have in the ID, as it has no punctuation. There are other issues with it but that is the 'first'. Bob --------------0366386443E51207D4AAF720 Content-Type: text/xml; name="draft-moskowitz-small-crypto-00.xml" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="draft-moskowitz-small-crypto-00.xml" ]> Small Crypto for Small IOT Huawei
Oak Park MI 48237 rgm@labs.htt-consult.com
Huawei
No. 101, Software Avenue, Yuhuatai District Nanjing China Frank.xialiang@huawei.com
Security Area CURDLE RFC Request for Comments I-D Internet-Draft Keccak EDDSA IOT This memo proposes to leverage the Keccak algorithm at a function "width" of b=400 to provide a set of "small" cryptographic functions well suited to the IOT constrained environment. As such, only 128 bit security level is provided here. The full set of NIST approved Keccak derived functions that can work within the b=400 constraint, plus the 3rd round candidate in the CAESAR competition, Ketje, are defined.
The Keccak algorithm at a width of b=1600 was selected by NIST for SHA-3 as defined in FIPS 202. It is further used to define additional hashing functions in NIST SP 800-185, all with b=1600. This selection is well suited for 64 bit processors and large messages. It can take advantage of multiple core CPUs and works well even on 32 bit processors. It is not well suited for small messages and 8 bit processors that are common in IOT. A full set of function widths of 25, 50, 100, 200, 400, and 800 are also defined in Keccak. Selection of values of other than 1600 is a risk/design trade off. A width of 400 is used here as the smallest that can provide 128 bits security strength. Keccak provides more than a secure hash function. FIPS 202 defines the SHAKE function to provide a hash output of arbitrary length, rather than current practice of truncating a longer hash to the needed length. SP 800-185 defines a keyed hash, KMAC, that does not require the HMAC complexity and computational cost. This also can provide a PRF. Finally, Keccak also provides an AEAD cipher, Ketje, to thus deliver in a single base function, the full suite of symmetric cryptographic functions.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
This section will contain notations
TBD
Keccak is a extendable-output function (XOF) sponge construction hash. It breaks from the 'standard' ARX (addition, rotation and exclusive-or (XOR)) hash approach. Instead it using only bit-level transpositions, bit-level additions and multiplications (in GF(2)). This contributes to its superior performance. This leads to one important nomenclature difference in Keccak. It does not have a block size. Rather in Keccak there is bit-rate which is one of the variable parameters.
The Keccak primitive is:
Instances are denoted
The instance Keccak[144,256] can be used for SHAKE128 [FIPS 202], cSHAKE128, KMAC128, KMACXOF128, TupleHash128, TupleHashXOF128, ParallelHash128, ParallelHashXOF128 [SP 800-185]. The difference is a bitrate of 144 rather than 1344. Some of the above variants, such as the parallel hashes are not of value in small devices with small r which is not amendable to tree hashing. To distinguish the form of the above hashes between the standard r=1344 and r=144, a designation of 'i' is appended to each name so that here SHAKE128i and KMAC128i are used.
Ketje Sr is already defined to use b=400.
Ed25519, RFC 8032, specifies the parameter H(x) as SHA-512. A new form, Ed25519i, will use SHAKE128i for H(x). This one change will bring Ed25519 more into the 'reach' of the constrained environment. The use of SHAKE128i is the only variant between Ed25519 and Ed25519i.
TBD. OID assignments
The safety margin in Keccak can be increased or de-creased simply by changing the number of rounds in Keccak-f. This is explained in "Note on Keccak parameters and usage", Section 6.
This memo proposes a radical change in the basic cryto-primatives used in protocols. As such, care is called for. Keccak is not new. It has been well reviewed as explained in "Why Keccak is not ARX". Still, it is important to compare each Keccak function proposed here against the current Best Practice.
TBD.
TBD.
TBD.
TBD.
Sections here draw heavily on information available on the Keccak site. I thank the Keccak Team in making this information openly available.
FIPS.202.2015: DOI.10.6028/NIST.FIPS.202 &IEEE.802.15.6_2012; Note on Keccak parameters and usage
Radboud University
STMicroelectronics
STMicroelectronics
Team Keccak Home Page
Radboud University
STMicroelectronics
STMicroelectronics
STMicroelectronics
Why Keccak is not ARX The Ketje authenticated encryption scheme
Radboud University
STMicroelectronics
STMicroelectronics
STMicroelectronics
TBD.
In-body sensors, like pacemakers, connected via the Body Area Network (BAN) will be very power conscious. Battery replacement can often require surgery. This will lead to loose interpretation of the HIPAA protection requirements to the detriment of the patient. In-body sensors are an important class of devices that would benefit from the most power and code efficient security components that still meet a strong security claim.
CAN FD (CAN with Flexible Data-Rate) is an extension to the original CAN bus protocol specified in ISO 11898-1. Developed in 2011 and released in 2012. Its larger data payload of 64 bytes can support a encrypting and authenticating protocol, but various in-vehicle constraints can make this challenging. Sensors may be in a very high temperature environment, making even a marginal CPU temperature increase due to heavy computations catastrophic. Cost is always a automotive component constraint and security tends to come in last in the cost competition. Thus any way that the cost of security can be lowered is a major win.
BACnet (ISO 16484-5) is the standard for wired, in-building control systems. Recently IPv6 support (RFC 8163) was added. Some BACnet devices are extremely constrained; 4-bit processors are still common. Though AES on such 4-bit processors is available, it is extremely slow. A smaller security suite would be a real benefit for this environment.
TBD.
TBD. Magnitude faster?
TBD.
TBD.
TBD.
TBD.
--------------0366386443E51207D4AAF720-- From nobody Mon Sep 25 12:43:01 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310071345A2 for ; Mon, 25 Sep 2017 12:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 9E-o2xeBIDRj for ; Mon, 25 Sep 2017 12:42:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 60ECC1345A1 for ; Mon, 25 Sep 2017 12:42:46 -0700 (PDT) Received: from [192.168.178.20] ([93.217.120.208]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LtJ5T-1dCkCn11j9-012n0y; Mon, 25 Sep 2017 21:42:34 +0200 To: Robert Moskowitz , Carsten Bormann Cc: "xml2rfc@ietf.org" References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> From: Julian Reschke Message-ID: Date: Mon, 25 Sep 2017 21:42:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:+k4I9HhAqlr6Axm6lVwhFSpdbdm+uVSCFSVTsiTzQIkL8djh5Ju +qN9YvnFzyx7h+j1zpDTey07e+UCLDbRAUyJV4L65l7n7qQnlHRQDGMy2fmV70lHX3huUlp TUh9m0JLMWI20IH2PCLsVOCIqkBexDJ4RcfwyrkQA1pXIOp77dS+mYFKAxe8azyUJvN6P6o Nj3EPW6yQ7ggyXyZ/mFAw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Mg5W0zZlUU0=:Svz8QMkpbmL14u+94AWxE6 SmcQPQMoFAkpYR5vSFGR6IdKiBJUd18L4z0aiiiWHvSJ7qiVMTtuNPv2hbHEzjgADAv0Yb+BU UgaagZcNzL2/K6RQfCQMah/YLYX94NMp3My9XeAljBQKu/4uhP2qBUbXMU5+QEkTKS2SWYZnq 7G3Z+iKepkXV2XLrYk/nbzHIdl5tq2EePispgDzGlFhn+Gt5hlkMX8jFEfyvn00OjnUZQiIVH NIbUFnG83dqFqVZucK5cVqksSzEcI1UP3CqYJcVMFKzo+5W2kD2tWjg+YDlpAg/iS33ZhtQVS wF+gLZS8J80NS1bY017KHBpV8GlqgWWRGwfJ4YJybrzM8phtCGJGKVMxA3ffE1ui0QJMJQP5M XQjQB1Bfnwvh6qwtUdLw/kW3BZKlgJ208/qikaeOyaWPzRytlfYrE9nYN6HPYbqZrsMnWPs6Q 4FEVPRQSOYiLDzm6vKeJ39TJ3KV0IvdJvJQTQnvZUwa/Tw14ecPZI/Gn9RY+OTk/jAWIUaycw cdPjsGul6FQhPh4WjzZhybJtLX6jNTVkwIPiIB7UADnqvWKBQCRN2AKW7opA/raVszO3JOSIa Yao55kqWArQaPPPBVaVzQz4fAMkN7LK2ng4/gatk+d9Byu/KoHiCmFOHGmzZhbfEgXXwBus5v 2MfKoPGSoXrSmqJN2DDOP0tOKAaUTmnFJ4fN2hos3M74StaaTt99fF8SBiPVBe7doCISQGicE Aleowdnthc5IRsNObAdJZdkDbWWyWyBu5WRNvC7vd/z46unRsS2B1tfy66KIssWHMD3tVXftG nAsAQbQERfcC1HoHgOOMRvEO60IvXZOlYZexXolr9s0eCl3zPY= Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 19:42:59 -0000 On 2017-09-25 21:01, Robert Moskowitz wrote: > ... What you did is that you added markdown text into XML. That doesn't work. You'll have to include the elements. Best regards, Julian From nobody Mon Sep 25 12:54:22 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC8C134592 for ; Mon, 25 Sep 2017 12:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 JfG07SmR5xSa for ; Mon, 25 Sep 2017 12:54:18 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BEED134576 for ; Mon, 25 Sep 2017 12:54:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 77AE462140; Mon, 25 Sep 2017 15:54:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qK9mCrX46gpn; Mon, 25 Sep 2017 15:54:15 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 85B59620D4; Mon, 25 Sep 2017 15:54:14 -0400 (EDT) To: Julian Reschke , Carsten Bormann Cc: "xml2rfc@ietf.org" References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> From: Robert Moskowitz Message-ID: Date: Mon, 25 Sep 2017 15:54:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 19:54:21 -0000 On 09/25/2017 03:42 PM, Julian Reschke wrote: > On 2017-09-25 21:01, Robert Moskowitz wrote: >> ... > > > What you did is that you added markdown text into XML. That doesn't > work. You'll have to include the elements. > > Best regards, Julian > > Then what did you mean by: "There's nothing wrong in just having the referenced data inlined into your XML source." A few messages back. That was the nature of my reply to Carsten. I work in XML, he gave me a markdown answer. Which also points to some orphaning of the xml capability. Bob Bob From nobody Mon Sep 25 13:58:37 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D9C134576 for ; Mon, 25 Sep 2017 13:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 K9wIo931jnMi for ; Mon, 25 Sep 2017 13:58:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 C94D1132055 for ; Mon, 25 Sep 2017 13:58:33 -0700 (PDT) Received: from [192.168.178.20] ([93.217.120.208]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MYKGj-1drpD03P4j-00V8at; Mon, 25 Sep 2017 22:58:19 +0200 To: Robert Moskowitz , Carsten Bormann Cc: "xml2rfc@ietf.org" References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> From: Julian Reschke Message-ID: Date: Mon, 25 Sep 2017 22:58:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:rZqvlcOYhzaqBGSWYR5m/cTLy43OMWOBh29fG0fMu1cp630I/17 bTieKUUiDxnZ7fdb+amApDDTejDs+4mOEcgjKgZWXNst3pLnrU+JEsBMrzl2/earxmuczrH xtGdcKup4mZ7fpTQzGycoBvUZU4r3vmMzxIOvoL5zcl/QlzRdV9M3eqUTTIpVLoAB3CHo23 iNvMxgUKpytc3gBmOZJCg== X-UI-Out-Filterresults: notjunk:1;V01:K0:kuOr6YanCE8=:rp6lBZ6VORw/1Ww5cMy7ij SWW3SxhnAHxAV5VqNINKPNvVHxjagNgoY3EE+nRiD/OtYYT/2lL5MPCUFTXz/vnDSESLqEWDI Iz4er3HbB/aldJccV8gChXUVR4vFp3oixp+z79efvINKInqwnUzGm1KVF4xb3sU05sxcG9su+ hnSAxD/MHbgCtRnWU1jr90p6uGG2M58QqBK2+kVJh4Z0jVMgD7viR7C1xkCYHI7yvWQ7iNcsW jZpPv6AMBQE2WtiVm9OlJeNgpgyTq36HD6je5ilvEN+Q691C7X/CKud+a1SgoWD/4E5xB54Mi 9Emp53cSJBckcntiJ6ho/gpWjBaXv46FYVuvewUep3QMFrXICW8af7FPLKfTw3LjqZ6v6pYvi A33PBeypfgogwzWtz9iBcPqL/SucDAyE+AVxm+zmEOvEP/b1Vmy620rNi7H1u2O3No1ClL3hS rtGBPA9jmf5n9ZV/JBk0Ap2YNlTRaY9hEGP1zWPH8EJK99zN1m2Hrj7+BGYxXBF5FHhaoT+pC kR0E4xCEyYv2IFTlI1ut8T3eWBzZWgQGV2NLH6UTrNFl3uDZfeLe4hM7wqhCD5jjqSuqbgjTC u5mV/t675fx1SaUcfKGr6voTMogmehlhvZfKRQ4q85IJLw4+chXpxwSW5xXSmwtGrn1ZYxplh buQ9v6TSGGZE/umEtHGhKAVBslMBRnGjpVUuwj70LqnYWluQWbd5HXSO8K+uh+yBGfhpJr9QR oygSod2IJ3w0aqnLrbUk2MPOjSw65sTU1Mzmbe2/XPgnBOLYGGl4RsIcYpH3TLDba8w9HQiOk 3CHE+Xc1hAU2NG8h806k+G5W2rJZr1wfg3oRE46f1I7HPA9FZI= Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 20:58:36 -0000 On 2017-09-25 21:54, Robert Moskowitz wrote: > > > On 09/25/2017 03:42 PM, Julian Reschke wrote: >> On 2017-09-25 21:01, Robert Moskowitz wrote: >>> ... >> >> >> What you did is that you added markdown text into XML. That doesn't >> work. You'll have to include the elements. >> >> Best regards, Julian >> >> > Then what did you mean by: > > "There's nothing wrong in just having the referenced data inlined into > your XML source." > > A few messages back. > > That was the nature of my reply to Carsten.  I work in XML, he gave me a > markdown answer.  Which also points to some orphaning of the xml > capability. a) markdown is used by some people as *frontend*, not replacement b) pleas go back and re-read what Carsten and I wrote Best regards, Julian From nobody Mon Sep 25 14:16:56 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A711345A5 for ; Mon, 25 Sep 2017 14:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 4ovcUMP4aUWW for ; Mon, 25 Sep 2017 14:16:52 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791C81345A8 for ; Mon, 25 Sep 2017 14:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v8PLGkGr021275; Mon, 25 Sep 2017 23:16:46 +0200 (CEST) Received: from [172.20.10.9] (ip-109-45-0-30.web.vodafone.de [109.45.0.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3y1H2k1BKyzDL3x; Mon, 25 Sep 2017 23:16:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Mon, 25 Sep 2017 23:16:42 +0200 Cc: Julian Reschke , "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 528067002.754701-92a39a958577ef0ca3e305f30fb75435 Content-Transfer-Encoding: quoted-printable Message-Id: References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 21:16:54 -0000 On Sep 25, 2017, at 21:54, Robert Moskowitz wrote: >=20 > That was the nature of my reply to Carsten. I work in XML, he gave me = a markdown answer. =20 Yes. On this list, we are in different stages of transitioning away = from XML as an *authoring* format. Which is why I gave a markdown-specific answer first (and Julian pointed = out how to do this in XML). > Which also points to some orphaning of the xml capability. XML (soon with a new DTD colloquially referred to as =E2=80=9CRFCXML = v3") will continue to be the preferred *submission* format, and of = course authoring right in the submission format will always be possible. = That=E2=80=99s why I gave two ways to generate the references to NIST = documents right in XML in my second answer: one for pasting in the = RFCXML reference format, and one for doing the usual bibxml dance = (=E2=80=9CSystem entity reference=E2=80=9D =E2=80=94 well, I only gave = the entity definition) at formatting time. By the way, all the examples I gave allow you to change the anchor = (label) as desired =E2=80=94 for entity imports from bibxml this works = with bibxml7, as these are dynamically generated, but not for most other = bibxml categories. Now for finding the seriesinfo strangeness... Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Sep 25 14:53:41 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D621345C6 for ; Mon, 25 Sep 2017 14:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 MgOt8cRE6k6U for ; Mon, 25 Sep 2017 14:53:38 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C538713202D for ; Mon, 25 Sep 2017 14:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v8PLrVRi021691; Mon, 25 Sep 2017 23:53:31 +0200 (CEST) Received: from [172.20.10.9] (ip-109-45-0-30.web.vodafone.de [109.45.0.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3y1Hs670vQzDL4M; Mon, 25 Sep 2017 23:53:30 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Mon, 25 Sep 2017 23:53:30 +0200 Cc: "HANSEN, TONY L" , "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 528069209.958644-8c26460c3734853f79c6c81edf1bc3e4 Content-Transfer-Encoding: quoted-printable Message-Id: <99EB97B1-938E-4A81-A628-522BE91F3CF4@tzi.org> References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 21:53:39 -0000 On Sep 25, 2017, at 23:16, Carsten Bormann wrote: >=20 > Now for finding the seriesinfo strangeness... Fixed in kramdown-rfc2629 1.2.6 (1.2.5 could not deal with empty = container-titles). Please gem update as convenient. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Sep 25 14:56:43 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB621345D4 for ; Mon, 25 Sep 2017 14:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 bP5D2WerH486 for ; Mon, 25 Sep 2017 14:56:40 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 233B61345D1 for ; Mon, 25 Sep 2017 14:56:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 16AD0622B8; Mon, 25 Sep 2017 17:56:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Tj73nhWRj7yP; Mon, 25 Sep 2017 17:56:33 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id A5764622B6; Mon, 25 Sep 2017 17:56:32 -0400 (EDT) To: Julian Reschke , "xml2rfc@ietf.org" References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> From: Robert Moskowitz Message-ID: Date: Mon, 25 Sep 2017 17:56:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 21:56:42 -0000 Julian, I am going back as you said... On 09/25/2017 12:19 AM, Julian Reschke wrote: > On 2017-09-25 00:27, Robert Moskowitz wrote: >> ... >> Can these be added to >> http://xml2rfc.tools.ietf.org/public/rfc/bibxml2/ ? >> >> Note the URL change for where FIPS docs are from the 'old' >> >> http://csrc.nist.gov/publications/fips >> >> Currently, I cannot find any SP in the bibxml area. >> ... > > There's nothing wrong in just having the referenced data inlined into > your XML source. What data are you referring to that I can place inline in the XML? I am missing something here. Bob > > Best regards, Julian > From nobody Mon Sep 25 15:06:53 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271F21345D7 for ; Mon, 25 Sep 2017 15:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 4ox4FOxWHQoI for ; Mon, 25 Sep 2017 15:06:47 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A861345CA for ; Mon, 25 Sep 2017 15:06:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 8B294622C8; Mon, 25 Sep 2017 18:06:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9zg1TV4mIdsT; Mon, 25 Sep 2017 18:06:40 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 1F07C622A8; Mon, 25 Sep 2017 18:06:33 -0400 (EDT) To: Carsten Bormann Cc: Julian Reschke , "xml2rfc@ietf.org" References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> From: Robert Moskowitz Message-ID: <50613851-e0f0-e681-740f-e5f70b720a79@htt-consult.com> Date: Mon, 25 Sep 2017 18:06:25 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 22:06:49 -0000 On 09/25/2017 05:16 PM, Carsten Bormann wrote: > On Sep 25, 2017, at 21:54, Robert Moskowitz wrote: >> That was the nature of my reply to Carsten. I work in XML, he gave me a markdown answer. > Yes. On this list, we are in different stages of transitioning away from XML as an *authoring* format. > Which is why I gave a markdown-specific answer first (and Julian pointed out how to do this in XML). > >> Which also points to some orphaning of the xml capability. > XML (soon with a new DTD colloquially referred to as “RFCXML v3") will continue to be the preferred *submission* format, and of course authoring right in the submission format will always be possible. That’s why I gave two ways to generate the references to NIST documents right in XML in my second answer: one for pasting in the RFCXML reference format, and one for doing the usual bibxml dance (“System entity reference” — well, I only gave the entity definition) at formatting time. Since the bibxml url seems to have a strange xml for the nist docs, I have put some xml reference right into the draft for now. > By the way, all the examples I gave allow you to change the anchor (label) as desired — for entity imports from bibxml this works with bibxml7, as these are dynamically generated, but not for most other bibxml categories. I have read the docs, and don't see, short of including the xml directly into the reference section to change the anchor label used in the ID. The one example in the docs show how to change RFC4306 to IKEv2 by including the whole xml. This has always been a no fun issue with long draft names as references. I had tried altering: To: Which follows the IEEE naming requirement (1AR is a self-standing standard, not an addendum to another standard and thus MUST be capitalized when referenced), and then put &IEEE_802_1AR in the reference section and got an error for my efforts. > > Now for finding the seriesinfo strangeness... > > Grüße, Carsten > > From nobody Mon Sep 25 21:18:10 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C0613466F for ; Mon, 25 Sep 2017 21:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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 7V0KS9YbDz_s for ; Mon, 25 Sep 2017 21:18:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 41ACE13466E for ; Mon, 25 Sep 2017 21:18:06 -0700 (PDT) Received: from [192.168.178.20] ([93.217.116.245]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Md3ZK-1dfa8X3Yv4-00IAeL; Tue, 26 Sep 2017 06:17:47 +0200 To: Carsten Bormann , Robert Moskowitz Cc: "xml2rfc@ietf.org" References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> From: Julian Reschke Message-ID: <31150ef8-fd63-c104-1127-60755dcdb6ce@gmx.de> Date: Tue, 26 Sep 2017 06:17:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:v7oD5XERDXng+H9HW0cNyoNIUMs4V+NAMS5a1mp3WqNTRHFkrIN IAvavVWV6KtmfQY9KAX4iNa8sbtQDvz8HzsxiP/Fwm7ECmDeRJSV6jC0iuLiYsCoPM7Mi6J rGJWTm5+dGZeJMR2TqiHNnRE/pm/y0/uY26KO/3QTn0SRINRxTdjGZ4uOuCbvCkyljhho4m XV+yja9MChLOi2SS4BOAw== X-UI-Out-Filterresults: notjunk:1;V01:K0:87rJddgTgfA=:ogBZMT5gZpsxm1jP2YQdqz 82Mjx+u/kpCoFvKHZvuqNG8zhnh5EhRbVS5d+r7L2Gw6SEbQR7JCLg7iwx035rc/uWb+7H/I0 di4rjvpwVnQCviX5DFDuf6c5L3CYGAqJ23MZzBnk8N+5LlSn8ungPvAnzto9gsIf8JDE4Sg10 AuPJRXZlqL1axln/MSvqLoPXv1dX4fP7deAsiyv4F92RXZpoWbL5HBOWEZ1QE+StDd4IKKIzE qFqE0QK3PEwLnG+3ehui6gIWZ9ZaD8bgvbEx6PSU3vgqz1CuZ6IezGtq8yWlkK9f8f93yknZs zsIWird9nyvV5CeBOCRKUyK3MHmD/NM0z/7Pwz8Xi5J5E2bYnOtVSiPRRckEb8Ayh5ooU4rHu 8r0HGX/an2cL1LtqDIE5uc2LJN1r2dwgX5obp8dw087v+HrOVn9P1mqxHcMLlDI6nStsAJCAv PhifVqnE9RTzghoprvCioAzpkpX5F+1KPRXJnH2hSH8Ur5pg9ypOkEtenw7pZJ6KQOmwcsC/2 gW+J63LKcqntLt9LYnBCLXy0hqlE3kfJuq6k0tfqQw+AUyUuEYwTiHzMKCTqLff/D0JXnlOaM eqpa0MRNybHoFfAQQyOtU4r+84+SVIHf2/9jpj6RzTI5uyM3Hjb2pCdUgvKEeL4lA7pxbsfH8 63ZI9IZqCsx6L17wWe1GnkrcqyKoGIjyPqztVem4iI4WhL5NquEDJMP9ZkpqRqeX6/bidt3Mf 3TSDJfAYgk0b3XHJlgnGVCSBetafoVYTeedFQGJ1C+5m7rqCEMRbqLIwhDk0IP6XbKQR+A7WI RXtvHqithWhyANxpCVawJUdDQJsiFzcslA10wH44WM5OFYgtGs= Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 04:18:09 -0000 On 2017-09-25 23:16, Carsten Bormann wrote: > On Sep 25, 2017, at 21:54, Robert Moskowitz wrote: >> >> That was the nature of my reply to Carsten. I work in XML, he gave me a markdown answer. > > Yes. On this list, we are in different stages of transitioning away from XML as an *authoring* format. Clarifying: where one "stage" is: "not transitioning away at all". > ... Best regards, Julian From nobody Mon Sep 25 21:26:17 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B82133038 for ; Mon, 25 Sep 2017 21:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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 mnAbt2QhtTJi for ; Mon, 25 Sep 2017 21:26:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 AEC8E13219B for ; Mon, 25 Sep 2017 21:26:13 -0700 (PDT) Received: from [192.168.178.20] ([93.217.116.245]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LomJ1-1dPpSd0YTD-00gpvg; Tue, 26 Sep 2017 06:26:00 +0200 To: Robert Moskowitz , Carsten Bormann Cc: "xml2rfc@ietf.org" References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> <50613851-e0f0-e681-740f-e5f70b720a79@htt-consult.com> From: Julian Reschke Message-ID: <1d08d3bf-24aa-5b1b-f705-e60eedb146ef@gmx.de> Date: Tue, 26 Sep 2017 06:25:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <50613851-e0f0-e681-740f-e5f70b720a79@htt-consult.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:13SFzUXf/Ee2Ij3KaCigfGmvQTi8hh4W6J/APAJji7NJCvhGMJF 43Wbct4hEzLxn2rVpJkf2gbX5QnoRd61sEVfZoPF8wKhnbUaJjghO0YsU2oJVfONK3OvYR3 KS6rVa+THUt8L7xHAP9/DouRDnnPaVZNjYuEhGzyLlUh45d1hLa30bvt2pKPwCQJs48afLa DfLXx+LrQwbMKvmTv6G0A== X-UI-Out-Filterresults: notjunk:1;V01:K0:Ccx3U2xM6S4=:gWm4XCfFqY3x9tCCfw9yn0 yKH9HvfkAHVN6Jjmky6b3Esh2EiM7zWMN9dsXnxdZcXM5pGWiP95/KLtfvzbTBDp1D6xYBfRX wwT4TKhovKfD+kkL64wfIuR2iWtrfCQzgeE92fFAoqkbTLPr2mrntcIRYrYNZvyCfR1MyhQ1D 1r6s/RmJg7WCCKjH9N3uUEcloKAUjBNZDvecoAy+FLmwp83lr3ZGlW6GtM2GkY1bvUlXwb1vi FvKMHlasuww3uIM+9df0011SMgjX29dYvSE4GRsXy3ImM2qtrl3W3pLTAiP8T+LguZdV/4wtt eVaIl/t/gFXLAEzh2nBY7Gpi9p4Qe+OdAAcXl7GHuOi8KUT8AlCxlV5s1BEuX/QFeIduX/PWT KifJStyBRvWd0r2u7iG0VWUehUjYLTVvWfZShsMvkLc35sOwOVBX03X9PK7kz1ewW5oe+uXvn FvINqbJrvXsfb33AcF4iZSDl6DEItgRHmDOkH8v02ltzJW1qfvJ2BXIu5txaddCB8fQEa7NRZ ZanVJS0V1wgAZWKhaDu3g+5NzuDvw3+SMQJSIsslFPJPtz3AOZCuFYbq5KHYkumN6TPkYoANB fcZ0RhLZSiu0BncQ3jKJ2Te/xAP9Oi1r5xhvbmhzDsl261YN8BzAvC5me7j4SZJAfTmLH/cVP BD6XfEs5fSXeo+AChHVdqgqNlB/8WqZvdvzibaw6IzxmIky053ufXHKIBd8zPRgfRr0f0/9/c Dl5vs2kDCMN1jM0116igZMWktkOspYvUgitrqNzL0U3zw3uTtbjvD31bFdvlLwX0PnPJZWCRQ RLJQlwV/vH3scY3q2y7VJEdeSdNowpwQskNCCzF8ZZKPpNuWPc= Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 04:26:16 -0000 On 2017-09-26 00:06, Robert Moskowitz wrote: > ... > Since the bibxml url seems to have a strange xml for the nist docs, I > have put some xml reference right into the draft for now. > ... Yes. Why is that a problem? >> By the way, all the examples I gave allow you to change the anchor >> (label) as desired — for entity imports from bibxml this works with >> bibxml7, as these are dynamically generated, but not for most other >> bibxml categories. > > I have read the docs, and don't see, short of including the xml directly > into the reference section to change the anchor label used in the ID. The V3 vocabulary allows to rename references, see . This is not implemented yet in xml2rfc, but you can use rfc2629.xslt as preprocessor already (see ). > The one example in the docs show how to change RFC4306 to IKEv2 by > including the whole xml.  This has always been a no fun issue with long > draft names as references. > > I had tried altering: > >   "https://xml2rfc.tools.ietf.org/public/rfc/bibxml6/reference.IEEE.802.1AR_2009.xml"> > > > > To: > >   "https://xml2rfc.tools.ietf.org/public/rfc/bibxml6/reference.IEEE.802.1AR_2009.xml"> > > > Which follows the IEEE naming requirement (1AR is a self-standing > standard, not an addendum to another standard and thus MUST be > capitalized when referenced), and then put > > &IEEE_802_1AR > > in the reference section and got an error for my efforts. 1) I don't see how renaming the XML entity can possible affect the output. It's like renaming a variable a variable in a program. 2) I also don't see why it would cause an error. But if you don't show us either the source code or at least the error message, how are we supposed to help? Best regards, Julian From nobody Tue Sep 26 03:44:30 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742F71326FE for ; Tue, 26 Sep 2017 03:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 KXQTD40jG4ko for ; Tue, 26 Sep 2017 03:44:28 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4AD1321A4 for ; Tue, 26 Sep 2017 03:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v8QAiMmK025309; Tue, 26 Sep 2017 12:44:22 +0200 (CEST) Received: from [172.20.10.11] (ip-109-45-1-180.web.vodafone.de [109.45.1.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3y1cyY5Tj4zDLHH; Tue, 26 Sep 2017 12:44:21 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <31150ef8-fd63-c104-1127-60755dcdb6ce@gmx.de> Date: Tue, 26 Sep 2017 12:44:17 +0200 Cc: "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 528115457.2022-7507ad4f9dd57f28a18d7220060b9feb Content-Transfer-Encoding: quoted-printable Message-Id: References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> <31150ef8-fd63-c104-1127-60755dcdb6ce@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 10:44:29 -0000 On Sep 26, 2017, at 06:17, Julian Reschke wrote: >=20 >> Yes. On this list, we are in different stages of transitioning away = from XML as an *authoring* format. >=20 > Clarifying: where one "stage" is: "not transitioning away at all". :-) Sure, I remember being in that stage, too. Then, in 2010, I had to write/contribute to six I-Ds with a short = deadline. I just had gone through the experience of several non-trivial, = collaborative (and heavily version-controlled) docbook-based = documentation projects, and I remembered how much better these went once = we had switched to ASCIIDOC as the authoring format. So I gambled that I would save time by first writing a markdown to = RFCXML conversion tool and then writing the six I-Ds. Of course, I = don=E2=80=99t have a control group, but I believe that this did save a = lot of time. The choice fell on markdown for that tool instead of ASCIIDOC =E2=80=94 = not because it is better (it is not), but it already was widely = understood at the time, so it would be easier to collaborate on = documents that way. With the rise of git and github, both the = version-controlled collaborative approach and the use of markdown as an = authoring format have since received a considerable boost. The fact that another markdown-based authoring tool as well as an = org-mode based tool were created independently shows that other people = are also seeing benefits in authoring using close-to-plaintext formats. Our processing pipelines are now well-oiled for supporting these = authoring languages. The remaining problem happens when people want to collaborate on an RFC = who have different authoring language preferences. The = version-controlled approach pretty much rules out constant up- and = down-conversion, so it is usually necessary to agree on one language. = In the efforts I have been involved in, agreeing on markdown generally = has not been too hard. (Agreeing on American spelling has been harder = :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Sep 26 05:56:45 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BA51331F1 for ; Tue, 26 Sep 2017 05:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, 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 VnDIBY1HxSq3 for ; Tue, 26 Sep 2017 05:56:42 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C44913214D for ; Tue, 26 Sep 2017 05:56:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 33D886221B; Tue, 26 Sep 2017 08:56:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uJ63IwCGyiDj; Tue, 26 Sep 2017 08:56:36 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 10D7762220; Tue, 26 Sep 2017 08:56:35 -0400 (EDT) To: Julian Reschke , Carsten Bormann Cc: "xml2rfc@ietf.org" References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> <31150ef8-fd63-c104-1127-60755dcdb6ce@gmx.de> From: Robert Moskowitz Message-ID: Date: Tue, 26 Sep 2017 08:56:28 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <31150ef8-fd63-c104-1127-60755dcdb6ce@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 12:56:44 -0000 On 09/26/2017 12:17 AM, Julian Reschke wrote: > On 2017-09-25 23:16, Carsten Bormann wrote: >> On Sep 25, 2017, at 21:54, Robert Moskowitz wrote: >>> >>> That was the nature of my reply to Carsten. I work in XML, he gave >>> me a markdown answer. >> >> Yes. On this list, we are in different stages of transitioning away >> from XML as an *authoring* format. > > Clarifying: where one "stage" is: "not transitioning away at all". I am being pushed by one co-author that wants to write in kramdown, so I am going to have to learn a bit and a bit of github to send him updates. Other than that, I am very comfortable with xml and using Geany as my editor. I may only have a couple more active years here in the IETF, so I don't see the compelling need to change. And it took me long enough to get into xml! Bob > >> ... > > Best regards, Julian > From nobody Tue Sep 26 06:07:34 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25211332D7 for ; Tue, 26 Sep 2017 06:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, 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 YgqH5Uk2ob6F for ; Tue, 26 Sep 2017 06:07:31 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05811331FF for ; Tue, 26 Sep 2017 06:07:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D3BB46221B; Tue, 26 Sep 2017 09:07:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WF9lra8VgJER; Tue, 26 Sep 2017 09:07:11 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id BEF046221F; Tue, 26 Sep 2017 09:07:09 -0400 (EDT) To: Julian Reschke , Carsten Bormann Cc: "xml2rfc@ietf.org" References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> <50613851-e0f0-e681-740f-e5f70b720a79@htt-consult.com> <1d08d3bf-24aa-5b1b-f705-e60eedb146ef@gmx.de> From: Robert Moskowitz Message-ID: <6b52d93a-943c-57c0-c803-ef9363ffa6a2@htt-consult.com> Date: Tue, 26 Sep 2017 09:06:58 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1d08d3bf-24aa-5b1b-f705-e60eedb146ef@gmx.de> Content-Type: multipart/mixed; boundary="------------AE70AC4F63251546EB0F0C99" Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 13:07:33 -0000 This is a multi-part message in MIME format. --------------AE70AC4F63251546EB0F0C99 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 09/26/2017 12:25 AM, Julian Reschke wrote: > On 2017-09-26 00:06, Robert Moskowitz wrote: >> ... >> Since the bibxml url seems to have a strange xml for the nist docs, I >> have put some xml reference right into the draft for now. >> ... > > Yes. Why is that a problem? If there is an 'official reference', I would rather use that then craft my own. In this case, I don't think the official one is best. It leaves out the organization, NIST. The date is not the one in the pdf (off by a month). It lacks the FIPS info (or the SP 800 info). Never mind any discussion on the anchor name. > >>> By the way, all the examples I gave allow you to change the anchor >>> (label) as desired — for entity imports from bibxml this works with >>> bibxml7, as these are dynamically generated, but not for most other >>> bibxml categories. >> >> I have read the docs, and don't see, short of including the xml >> directly into the reference section to change the anchor label used >> in the ID. > > The V3 vocabulary allows to rename references, see > . > This is not implemented yet in xml2rfc, but you can use rfc2629.xslt > as preprocessor already (see > ). I will look into this. > >> The one example in the docs show how to change RFC4306 to IKEv2 by >> including the whole xml. This has always been a no fun issue with >> long draft names as references. >> >> I had tried altering: >> >> > "https://xml2rfc.tools.ietf.org/public/rfc/bibxml6/reference.IEEE.802.1AR_2009.xml"> >> >> >> >> To: >> >> > "https://xml2rfc.tools.ietf.org/public/rfc/bibxml6/reference.IEEE.802.1AR_2009.xml"> >> >> >> Which follows the IEEE naming requirement (1AR is a self-standing >> standard, not an addendum to another standard and thus MUST be >> capitalized when referenced), and then put >> >> &IEEE_802_1AR >> >> in the reference section and got an error for my efforts. > > 1) I don't see how renaming the XML entity can possible affect the > output. It's like renaming a variable a variable in a program. > > 2) I also don't see why it would cause an error. But if you don't show > us either the source code or at least the error message, how are we > supposed to help? See the attached. I have renamed the anchor, IEEE.802.15.6_2012 to IEEE.802.15.6 in the ENTITY line and followed through in the reference. I get the error: $ xml2rfc draft-moskowitz-small-crypto-00.xml Parsing file draft-moskowitz-small-crypto-00.xml ERROR: Unable to validate the XML document: draft-moskowitz-small-crypto-00.xml draft-moskowitz-small-crypto-00.xml: Line 364: IDREF attribute target references an unknown ID "IEEE.802.15.6" Oh, and I tried it online from http://xml2rfc.tools.ietf.org/ and am getting the 500 server error. Again. Bob --------------AE70AC4F63251546EB0F0C99 Content-Type: text/xml; name="draft-moskowitz-small-crypto-00.xml" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="draft-moskowitz-small-crypto-00.xml" ]> Small Crypto for Small IOT Huawei
Oak Park MI 48237 rgm@labs.htt-consult.com
Huawei
No. 101, Software Avenue, Yuhuatai District Nanjing China Frank.xialiang@huawei.com
Security Area CURDLE RFC Request for Comments I-D Internet-Draft Keccak EDDSA IOT This memo proposes to leverage the Keccak algorithm at a function "width" of b=400 to provide a set of "small" cryptographic functions well suited to the IOT constrained environment. As such, only 128 bit security level is provided here. The full set of NIST approved Keccak derived functions that can work within the b=400 constraint, plus the 3rd round candidate in the CAESAR competition, Ketje, are defined.
The Keccak algorithm at a width of b=1600 was selected by NIST for SHA-3 as defined in FIPS 202. It is further used to define additional hashing functions in NIST SP 800-185, all with b=1600. This selection is well suited for 64 bit processors and large messages. It can take advantage of multiple core CPUs and works well even on 32 bit processors. It is not well suited for small messages and 8 bit processors that are common in IOT. A full set of function widths of 25, 50, 100, 200, 400, and 800 are also defined in Keccak. Selection of values of other than 1600 is a risk/design trade off. A width of 400 is used here as the smallest that can provide 128 bits security strength. Keccak provides more than a secure hash function. FIPS 202 defines the SHAKE function to provide a hash output of arbitrary length, rather than current practice of truncating a longer hash to the needed length. SP 800-185 defines a keyed hash, KMAC, that does not require the HMAC complexity and computational cost. This also can provide a PRF. Finally, Keccak also provides an AEAD cipher, Ketje, to thus deliver in a single base function, the full suite of symmetric cryptographic functions.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
This section will contain notations
TBD
Keccak is a extendable-output function (XOF) sponge construction hash. It breaks from the 'standard' ARX (addition, rotation and exclusive-or (XOR)) hash approach. Instead it using only bit-level transpositions, bit-level additions and multiplications (in GF(2)). This contributes to its superior performance. This leads to one important nomenclature difference in Keccak. It does not have a block size. Rather in Keccak there is bit-rate which is one of the variable parameters.
The Keccak primitive is:
Instances are denoted
The instance Keccak[144,256] can be used for SHAKE128 [FIPS 202], cSHAKE128, KMAC128, KMACXOF128, TupleHash128, TupleHashXOF128, ParallelHash128, ParallelHashXOF128 [SP 800-185]. The difference is a bitrate of 144 rather than 1344. Some of the above variants, such as the parallel hashes are not of value in small devices with small r which is not amendable to tree hashing. To distinguish the form of the above hashes between the standard r=1344 and r=144, a designation of 'i' is appended to each name so that here SHAKE128i and KMAC128i are used.
Ketje Sr is already defined to use b=400.
Ed25519, RFC 8032, specifies the parameter H(x) as SHA-512. A new form, Ed25519i, will use SHAKE128i for H(x). This one change will bring Ed25519 more into the 'reach' of the constrained environment. The use of SHAKE128i is the only variant between Ed25519 and Ed25519i.
TBD. OID assignments
The safety margin in Keccak can be increased or de-creased simply by changing the number of rounds in Keccak-f. This is explained in "Note on Keccak parameters and usage", Section 6.
This memo proposes a radical change in the basic cryto-primatives used in protocols. As such, care is called for. Keccak is not new. It has been well reviewed as explained in "Why Keccak is not ARX". Still, it is important to compare each Keccak function proposed here against the current Best Practice.
TBD.
TBD.
TBD.
TBD.
Sections here draw heavily on information available on the Keccak site. I thank the Keccak Team in making this information openly available.
SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions National Institute of Standards and Technology SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology &IEEE.802.15.6; Note on Keccak parameters and usage
Radboud University
STMicroelectronics
STMicroelectronics
Team Keccak Home Page
Radboud University
STMicroelectronics
STMicroelectronics
STMicroelectronics
Why Keccak is not ARX The Ketje authenticated encryption scheme
Radboud University
STMicroelectronics
STMicroelectronics
STMicroelectronics
TBD.
In-body sensors, like pacemakers, connected via the Body Area Network (BAN) will be very power conscious. Battery replacement can often require surgery. This will lead to loose interpretation of the HIPAA protection requirements to the detriment of the patient. In-body sensors are an important class of devices that would benefit from the most power and code efficient security components that still meet a strong security claim.
CAN FD (CAN with Flexible Data-Rate) is an extension to the original CAN bus protocol specified in ISO 11898-1. Developed in 2011 and released in 2012. Its larger data payload of 64 bytes can support a encrypting and authenticating protocol, but various in-vehicle constraints can make this challenging. Sensors may be in a very high temperature environment, making even a marginal CPU temperature increase due to heavy computations catastrophic. Cost is always a automotive component constraint and security tends to come in last in the cost competition. Thus any way that the cost of security can be lowered is a major win.
BACnet (ISO 16484-5) is the standard for wired, in-building control systems. Recently IPv6 support (RFC 8163) was added. Some BACnet devices are extremely constrained; 4-bit processors are still common. Though AES on such 4-bit processors is available, it is extremely slow. A smaller security suite would be a real benefit for this environment.
TBD.
TBD. Magnitude faster?
TBD.
TBD.
TBD.
TBD.
--------------AE70AC4F63251546EB0F0C99-- From nobody Tue Sep 26 06:18:56 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3DA132EDA for ; Tue, 26 Sep 2017 06:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=0.001, RCVD_IN_SORBS_SPAM=0.5, 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 Pw8tV4Wiqqvm for ; Tue, 26 Sep 2017 06:18:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 02B5612426E for ; Tue, 26 Sep 2017 06:18:52 -0700 (PDT) Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LwrPM-1dH8A12mPw-016Ryo; Tue, 26 Sep 2017 15:18:37 +0200 To: Robert Moskowitz , Carsten Bormann Cc: "xml2rfc@ietf.org" References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> <50613851-e0f0-e681-740f-e5f70b720a79@htt-consult.com> <1d08d3bf-24aa-5b1b-f705-e60eedb146ef@gmx.de> <6b52d93a-943c-57c0-c803-ef9363ffa6a2@htt-consult.com> From: Julian Reschke Message-ID: <0dd626a6-85d2-aaf4-a225-309f63dfba3f@gmx.de> Date: Tue, 26 Sep 2017 15:18:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <6b52d93a-943c-57c0-c803-ef9363ffa6a2@htt-consult.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:9OeRsV9MnQVz5df8trYSQ6gevd2u+jQ3iNHjdhrqeW2n1O7sQeG asQF3bkUifmwvCM2Pc2KTh4tGZGU3mGkCuQrIjC7i+zWhcnymIjOda6yKU3/7Wu0/0Qa1cP hKRh5mszhmFM8lbN5+uvS4/CQKTT9f44FD2qME/vELkZxCB822k+Shlydbo24WPCNzHc1Zr hYgrhoQfza6rlHohoXNFg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Q0koOxLTlmg=:KhzugKiI4zBVI1KdleRlYv 0d1n4I9OZxN6NDfGfOZ8hoElxfxJznH5hVlpk4xLm1shY+nt4BFfKTIgkAuZ99BI10LbfxDOR 3fkOm6iwziEcem1qEygOiAsmiI7QbZJ1BBEdptGgXR7mbAgkta+1fCS2zSblCEJc/jasqAB3T id9IgRwcXD8bCXpJISCRM+UKxMDEWZvUnHpFTCImY+6MQgb8t5vK1e4XdECgeHb43QqeoDz8v ijtCM3rGly2zXV/0PzDii6YvRg0lLOG76qdiWVgAQfVHU/PqwnKv8caSNe+GEYNN5vfTR2Fe6 oVBsKQVtGGASD1Oj408O7uorjEfF58muKplViFJD0m/lgYqZJVABQih+s3oUrcyQkzbYLzf16 fRwi0h317DyJjKKT54cNGbDY1diRpmpvE9ciqrkk7osETlPcx1HweSBCZNdi6ZPNQe7sobaA4 CSfFgBteU9Z1ZbGKSB7eXgabKjeaoEDjthX0vizPHKyfwYRmGN1zY/hf0J/FQxWkR/sQOYY0T cNCehzPwmIukDZQ8KqqasT9lYXuzXVW8JMafc47c+pkSMuNtjUBvV9/6EG5XRXYui9fglA+Nh I0+AVESFUedoxjFuR17axcIRpRyeBAFJI6vq5pjD7v1VgUDnWkclnlooX6cC/4hMq3i1xfdP3 RKw519Ko20L4/quSH96Hcacr0BU5kqzD0Tj6mo7kCpfr8UtDeOuTT8nb/Q4TVKw7Pas0rJp4P u69Qb5tW7JpPNUMR9UifQ6i94kRzeeD51GXIY4Ri/J8FuvYDfIVxaZm6g0ueJIkMTrVKCcEj2 rWb3AKOT7miWRHW4exCRd1L0a6xp3QP1DzCvgm4ksVzZz6WMoQ= Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 13:18:55 -0000 On 2017-09-26 15:06, Robert Moskowitz wrote: > ... >> 1) I don't see how renaming the XML entity can possible affect the >> output. It's like renaming a variable a variable in a program. >> >> 2) I also don't see why it would cause an error. But if you don't show >> us either the source code or at least the error message, how are we >> supposed to help? > > See the attached.  I have renamed the anchor, IEEE.802.15.6_2012 to > IEEE.802.15.6 in the ENTITY line and followed through in the reference. No, you renamed the entity, not the anchor - that one is defined in the XML that your're including from . > I get the error: > > $ xml2rfc draft-moskowitz-small-crypto-00.xml > Parsing file draft-moskowitz-small-crypto-00.xml > ERROR: Unable to validate the XML document: > draft-moskowitz-small-crypto-00.xml >  draft-moskowitz-small-crypto-00.xml: Line 364: IDREF attribute target > references an unknown ID "IEEE.802.15.6" > ... Yes, because your document does not contain a reference with that anchor. Best regards, Julian From nobody Tue Sep 26 06:29:23 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBE61332F2 for ; Tue, 26 Sep 2017 06:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, 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 8-Dieh_ja4b9 for ; Tue, 26 Sep 2017 06:29:20 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8E31332D7 for ; Tue, 26 Sep 2017 06:29:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 4BA6B61FD8; Tue, 26 Sep 2017 09:29:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0f6uCsMjZSIq; Tue, 26 Sep 2017 09:29:14 -0400 (EDT) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id E091662219; Tue, 26 Sep 2017 09:29:09 -0400 (EDT) To: Julian Reschke , Carsten Bormann Cc: "xml2rfc@ietf.org" References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> <50613851-e0f0-e681-740f-e5f70b720a79@htt-consult.com> <1d08d3bf-24aa-5b1b-f705-e60eedb146ef@gmx.de> <6b52d93a-943c-57c0-c803-ef9363ffa6a2@htt-consult.com> <0dd626a6-85d2-aaf4-a225-309f63dfba3f@gmx.de> From: Robert Moskowitz Message-ID: <6ccc7bf8-c5cb-49ba-586c-b20b834ffa2d@htt-consult.com> Date: Tue, 26 Sep 2017 09:29:06 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <0dd626a6-85d2-aaf4-a225-309f63dfba3f@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 13:29:21 -0000 On 09/26/2017 09:18 AM, Julian Reschke wrote: > On 2017-09-26 15:06, Robert Moskowitz wrote: >> ... >> 1) I don't see how renaming the XML entity can possible affect >> the >>> output. It's like renaming a variable a variable in a program. >>> >>> 2) I also don't see why it would cause an error. But if you don't >>> show us either the source code or at least the error message, how >>> are we supposed to help? >> >> See the attached. I have renamed the anchor, IEEE.802.15.6_2012 to >> IEEE.802.15.6 in the ENTITY line and followed through in the reference. > > No, you renamed the entity, not the anchor - that one is defined in > the XML that your're including from > . So there is, currently, no way to rename the anchor in an included reference xml... OK > >> I get the error: >> >> $ xml2rfc draft-moskowitz-small-crypto-00.xml >> Parsing file draft-moskowitz-small-crypto-00.xml >> ERROR: Unable to validate the XML document: >> draft-moskowitz-small-crypto-00.xml >> draft-moskowitz-small-crypto-00.xml: Line 364: IDREF attribute >> target references an unknown ID "IEEE.802.15.6" >> ... > > Yes, because your document does not contain a reference with that anchor. > > Best regards, Julian > From nobody Tue Sep 26 06:37:26 2017 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEA11332D7 for ; Tue, 26 Sep 2017 06:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 AAieK7OR4WMe for ; Tue, 26 Sep 2017 06:37:21 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9C413307F for ; Tue, 26 Sep 2017 06:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v8QDbBNx018534; Tue, 26 Sep 2017 15:37:11 +0200 (CEST) Received: from [172.20.10.9] (ip-109-45-0-30.web.vodafone.de [109.45.0.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3y1hny4r9JzDLN5; Tue, 26 Sep 2017 15:37:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <6b52d93a-943c-57c0-c803-ef9363ffa6a2@htt-consult.com> Date: Tue, 26 Sep 2017 15:37:09 +0200 Cc: Julian Reschke , "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 528125829.357906-c3f9bbf746c287790495a63c93d2c798 Content-Transfer-Encoding: quoted-printable Message-Id: References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> <50613851-e0f0-e681-740f-e5f70b720a79@htt-consult.com> <1d08d3bf-24aa-5b1b-f705-e60eedb146ef@gmx.de> <6b52d93a-943c-57c0-c803-ef9363ffa6a2@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 13:37:24 -0000 On Sep 26, 2017, at 15:06, Robert Moskowitz wrote: >=20 >=20 >=20 > On 09/26/2017 12:25 AM, Julian Reschke wrote: >> On 2017-09-26 00:06, Robert Moskowitz wrote: >>> ... >>> Since the bibxml url seems to have a strange xml for the nist docs, = I have put some xml reference right into the draft for now. >>> ... >>=20 >> Yes. Why is that a problem? >=20 > If there is an 'official reference', I would rather use that then = craft my own. >=20 > In this case, I don't think the official one is best. It leaves out = the organization, NIST. The date is not the one in the pdf (off by a = month). It lacks the FIPS info (or the SP 800 info). Never mind any = discussion on the anchor name. The complete lack of the publisher name is a bug that I already have = fixed; waiting for Henrik or Tony to install that fix. However, the = =E2=80=9CFIPS PUB 202=E2=80=9D or =E2=80=9CSpecial Publication SP = 800-185=E2=80=9D you want is indeed not in the DOI database; that is a = strong reason to maintain your own entry instead of using an = =E2=80=98official=E2=80=99 one. For bibxml7 DOI references, you do get to choose the anchor (the thing = after the question mark in the URI); for manually included references, = you can always change the anchor you give there. > See the attached. I have renamed the anchor, IEEE.802.15.6_2012 to = IEEE.802.15.6 in the ENTITY line and followed through in the reference. = I get the error: For directly including bibxml6 in XML via entity reference, you = *don=E2=80=99t* get to choose the anchor right now. (You probably have renamed the entity; the name of the entity is = inconsequential; it=E2=80=99s just the equivalent of a filename =E2=80=94 = the anchor name is set in what is the content of the file.) Again, if you paste in the reference, you can change the anchor as = desired. (Same if you use kramdown-rfc to do the pasting in for you.) > $ xml2rfc draft-moskowitz-small-crypto-00.xml > Parsing file draft-moskowitz-small-crypto-00.xml > ERROR: Unable to validate the XML document: = draft-moskowitz-small-crypto-00.xml > draft-moskowitz-small-crypto-00.xml: Line 364: IDREF attribute target = references an unknown ID "IEEE.802.15.6" >=20 > Oh, and I tried it online from http://xml2rfc.tools.ietf.org/ and am = getting the 500 server error. Again. Well, yes, because you don=E2=80=99t have a reference with the anchor = "IEEE.802.15.6=E2=80=9D (changing the entity name for that does nothing, = and the reference in bibxml6 starts " X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D4313334E for ; Tue, 26 Sep 2017 10:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 RHtLr9osaGww for ; Tue, 26 Sep 2017 10:15:20 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E811330AE for ; Tue, 26 Sep 2017 10:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v8QHFEmu015416; Tue, 26 Sep 2017 19:15:14 +0200 (CEST) Received: from [172.27.22.22] (unknown [195.37.142.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3y1ndZ1nWqzDLS2; Tue, 26 Sep 2017 19:15:14 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <6ccc7bf8-c5cb-49ba-586c-b20b834ffa2d@htt-consult.com> Date: Tue, 26 Sep 2017 19:15:12 +0200 Cc: Julian Reschke , "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 528138912.723831-ecf6df69d7364d50cf859facfd7fc69e Content-Transfer-Encoding: quoted-printable Message-Id: <139835CB-1DF3-44E0-B866-247BA26F071A@tzi.org> References: <58e747d9-91fa-5fdb-ba9d-778648eea2dc@htt-consult.com> <7D628FE8-DA33-44D0-A253-BC9120DE564B@tzi.org> <4055a36c-136f-da7f-b89e-034575adeb55@htt-consult.com> <50613851-e0f0-e681-740f-e5f70b720a79@htt-consult.com> <1d08d3bf-24aa-5b1b-f705-e60eedb146ef@gmx.de> <6b52d93a-943c-57c0-c803-ef9363ffa6a2@htt-consult.com> <0dd626a6-85d2-aaf4-a225-309f63dfba3f@gmx.de> <6ccc7bf8-c5cb-49ba-586c-b20b834ffa2d@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [xml2rfc] FIPS and SP800 references X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 17:15:21 -0000 On Sep 26, 2017, at 15:29, Robert Moskowitz wrote: >=20 > So there is, currently, no way to rename the anchor in an included = reference xml... Currently only if that XML is freshly generated for you, as in bibxml7. (Or by automatically rewriting it after generation as kramdown-rfc = does.) Tony has made noises that maybe he can provide the anchor query = parameter for the other bibxmls, too, but as far as I know that hasn=E2=80= =99t been implemented yet. Gr=C3=BC=C3=9Fe, Carsten