From nobody Tue Aug 1 08:12:08 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BA6132195 for ; Tue, 1 Aug 2017 08:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=nWT3ubZa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AD7NpLrW 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 UkSfZO3zGwIj for ; Tue, 1 Aug 2017 08:12:04 -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 EE962129ABE for ; Tue, 1 Aug 2017 08:12:03 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1832B20AD3 for ; Tue, 1 Aug 2017 11:12:03 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Tue, 01 Aug 2017 11:12:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; 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=JsJiHKQtYYNmGfc9FVdFe9khON1SDKChKsKIIBCbJKw=; b=nWT3ubZa kC4SSDi2kg4O1+fLWpkBiJXYRZfNCx+B0uTN0R1bP8ujo/L8Hp4X5HnxSuf61b2h 7S3uISow8ufG5c8a6Lb5joeweB+Ztan0TLFcvsg/RDD6HXm0lT60ty6JhydI2Gnc Qx6xEhoc4u9cH+St5anbqYzmpYwfqjESrItQexSTggr7GezblRQECd+mcrAyf3Qj X6HsaJJi7RlJyrpkDfTTh5QXy65ppM6j8FNJ1FAHm9HX3PosmqizvTLY855Z/0Dm RENb7qglZ4pZjM+OSldzs2nkOgnNJQHmnQpg/W1RpAcLaCDqFb+lnaFILl21q+45 UGvVHQKdgvb1Nw== 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=JsJiHKQtYYNmGfc9FVdFe9khON1SD KChKsKIIBCbJKw=; b=AD7NpLrW7al3+U28rw6SYD4CBJczYMsQ3xBm1sTDiF+Ar Hn99TV5myIq5+RgROwxArLHgvZ7CDkHgdlORZb/cNdm975Gc69qtX+7H1Jl4KNqF 8IrGbPcKumjfV6UoMSEQBfJsxdtcqmS//IINlPE0b4gkdOXfRTadIgZi68v5+U8o VroOuztNUUEDbvU3TOQPOqXUYXlYUKKMu//lOs/k0EiW7M6ZgFyWx+5ytOkc3VL4 13TaJbSBJL+iCYvZHMm11JnJAEfRgoG3yefMutsAUwsEkQ1kGFWDkED0QA18mep5 9/HZDwDL3uGJoStvVMEZRwNuMTIG3pHWJ3OhkAkfA== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E58409E2DE; Tue, 1 Aug 2017 11:12:02 -0400 (EDT) Message-Id: <1501600322.4126537.1059677016.6604FB09@webmail.messagingengine.com> From: Alexey Melnikov To: tools-development@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-917c8476 X-Forwarded-Message-Id: Date: Tue, 01 Aug 2017 16:12:02 +0100 Archived-At: Subject: [TOOLS-DEVELOPMENT] Fwd: Helping set up a DMARC record for the IETF to analyze the impact of ARC X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 15:12:06 -0000 Hi, In order to help with analyzing impact of DMARC on IETF email, Seth from Valimail suggested that ietf.org domain should publish a p=none DMARC record in DNS. He is also saying that Valimail is happy to process reports for ietf.org. My suggestion: 1) I agree that ietf.org should publish DMARC p=none DNS record with reporting email address ("rua" field). 2) I agree that reports submitted to "rua" email address need to be analyzed somehow. They don't contain personally identifiable information, so using Valimail services is Ok. If we can keep a copy of reports, I suggest we do that (e.g. maybe we can create an alias that delivers to an archive mailbox and to a Valimail address.) Comments? Thank you, Alexey ----- Original message ----- From: Seth Blank To: Alexey Melnikov Subject: Helping set up a DMARC record for the IETF to analyze the impact of ARC Date: Wed, 26 Jul 2017 18:06:37 +0200 Hi Alexey, Now that we're looking to upgrade the IETF's mailman instance to ARC sign (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-08) and Gmail is handling ARC signatures properly (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-08#section-13.1), we wanted to offer to provide free analysis for the IETF so that the impact of ARC signing on IETF list delivery could be well understood. As background, ValiMail provides a SaaS portal for organizations to help them get to and maintain DMARC enforcement. We receive DMARC aggregate reports (as defined in https://tools.ietf.org/html/rfc7489#section-7.2 and https://tools.ietf.org/html/rfc7489#appendix-C) and provide a dashboard to visualize and comprehend those reports at scale. We do this for customers of all sizes, from Time Warner and Uber to the Online Trust Alliance (which is now a part of ISOC) and the Anti-Phishing Working Group. Adding a DMARC record at p=none does not impact mail flow, but allows the collection of data in aggregate (which contains no PII) that make it possible to see the impact of changes to one's mail sending environment. The more DMARC data we can collect before the IETF mailman instances are upgraded, the more we can clearly detail the impact of the upgrade (and even of the other list rewriting schemes under consideration for September). If acceptable to the IESG, the sooner we can start collecting DMARC data from the IETF, the better. Since the IETF does not currently have a DMARC record, the simplest approach is to NS delegate _dmarc.ietf.org to ValiMail. If the NS delegation is too high a bar, then simply creating a DMARC record with a rua that contains ValiMail will allow us to do the analysis. Let us know if there's any other information you might need, Seth -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> From nobody Wed Aug 2 07:49:36 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43E2132118 for ; Wed, 2 Aug 2017 07:49:34 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 UxHPblArJ0yG for ; Wed, 2 Aug 2017 07:49:32 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 2BFFC131CA2 for ; Wed, 2 Aug 2017 07:49:32 -0700 (PDT) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id ED59340586 for ; Wed, 2 Aug 2017 08:49:30 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id sEpT1v00c2SSUrH01EpW1P; Wed, 02 Aug 2017 08:49:30 -0600 X-Authority-Analysis: v=2.2 cv=XMVAcUpE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=NEAV23lmAAAA:8 a=wU2YTnxGAAAA:8 a=zQP7CpKOAAAA:8 a=RpNjiQI2AAAA:8 a=QF2H0--CAAAA:8 a=48vgC7mUAAAA:8 a=uieW-cmk32Qpqf0kOpMA:9 a=jpIH26JlB8aEU1M81S3jpgcb7nU=:19 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=vJuR_VyAocOa-HWBgGQO:22 a=qLCvuMKpmWptj0pRGMQE:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=l4oRwo3+x32Zr1KYRkyAKqCgTTZv4EW2JextgyPz5GA=; b=lu6yrYjNyE1Hd4o6MXRd3Xc/1F 3DMZSc/8gtRoyvOc1dKwwPOkjx+4ioZwIcQBcUXDGJFov4idUtppQ7PmPvEgPaUVV6AX1mX75h0s6 Rl4VL2a6NQkPbeoV190Zt6G6x; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:36968 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dcuxj-001xfd-Cu; Wed, 02 Aug 2017 08:49:27 -0600 To: "HANSEN, TONY L" , Henrik Levkowetz , IETF Development References: <15d60f183f8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <15d62326480.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5405DBCD-7F05-4DBB-90A9-50404BDE32E7@att.com> <34a81819-e3d0-0858-1b70-dbdd50a6643c@labn.net> <20232D58-41C6-42B8-BF47-3BA93326C5CF@att.com> <7099168B-4F6D-4F18-AD00-B7180B2D040F@att.com> <81CDB854-2884-494B-A571-4B48EE937290@att.com> <15d999a0c20.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <178DDD56-33EC-4079-BA5C-6A57C53E8314@att.com> From: Lou Berger Message-ID: <0cf7524d-0373-7220-7efb-8246d2a137ff@labn.net> Date: Wed, 2 Aug 2017 10:49:24 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <178DDD56-33EC-4079-BA5C-6A57C53E8314@att.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dcuxj-001xfd-Cu X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:36968 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Fyi example repo using xml2rfc cgi X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 14:49:34 -0000 here's something basic, it just reports failures/success via standard travis email https://github.com/louberger/teas-gmpls-scsi the next step (when I have some time) will to have travis publish back artifacts (.txt and .html) as well as dynamically updated/generated xml to the source repo. Lou PS i'm not sure if this intentional - and looking at the code it seems not - but idnits is not generating an error exit code when it sees errors. On 7/31/2017 1:52 PM, HANSEN, TONY L wrote: > It’ll be interesting seeing what you come up with for CI. I’m particularly interested on having an eye on it towards reuse. > > Tony > > On 7/31/17, 1:03 PM, "Lou Berger" wrote: > > This is great! Thank you. > > Now I'll have to automate checks as part of ci... > > Lou > > > On July 31, 2017 12:09:57 PM "HANSEN, TONY L" wrote: > > > :) > > > > For those copying the URLs below, instead of this: > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_idnits-3Furl-3Dhttps-3A__xml2rfc.tools.ietf.org_cgi-2Dbin_xml2rfc-2Ddev.cgi-3Furl-3Dhttps-3A__raw.githubusercontent.com_ietf-2Drtg-2Darea-2Dyang-2Darch-2Ddt_meta-2Dmodel_master_logical-2Dnetwork-2Delement_draft-2Dietf-2Drtgwg-2Dlne-2Dmodel.xml-26modeAsFormat-3Dascii&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=hOxZsFWl-FxWFgkUsBHVdrMwb5VYk7o662f_Gi0u3cc&s=1VxgfkpC57NdUoZdM488jKmeUmQTJKS9IwCZVtNuzb4&e= > > > > you should use this: > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_idnits-3Furl-3Dhttps-3A__xml2rfc.tools.ietf.org_cgi-2Dbin_xml2rfc.cgi-3Furl-3Dhttps-3A__raw.githubusercontent.com_ietf-2Drtg-2Darea-2Dyang-2Darch-2Ddt_meta-2Dmodel_master_logical-2Dnetwork-2Delement_draft-2Dietf-2Drtgwg-2Dlne-2Dmodel.xml-26modeAsFormat-3Dascii&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=hOxZsFWl-FxWFgkUsBHVdrMwb5VYk7o662f_Gi0u3cc&s=nPdoOL7br7spMxa1G27CadbyOVkxofQBxdaMbp4tI5s&e= > > > > (note the “-dev” was deleted) > > > > Tony > > > > On 7/31/17, 12:02 PM, "Henrik Levkowetz" wrote: > > > > Nice! :-) > > > > Henrik > > > > On 2017-07-31 17:58, HANSEN, TONY L wrote: > > > Thank you, Henrik. > > > > > > I successfully tested the new idnits with the dev version of xml2rfc.cgi. > > So I pushed the necessary changes out to the xml2rfc.cgi as well. > > > > > > So this works now: > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_idnits-3Furl-3Dhttps-3A__xml2rfc.tools.ietf.org_cgi-2Dbin_xml2rfc-2Ddev.cgi-3Furl-3Dhttps-3A__raw.githubusercontent.com_ietf-2Drtg-2Darea-2Dyang-2Darch-2Ddt_meta-2Dmodel_master_logical-2Dnetwork-2Delement_draft-2Dietf-2Drtgwg-2Dlne-2Dmodel.xml-26modeAsFormat-3Dascii&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=hOxZsFWl-FxWFgkUsBHVdrMwb5VYk7o662f_Gi0u3cc&s=1VxgfkpC57NdUoZdM488jKmeUmQTJKS9IwCZVtNuzb4&e= > > > > > > As does this shorter call: > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_idnits-3Furl-3Dhttps-3A__xml2rfc.tools.ietf.org_cgi-2Dbin_github2text_ietf-2Drtg-2Darea-2Dyang-2Darch-2Ddt_meta-2Dmodel_master_logical-2Dnetwork-2Delement_draft-2Dietf-2Drtgwg-2Dlne-2Dmodel.xml&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=hOxZsFWl-FxWFgkUsBHVdrMwb5VYk7o662f_Gi0u3cc&s=d7QFknn1jl4tGSJcp7Wmouzm0-eiQ3N9rzKu1qxKZmE&e= > > > > > > Tony > > > > > > On 7/31/17, 10:42 AM, "Henrik Levkowetz" wrote: > > > > > > Hi Tony, > > > > > > Lou just poked me on this; sorry for loosing track of it. > > > > > > Inline: > > > > > > On 2017-07-21 15:58, HANSEN, TONY L wrote: > > > > On 7/21/17, 3:50 AM, "Lou Berger" wrote: > > > > > > > > Hi Tony, > > > > I did think of one thing that would be good to improve related > > to this: > > > > the ability to pass the results of web xml2rfc to idnits > > > > > > > > for example, the following doesn't work: > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_idnits-3Furl-3Dhttps-3A__xml2rfc.tools.ietf.org_cgi-2Dbin_xml2rfc.cgi-3Furl-3Dhttps-3A__raw.githubusercontent.com_ietf-2Drtg-2Darea-2Dyang-2Darch-2Ddt_meta-2Dmodel_master_logical-2Dnetwork-2Delement_draft-2Dietf-2Drtgwg-2Dlne-2Dmodel.xml-26modeAsFormat-3Dascii&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=hOxZsFWl-FxWFgkUsBHVdrMwb5VYk7o662f_Gi0u3cc&s=nPdoOL7br7spMxa1G27CadbyOVkxofQBxdaMbp4tI5s&e= > > > > > > > > Lou > > > > > > > > > > > > This is an integration problem between web xml2rfc and idnits. > > Idnits returns the following error: > > > > > > > > Unexpected file name > > > > > > > > The uploaded file didn't have the expected .txt extenstion. > > > > > > > > > > > > Henrik, these are the headers that are returned from xml2rfc: > > > > > > > > HTTP/1.1 200 OK > > > > Date: Fri, 21 Jul 2017 13:22:03 GMT > > > > Server: Apache/2.2.22 (Debian) > > > > Vary: Accept-Encoding > > > > Transfer-Encoding: chunked > > > > Content-Type: text/plain; charset=ISO-8859-1 > > > > > > > > I then modified xml2rfc-dev.cgi to generate this additional header: > > > > > > > > Content-Disposition: inline; filename="url.txt" > > > > > > > > But it made no difference. > > > > > > I've added support for a filename being provided with the > > Content-Disposition > > > header field; this should work now. > > > > > > > What in particular is idnits looking for? > > > > > > Simply the extension to which the uploaded file was saved, which was > > taken > > > from the upload form name, or the url directly, earlier. > > > > > > > > > Best regards, > > > > > > Henrik > > > > > > > > > > Tony > > > > > > > > _______________________________________________ > > > > TOOLS-DEVELOPMENT mailing list > > > > TOOLS-DEVELOPMENT@ietf.org > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tools-2Ddevelopment&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Kz8VdgPVctDNSNPJ6PsBaw&m=hOxZsFWl-FxWFgkUsBHVdrMwb5VYk7o662f_Gi0u3cc&s=ulDT5puwELnP0Ha9sKrP3MFwXpqZRSwH8NL519otzek&e= > > > > > > > > > > > > > > > > > > > > > > > From nobody Thu Aug 3 09:54:51 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB077132402 for ; Thu, 3 Aug 2017 09:54:49 -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 j2DP2POF_o-b for ; Thu, 3 Aug 2017 09:54:48 -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 6944D13241C for ; Thu, 3 Aug 2017 09:54:48 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:49431 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ddJOY-0006fT-FQ; Thu, 03 Aug 2017 09:54:48 -0700 To: Alexey Melnikov , tools-development@ietf.org References: <1501600322.4126537.1059677016.6604FB09@webmail.messagingengine.com> From: Henrik Levkowetz Message-ID: <2f50465c-72f7-93d8-1da3-1ca9fe919090@levkowetz.com> Date: Thu, 3 Aug 2017 18:54:32 +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: <1501600322.4126537.1059677016.6604FB09@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wC8VfODXqAAjAwdgPxx2w0thrPNuE88oV" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-development@ietf.org, aamelnikov@fastmail.fm 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 durif.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Fwd: Helping set up a DMARC record for the IETF to analyze the impact of ARC X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 16:54:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wC8VfODXqAAjAwdgPxx2w0thrPNuE88oV Content-Type: multipart/mixed; boundary="csslaVTtWa5qqPu8J5TIT0cJNRPaf7elN"; protected-headers="v1" From: Henrik Levkowetz To: Alexey Melnikov , tools-development@ietf.org Message-ID: <2f50465c-72f7-93d8-1da3-1ca9fe919090@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] Fwd: Helping set up a DMARC record for the IETF to analyze the impact of ARC References: <1501600322.4126537.1059677016.6604FB09@webmail.messagingengine.com> In-Reply-To: <1501600322.4126537.1059677016.6604FB09@webmail.messagingengine.com> --csslaVTtWa5qqPu8J5TIT0cJNRPaf7elN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2017-08-01 17:12, Alexey Melnikov wrote: > Hi, > In order to help with analyzing impact of DMARC on IETF email, Seth fro= m > Valimail suggested that ietf.org domain should publish a p=3Dnone DMARC= > record in DNS. He is also saying that Valimail is happy to process > reports for ietf.org. >=20 > My suggestion: >=20 > 1) I agree that ietf.org should publish DMARC p=3Dnone DNS record with > reporting email address ("rua" field). > 2) I agree that reports submitted to "rua" email address need to be > analyzed somehow. They don't contain personally identifiable > information, so using Valimail services is Ok. If we can keep a copy of= > reports, I suggest we do that (e.g. maybe we can create an alias that > delivers to an archive mailbox and to a Valimail address.) >=20 > Comments? Works for me. Since the ARC milter package for OpenSUSE is available now, we should do this swiftly if we want to gather data before we deploy ARC. Best regards, Henrik >=20 > Thank you, > Alexey >=20 > ----- Original message ----- > From: Seth Blank > To: Alexey Melnikov > Subject: Helping set up a DMARC record for the IETF to analyze the > impact of ARC > Date: Wed, 26 Jul 2017 18:06:37 +0200 >=20 > Hi Alexey, >=20 > Now that we're looking to upgrade the IETF's mailman instance to ARC > sign (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-08) > and Gmail is handling ARC signatures properly > (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-08#section-1= 3.1), > we wanted to offer to provide free analysis for the IETF so that the > impact of ARC signing on IETF list delivery could be well understood. >=20 > As background, ValiMail provides a SaaS portal for organizations to > help them get to and maintain DMARC enforcement. We receive DMARC > aggregate reports (as defined in > https://tools.ietf.org/html/rfc7489#section-7.2 and > https://tools.ietf.org/html/rfc7489#appendix-C) and provide a > dashboard to visualize and comprehend those reports at scale. >=20 > We do this for customers of all sizes, from Time Warner and Uber to > the Online Trust Alliance (which is now a part of ISOC) and the > Anti-Phishing Working Group. >=20 > Adding a DMARC record at p=3Dnone does not impact mail flow, but allows= > the collection of data in aggregate (which contains no PII) that make > it possible to see the impact of changes to one's mail sending > environment. >=20 > The more DMARC data we can collect before the IETF mailman instances > are upgraded, the more we can clearly detail the impact of the upgrade > (and even of the other list rewriting schemes under consideration for > September). If acceptable to the IESG, the sooner we can start > collecting DMARC data from the IETF, the better. >=20 > Since the IETF does not currently have a DMARC record, the simplest > approach is to NS delegate _dmarc.ietf.org to ValiMail. If the NS > delegation is too high a bar, then simply creating a DMARC record with > a rua that contains ValiMail will allow us to do the analysis. >=20 > Let us know if there's any other information you might need, >=20 > Seth >=20 --csslaVTtWa5qqPu8J5TIT0cJNRPaf7elN-- --wC8VfODXqAAjAwdgPxx2w0thrPNuE88oV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZg1VOAAoJEE6bV0uPuxcapy8QAIv52zrAuqsDBClNOwTzA5rJ BZaOxxMraM66G+kYyqKiMgyH1Cnfpb5W4bIrfFXWsd06ZczQGPLcrPe5uZaN86zS NV6Dz83As57QhYcl2IU48gH3/wS/T5CSuAnT50SCHc13gZ5XXs0mWo1Bdhu3KHM7 8mKBPPJxDDJ3EmA0dxe74PbcI65oIEjnzOoxGAXqNVFS59isDFygMXqiglppgZhe SOdQjKrz0XffamDBWx4HhL42bpCnN5ENszSxwr2f8MWPC5Ve/Jn2sDA3xjSr72IU ZwMKS5W3s8Cp67dAERgGaiOENxrBWNI/Ej7riu70pB/pOUZjrUvqYjxjMjCrWJY/ hT5nDRfAOu58wiNOPQ/98INcpwlLeckKZn7zJX6Z9kB5pua+L/wiLySSF5aWNgMg Jgrb+CcrMx84Njr2pofrGct70Vw9qWf4u5UaDQkgA6CI+y2vVtz1T10e06FgLKOy OIgISycQsMUFhXGQVR6dK6fJ0jpsDtHNf+XGLXxyItz3F0iBBMoFoO6cjvMbYdFc lZLkZ4xsgdPI6gQfVw6W8fO/S9OyV/9lVgQ/VYIBSNMdVXiMa1aLUKe9hjpppWs8 h4yXTRRT1qriNhkwPlIcs02NQi571QqUbhaRgj1SF3JLLiqUWgHKsuwFsdq1Ud5D 10mzo97etN2wqLGh3kZM =TQhu -----END PGP SIGNATURE----- --wC8VfODXqAAjAwdgPxx2w0thrPNuE88oV-- From nobody Thu Aug 3 09:56:42 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7271A131FF2 for ; Thu, 3 Aug 2017 09:56:39 -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 sJysJfq9cbyr for ; Thu, 3 Aug 2017 09:56:37 -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 2C1E4131C58 for ; Thu, 3 Aug 2017 09:56:37 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:49438 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ddJQJ-0003DN-Iz; Thu, 03 Aug 2017 09:56:36 -0700 To: Lou Berger , "HANSEN, TONY L" , IETF Development References: <15d60f183f8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <15d62326480.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5405DBCD-7F05-4DBB-90A9-50404BDE32E7@att.com> <34a81819-e3d0-0858-1b70-dbdd50a6643c@labn.net> <20232D58-41C6-42B8-BF47-3BA93326C5CF@att.com> <7099168B-4F6D-4F18-AD00-B7180B2D040F@att.com> <81CDB854-2884-494B-A571-4B48EE937290@att.com> <15d999a0c20.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <178DDD56-33EC-4079-BA5C-6A57C53E8314@att.com> <0cf7524d-0373-7220-7efb-8246d2a137ff@labn.net> From: Henrik Levkowetz Message-ID: <060a2e2c-2f5e-2a69-ea81-c7411c10b5b2@levkowetz.com> Date: Thu, 3 Aug 2017 18:56:27 +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: <0cf7524d-0373-7220-7efb-8246d2a137ff@labn.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wawadnEJIS2tUlHkHQ5PbrlaltRQ1wLRj" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-development@ietf.org, tony@att.com, lberger@labn.net 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 durif.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Fyi example repo using xml2rfc cgi X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 16:56:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wawadnEJIS2tUlHkHQ5PbrlaltRQ1wLRj Content-Type: multipart/mixed; boundary="2572IiG0xGfFr2qC6BncodKR5ORjUkCkv"; protected-headers="v1" From: Henrik Levkowetz To: Lou Berger , "HANSEN, TONY L" , IETF Development Message-ID: <060a2e2c-2f5e-2a69-ea81-c7411c10b5b2@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] Fyi example repo using xml2rfc cgi References: <15d60f183f8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <15d62326480.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5405DBCD-7F05-4DBB-90A9-50404BDE32E7@att.com> <34a81819-e3d0-0858-1b70-dbdd50a6643c@labn.net> <20232D58-41C6-42B8-BF47-3BA93326C5CF@att.com> <7099168B-4F6D-4F18-AD00-B7180B2D040F@att.com> <81CDB854-2884-494B-A571-4B48EE937290@att.com> <15d999a0c20.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <178DDD56-33EC-4079-BA5C-6A57C53E8314@att.com> <0cf7524d-0373-7220-7efb-8246d2a137ff@labn.net> In-Reply-To: <0cf7524d-0373-7220-7efb-8246d2a137ff@labn.net> --2572IiG0xGfFr2qC6BncodKR5ORjUkCkv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Lou, On 2017-08-02 16:49, Lou Berger wrote: > here's something basic, it just reports failures/success via standard > travis email >=20 > https://github.com/louberger/teas-gmpls-scsi >=20 > the next step (when I have some time) will to have travis publish back > artifacts (.txt and .html) as well as dynamically updated/generated xml= > to the source repo. >=20 > Lou >=20 > PS i'm not sure if this intentional - and looking at the code it seems > not - but idnits is not generating an error exit code when it sees erro= rs.=20 Is it the command-line idnits or the web service which you'd like to retu= rn errors? Henrik >=20 > On 7/31/2017 1:52 PM, HANSEN, TONY L wrote: >> It=E2=80=99ll be interesting seeing what you come up with for CI. I=E2= =80=99m particularly interested on having an eye on it towards reuse. >> >> Tony >> >> On 7/31/17, 1:03 PM, "Lou Berger" wrote: >> >> This is great! Thank you. >> =20 >> Now I'll have to automate checks as part of ci... >> =20 >> Lou >> =20 >> =20 >> On July 31, 2017 12:09:57 PM "HANSEN, TONY L" wrote= : >> =20 >> > :) >> > >> > For those copying the URLs below, instead of this: >> > >> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.iet= f.org_idnits-3Furl-3Dhttps-3A__xml2rfc.tools.ietf.org_cgi-2Dbin_xml2rfc-2= Ddev.cgi-3Furl-3Dhttps-3A__raw.githubusercontent.com_ietf-2Drtg-2Darea-2D= yang-2Darch-2Ddt_meta-2Dmodel_master_logical-2Dnetwork-2Delement_draft-2D= ietf-2Drtgwg-2Dlne-2Dmodel.xml-26modeAsFormat-3Dascii&d=3DDwIDaQ&c=3DLFYZ= -o9_HUMeMTSQicvjIg&r=3DKz8VdgPVctDNSNPJ6PsBaw&m=3DhOxZsFWl-FxWFgkUsBHVdrM= wb5VYk7o662f_Gi0u3cc&s=3D1VxgfkpC57NdUoZdM488jKmeUmQTJKS9IwCZVtNuzb4&e=3D= =20 >> > >> > you should use this: >> > >> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.iet= f.org_idnits-3Furl-3Dhttps-3A__xml2rfc.tools.ietf.org_cgi-2Dbin_xml2rfc.c= gi-3Furl-3Dhttps-3A__raw.githubusercontent.com_ietf-2Drtg-2Darea-2Dyang-2= Darch-2Ddt_meta-2Dmodel_master_logical-2Dnetwork-2Delement_draft-2Dietf-2= Drtgwg-2Dlne-2Dmodel.xml-26modeAsFormat-3Dascii&d=3DDwIDaQ&c=3DLFYZ-o9_HU= MeMTSQicvjIg&r=3DKz8VdgPVctDNSNPJ6PsBaw&m=3DhOxZsFWl-FxWFgkUsBHVdrMwb5VYk= 7o662f_Gi0u3cc&s=3DnPdoOL7br7spMxa1G27CadbyOVkxofQBxdaMbp4tI5s&e=3D=20 >> > >> > (note the =E2=80=9C-dev=E2=80=9D was deleted) >> > >> > Tony >> > >> > On 7/31/17, 12:02 PM, "Henrik Levkowetz" = wrote: >> > >> > Nice! :-) >> > >> > Henrik >> > >> > On 2017-07-31 17:58, HANSEN, TONY L wrote: >> > > Thank you, Henrik. >> > > >> > > I successfully tested the new idnits with the dev version = of xml2rfc.cgi.=20 >> > So I pushed the necessary changes out to the xml2rfc.cgi as = well. >> > > >> > > So this works now: >> > > >> > >=20 >> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools= =2Eietf.org_idnits-3Furl-3Dhttps-3A__xml2rfc.tools.ietf.org_cgi-2Dbin_xml= 2rfc-2Ddev.cgi-3Furl-3Dhttps-3A__raw.githubusercontent.com_ietf-2Drtg-2Da= rea-2Dyang-2Darch-2Ddt_meta-2Dmodel_master_logical-2Dnetwork-2Delement_dr= aft-2Dietf-2Drtgwg-2Dlne-2Dmodel.xml-26modeAsFormat-3Dascii&d=3DDwIDaQ&c=3D= LFYZ-o9_HUMeMTSQicvjIg&r=3DKz8VdgPVctDNSNPJ6PsBaw&m=3DhOxZsFWl-FxWFgkUsBH= VdrMwb5VYk7o662f_Gi0u3cc&s=3D1VxgfkpC57NdUoZdM488jKmeUmQTJKS9IwCZVtNuzb4&= e=3D=20 >> > > >> > > As does this shorter call: >> > > >> > >=20 >> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools= =2Eietf.org_idnits-3Furl-3Dhttps-3A__xml2rfc.tools.ietf.org_cgi-2Dbin_git= hub2text_ietf-2Drtg-2Darea-2Dyang-2Darch-2Ddt_meta-2Dmodel_master_logical= -2Dnetwork-2Delement_draft-2Dietf-2Drtgwg-2Dlne-2Dmodel.xml&d=3DDwIDaQ&c=3D= LFYZ-o9_HUMeMTSQicvjIg&r=3DKz8VdgPVctDNSNPJ6PsBaw&m=3DhOxZsFWl-FxWFgkUsBH= VdrMwb5VYk7o662f_Gi0u3cc&s=3Dd7QFknn1jl4tGSJcp7Wmouzm0-eiQ3N9rzKu1qxKZmE&= e=3D=20 >> > > >> > > Tony >> > > >> > > On 7/31/17, 10:42 AM, "Henrik Levkowetz" wrote: >> > > >> > > Hi Tony, >> > > >> > > Lou just poked me on this; sorry for loosing track of = it. >> > > >> > > Inline: >> > > >> > > On 2017-07-21 15:58, HANSEN, TONY L wrote: >> > > > On 7/21/17, 3:50 AM, "Lou Berger" = wrote: >> > > > >> > > > Hi Tony, >> > > > I did think of one thing that would be good to = improve related=20 >> > to this: >> > > > the ability to pass the results of web xml2rfc t= o idnits >> > > > >> > > > for example, the following doesn't work: >> > > > >> > > > =20 >> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools= =2Eietf.org_idnits-3Furl-3Dhttps-3A__xml2rfc.tools.ietf.org_cgi-2Dbin_xml= 2rfc.cgi-3Furl-3Dhttps-3A__raw.githubusercontent.com_ietf-2Drtg-2Darea-2D= yang-2Darch-2Ddt_meta-2Dmodel_master_logical-2Dnetwork-2Delement_draft-2D= ietf-2Drtgwg-2Dlne-2Dmodel.xml-26modeAsFormat-3Dascii&d=3DDwIDaQ&c=3DLFYZ= -o9_HUMeMTSQicvjIg&r=3DKz8VdgPVctDNSNPJ6PsBaw&m=3DhOxZsFWl-FxWFgkUsBHVdrM= wb5VYk7o662f_Gi0u3cc&s=3DnPdoOL7br7spMxa1G27CadbyOVkxofQBxdaMbp4tI5s&e=3D= =20 >> > > > >> > > > Lou >> > > > >> > > > >> > > > This is an integration problem between web xml2rfc a= nd idnits.=20 >> > Idnits returns the following error: >> > > > >> > > > Unexpected file name >> > > > >> > > > The uploaded file didn't have the expected .t= xt extenstion. >> > > > >> > > > >> > > > Henrik, these are the headers that are returned from= xml2rfc: >> > > > >> > > > HTTP/1.1 200 OK >> > > > Date: Fri, 21 Jul 2017 13:22:03 GMT >> > > > Server: Apache/2.2.22 (Debian) >> > > > Vary: Accept-Encoding >> > > > Transfer-Encoding: chunked >> > > > Content-Type: text/plain; charset=3DISO-8859-1 >> > > > >> > > > I then modified xml2rfc-dev.cgi to generate this add= itional header: >> > > > >> > > > Content-Disposition: inline; filename=3D"url.txt" >> > > > >> > > > But it made no difference. >> > > >> > > I've added support for a filename being provided with = the=20 >> > Content-Disposition >> > > header field; this should work now. >> > > >> > > > What in particular is idnits looking for? >> > > >> > > Simply the extension to which the uploaded file was sa= ved, which was=20 >> > taken >> > > from the upload form name, or the url directly, earlie= r. >> > > >> > > >> > > Best regards, >> > > >> > > Henrik >> > > >> > > >> > > > Tony >> > > > >> > > > _______________________________________________ >> > > > TOOLS-DEVELOPMENT mailing list >> > > > TOOLS-DEVELOPMENT@ietf.org >> > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3= A__www.ietf.org_mailman_listinfo_tools-2Ddevelopment&d=3DDwIDaQ&c=3DLFYZ-= o9_HUMeMTSQicvjIg&r=3DKz8VdgPVctDNSNPJ6PsBaw&m=3DhOxZsFWl-FxWFgkUsBHVdrMw= b5VYk7o662f_Gi0u3cc&s=3DulDT5puwELnP0Ha9sKrP3MFwXpqZRSwH8NL519otzek&e=3D = >> > > > >> > > >> > > >> > > >> > >> > >> > >> =20 >> =20 >> =20 >> >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 --2572IiG0xGfFr2qC6BncodKR5ORjUkCkv-- --wawadnEJIS2tUlHkHQ5PbrlaltRQ1wLRj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZg1W8AAoJEE6bV0uPuxca/bEQAJaiOgoWfbWNcy7J6evVZaIt o4SQoHv+eCVG1bvWQisB5iFtNd3uyeKzDt0ontzzjOKdX1R8OeIb4nMNMpkL+zMY FUnbHeAAKDDYmwQF4rb4ek8ju+eCoWu097i8kkJTLAULG7+Zixj63tUOUSXXHCOc Fci+RQqATHxJPBTt2O8q+I/9eZPegJ6GofwA1ufBi1uyYKqtWO/4JcT2jOcy5vAx AB+4ReBUj4EVU86ScYGxRT5YMlGPP0gWPBnIz86j3yl511pT35qDyymEMvv2TD66 eUjD8KpWyEd2WPkjGw7T1bJ9wVYoD9/xrp16y8OCzXj+8m/dsZg2wBiJaHavynyP JzWvtbXpvgbMc/gVd0KCwYYSdtFHZy2shdH5O+RpNbrYZ5iWV3dAKGNdCp2RVCqO 1/XhiDJCs+itdrnOhOdhmlRbRvNf+d1U0nP0vx5E/dpf1+CTOgtKu2x4LaC0HBRV gSPHJU2ttyCba1E5JmJHTKLXE82lRmILKu9fx9UJv1EL6DMSAX+juuMElOiwHCHt I3xXnOeluPHazSlqiw0JXkWhmgodE7UuU+ZTgv8PhIPRb/m6NEVA3LErx7hQtf10 QKNL8/3NHNvrj63fNhegRbxG0zucf2N+UmWAmysH73BZxM8LhCb2jlhx0B7unKT4 M8/K/PMIsJ8wmm+M0GLX =8vas -----END PGP SIGNATURE----- --wawadnEJIS2tUlHkHQ5PbrlaltRQ1wLRj-- From nobody Thu Aug 3 10:57:57 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E503131FCA for ; Thu, 3 Aug 2017 10:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 ct1pkyvRu6yO for ; Thu, 3 Aug 2017 10:57:55 -0700 (PDT) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02171132035 for ; Thu, 3 Aug 2017 10:57:51 -0700 (PDT) Received: from [::1] (port=35207 helo=[127.0.0.1]) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1ddKNa-0004IK-Vs; Thu, 03 Aug 2017 21:57:51 +0400 From: Lou Berger To: Henrik Levkowetz , "HANSEN, TONY L" , IETF Development Date: Thu, 03 Aug 2017 13:57:48 -0400 Message-ID: <15da93ede80.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <060a2e2c-2f5e-2a69-ea81-c7411c10b5b2@levkowetz.com> References: <15d60f183f8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <15d62326480.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5405DBCD-7F05-4DBB-90A9-50404BDE32E7@att.com> <34a81819-e3d0-0858-1b70-dbdd50a6643c@labn.net> <20232D58-41C6-42B8-BF47-3BA93326C5CF@att.com> <7099168B-4F6D-4F18-AD00-B7180B2D040F@att.com> <81CDB854-2884-494B-A571-4B48EE937290@att.com> <15d999a0c20.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <178DDD56-33EC-4079-BA5C-6A57C53E8314@att.com> <0cf7524d-0373-7220-7efb-8246d2a137ff@labn.net> <060a2e2c-2f5e-2a69-ea81-c7411c10b5b2@levkowetz.com> User-Agent: AquaMail/1.10.0-403 (build: 101000001) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Authenticated-Sender: newdragon.webhostserver.biz: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Fyi example repo using xml2rfc cgi X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 17:57:56 -0000 Hi Henrick, On August 3, 2017 12:57:06 PM Henrik Levkowetz wrote: ... >> >> PS i'm not sure if this intentional - and looking at the code it seems >> not - but idnits is not generating an error exit code when it sees errors. > > Is it the command-line idnits or the web service Command line. > which you'd like to return > errors? > Looking at the script it looks like the exit code should equal the number of reported errors, but this isn't the case. I actually don't need any changes for my use, grep -q gives me the exit code I need for testing, it just looked liked the exit code isn't as coded so was just letting you know. Cheers, Lou > Henrik > From nobody Thu Aug 3 11:10:34 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2802213188F for ; Thu, 3 Aug 2017 11:10:33 -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 lOC1BiobnbGF for ; Thu, 3 Aug 2017 11:10:32 -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 6BC4B132011 for ; Thu, 3 Aug 2017 11:10:29 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:49917 helo=[192.168.1.120]) by durif.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ddKZo-0006zQ-Qg; Thu, 03 Aug 2017 11:10:29 -0700 To: Lou Berger , "HANSEN, TONY L" , IETF Development References: <15d60f183f8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <15d62326480.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5405DBCD-7F05-4DBB-90A9-50404BDE32E7@att.com> <34a81819-e3d0-0858-1b70-dbdd50a6643c@labn.net> <20232D58-41C6-42B8-BF47-3BA93326C5CF@att.com> <7099168B-4F6D-4F18-AD00-B7180B2D040F@att.com> <81CDB854-2884-494B-A571-4B48EE937290@att.com> <15d999a0c20.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <178DDD56-33EC-4079-BA5C-6A57C53E8314@att.com> <0cf7524d-0373-7220-7efb-8246d2a137ff@labn.net> <060a2e2c-2f5e-2a69-ea81-c7411c10b5b2@levkowetz.com> <15da93ede80.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Henrik Levkowetz Message-ID: <28e3627d-639e-9483-6eba-400d16b104b1@levkowetz.com> Date: Thu, 3 Aug 2017 20:10:20 +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: <15da93ede80.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nQWPum7dj26dT0OAjxb9aStDiLC1v5vIa" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-development@ietf.org, tony@att.com, lberger@labn.net 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 durif.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Fyi example repo using xml2rfc cgi X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 18:10:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nQWPum7dj26dT0OAjxb9aStDiLC1v5vIa Content-Type: multipart/mixed; boundary="iK4lhpiECOLtCFvF02uTQ5GNiAT0kPuOt"; protected-headers="v1" From: Henrik Levkowetz To: Lou Berger , "HANSEN, TONY L" , IETF Development Message-ID: <28e3627d-639e-9483-6eba-400d16b104b1@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] Fyi example repo using xml2rfc cgi References: <15d60f183f8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <15d62326480.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5405DBCD-7F05-4DBB-90A9-50404BDE32E7@att.com> <34a81819-e3d0-0858-1b70-dbdd50a6643c@labn.net> <20232D58-41C6-42B8-BF47-3BA93326C5CF@att.com> <7099168B-4F6D-4F18-AD00-B7180B2D040F@att.com> <81CDB854-2884-494B-A571-4B48EE937290@att.com> <15d999a0c20.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <178DDD56-33EC-4079-BA5C-6A57C53E8314@att.com> <0cf7524d-0373-7220-7efb-8246d2a137ff@labn.net> <060a2e2c-2f5e-2a69-ea81-c7411c10b5b2@levkowetz.com> <15da93ede80.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <15da93ede80.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> --iK4lhpiECOLtCFvF02uTQ5GNiAT0kPuOt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Lou, On 2017-08-03 19:57, Lou Berger wrote: > Hi Henrick, >=20 > On August 3, 2017 12:57:06 PM Henrik Levkowetz w= rote: >=20 > ... >=20 >>> >>> PS i'm not sure if this intentional - and looking at the code it seem= s >>> not - but idnits is not generating an error exit code when it sees er= rors. >> >> Is it the command-line idnits or the web service >=20 > Command line. Ok. >> which you'd like to return >> errors? >> >=20 > Looking at the script it looks like the exit code should equal the numb= er=20 > of reported errors, but this isn't the case. >=20 > I actually don't need any changes for my use, grep -q gives me the exit= =20 > code I need for testing, it just looked liked the exit code isn't as co= ded=20 > so was just letting you know. Ack, understood. I'll have a look. I have a feeling there's a reason for the missing error code, could be that awk isn't set up to let you specify an error value. Henrik --iK4lhpiECOLtCFvF02uTQ5GNiAT0kPuOt-- --nQWPum7dj26dT0OAjxb9aStDiLC1v5vIa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZg2cNAAoJEE6bV0uPuxcarzoP/R9Rtfy+V8LXH8Vhc5D68hXZ jyzV9PqSFNN8KttVopbrvNIePtq1O7vCzG1IW+8w/GK8Ya3zgKBM7+xbwu+2spT3 b1GNDYabEQqQzK3MxHeaEXI/szK/t5eay1pYIjvoLr+QBELsvieupkx6CMOG9/VY p6dkhJradLUbshMxyQYXSH+ZCxke1YXAvKiXC+u9v18NJ1qvvJY1ZaCl+Il1Ty6g tdckS+p+BGreHSMP2zkYsZ41s2s1YoaRtUkHPdMOH+PPo5Lefhzhw2MWltaENHfj SVsGLU8t1Rnbr8Em7oLtpA89RbEeZ/GPDJ4LSx/9eKPduZmlZyu4ZqB90cRc6sPR hlyYcPTmEogs0ablHVCgNit0RXi+3SKKXgItxqw5Xa9k3XCdjt2J3N1oFFdl+Gho hlV66hkeg7v9nCYEJh32I4Xkp02vGKlgQowXrBhugl556AhzfWSmFsm4aXskGCUQ UY6yr6pj7oOdglYeTrRNQDQaXXeCdaups8ZA2hh+JO4YrfS8+k09Tu2Ab2+SaP/T S0YpZLLflYWLiDN/0IR/KBugHcj58Ot9JwLQ1b0Ax7GLWrJlPxJpIsyFr8QXZq/4 2N6k9+pG8JXaITwWOdK0G3tmt1Bw0QATTCrMVLi0eWTbwcVO5kUkVGvdJOkiyk5T Qm3BKqK3EQupGAKKlRwS =g/yR -----END PGP SIGNATURE----- --nQWPum7dj26dT0OAjxb9aStDiLC1v5vIa-- From nobody Thu Aug 3 12:06:40 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E693D120713 for ; Thu, 3 Aug 2017 12:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 p4uXdxwb46C9 for ; Thu, 3 Aug 2017 12:06:39 -0700 (PDT) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0332D126C22 for ; Thu, 3 Aug 2017 12:06:38 -0700 (PDT) Received: from [::1] (port=56650) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1ddLSA-0004e9-9P; Thu, 03 Aug 2017 23:06:38 +0400 To: Henrik Levkowetz , "HANSEN, TONY L" , IETF Development References: <15d60f183f8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <15d62326480.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <5405DBCD-7F05-4DBB-90A9-50404BDE32E7@att.com> <34a81819-e3d0-0858-1b70-dbdd50a6643c@labn.net> <20232D58-41C6-42B8-BF47-3BA93326C5CF@att.com> <7099168B-4F6D-4F18-AD00-B7180B2D040F@att.com> <81CDB854-2884-494B-A571-4B48EE937290@att.com> <15d999a0c20.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <178DDD56-33EC-4079-BA5C-6A57C53E8314@att.com> <0cf7524d-0373-7220-7efb-8246d2a137ff@labn.net> <060a2e2c-2f5e-2a69-ea81-c7411c10b5b2@levkowetz.com> <15da93ede80.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <28e3627d-639e-9483-6eba-400d16b104b1@levkowetz.com> From: Lou Berger Message-ID: Date: Thu, 3 Aug 2017 15:06:34 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <28e3627d-639e-9483-6eba-400d16b104b1@levkowetz.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Authenticated-Sender: newdragon.webhostserver.biz: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Fyi example repo using xml2rfc cgi X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 19:06:40 -0000 Hi Henrik, On 8/3/2017 2:10 PM, Henrik Levkowetz wrote: > Hi Lou, > > On 2017-08-03 19:57, Lou Berger wrote: >> Hi Henrick, >> >> On August 3, 2017 12:57:06 PM Henrik Levkowetz wrote: >> >> ... >> >>>> PS i'm not sure if this intentional - and looking at the code it seems >>>> not - but idnits is not generating an error exit code when it sees errors. >>> Is it the command-line idnits or the web service >> Command line. > Ok. > >>> which you'd like to return >>> errors? >>> >> Looking at the script it looks like the exit code should equal the number >> of reported errors, but this isn't the case. >> >> I actually don't need any changes for my use, grep -q gives me the exit >> code I need for testing, it just looked liked the exit code isn't as coded >> so was just letting you know. > Ack, understood. I'll have a look. I have a feeling there's a reason > for the missing error code, could be that awk isn't set up to let you > specify an error value. Okay, you made me look;-) Awk's exit code is the number of errors and this is returned by the checknits function, but the calling code isn't using the return value. I don't know if this is the design intent or not. It would be trivial to modify the code to have the exit code be the number of errors, if anyone needed/wanted this. Lou PS enjoy your vacation and we can pick this up on your return if you want to discuss further... > > Henrik > From nobody Fri Aug 4 14:10:39 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3719C1252BA for ; Fri, 4 Aug 2017 14:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=1.623, URIBL_SBL_A=0.1] 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 pcQyl387gKO6 for ; Fri, 4 Aug 2017 14:08:43 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B73126C0F for ; Fri, 4 Aug 2017 14:08:39 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 032E31C3F53 for ; Fri, 4 Aug 2017 14:08:30 -0700 (PDT) Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) by c8a.amsl.com (Postfix) with ESMTPSA id 99C7A1C3F55 for ; Fri, 4 Aug 2017 14:08:29 -0700 (PDT) Received: by mail-lf0-f54.google.com with SMTP id t128so11639214lff.2 for ; Fri, 04 Aug 2017 14:08:39 -0700 (PDT) X-Gm-Message-State: AHYfb5gDEifdiSuPZ4HSrTesFBdpKNFhEVWYoffC8clFRROLyrxeUh+D xDQSsY43vAiWP9KAYCKVSzdNmLLtNw== X-Received: by 10.25.221.77 with SMTP id u74mr1263808lfg.29.1501880917403; Fri, 04 Aug 2017 14:08:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.0.195 with HTTP; Fri, 4 Aug 2017 14:08:16 -0700 (PDT) From: Glen Date: Fri, 4 Aug 2017 14:08:16 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Glen Cc: iesg@ietf.org, wgchairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Fri, 04 Aug 2017 14:10:38 -0700 Subject: [TOOLS-DEVELOPMENT] Large Spam Attack in progress X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 21:08:45 -0000 All - A rather widespread spam attack is currently underway, and the IETF server is amongst its targets. There are over 26,000 hosts involved in this "distribution" of emails, which of course suggests a botnet. The large distribution of addresses implies a large number of subnets, making targeted blocking impossible. On a positive note, the IETF will at least be pleased to know that more than 10,000 of those hosts are using IPV6. Hooray for our side. At any rate, despite the distributed sources, it's all SMTP. And all of the spam appears to be coming "From" random numeric user IDs at one of four domains: qq.com 126.com 163.com sina.com So, naturally, I've blocked incoming email from those four domains. We're still seeing at least 5-6 incoming connections per second from various hosts, but the mail processing appears to have been stopped with the block. *sigh* Just wanted to let you know about this, in case you see junk in your list moderation queues. We'll continue to watch, as always, and adapt as needed. Just now I got two from "sohu.com" and "179.com". On to the block list they go. As always, any questions, let me know. Glen -- Glen Barney IT Director AMS (IETF Secretariat) From nobody Mon Aug 7 10:26:30 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE0C1324F5; Mon, 7 Aug 2017 10:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 9SbDRTgxa1wx; Mon, 7 Aug 2017 10:26:28 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0A2131CFE; Mon, 7 Aug 2017 10:26:27 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id F22671C166F; Mon, 7 Aug 2017 10:26:13 -0700 (PDT) Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) by c8a.amsl.com (Postfix) with ESMTPSA id 918851C1B1A; Mon, 7 Aug 2017 10:26:13 -0700 (PDT) Received: by mail-lf0-f51.google.com with SMTP id t128so4801198lff.2; Mon, 07 Aug 2017 10:26:27 -0700 (PDT) X-Gm-Message-State: AHYfb5hMO4w7xBe5W/0SeXpte5i6UcTgPSJv3Xpvd/BoGW5nOg/UdzOH 7oqUgNZ7tC6bXdD6YTCGe7dMSvkj1w== X-Received: by 10.25.232.13 with SMTP id f13mr423132lfh.190.1502126785742; Mon, 07 Aug 2017 10:26:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.0.195 with HTTP; Mon, 7 Aug 2017 10:26:05 -0700 (PDT) In-Reply-To: <21295.1502117527@obiwan.sandelman.ca> References: <26908.1502056909@obiwan.sandelman.ca> <21295.1502117527@obiwan.sandelman.ca> From: Glen Date: Mon, 7 Aug 2017 10:26:05 -0700 X-Gmail-Original-Message-ID: Message-ID: To: wgchairs@ietf.org Cc: tools-development@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Large Spam Attack in progress X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 17:26:29 -0000 On Mon, Aug 7, 2017 at 7:11 AM, Derek Atkins wrote: > That makes it easy. Just do what Google does, and require a valid PTR > record for all incoming IPv6 email. I would think that any valid email > sender would have a valid PTR record, whereas BotNets most likely would > not. On Mon, Aug 7, 2017 at 7:52 AM, Michael Richardson wrote: > Google email servers reject v6 connections without reverse maps. > It seems like a reasonable "must be at least this tall" check, although many > might disagree. We are already configured to do something like that by default, and I see lots of this kind of thing in the log: 2017-08-06T15:01:19.285596-07:00 ietfa postfix/smtpd[17799]: NOQUEUE: reject: RCPT from unknown[49.88.153.38]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [49.88.153.38]; from= to= proto=ESMTP helo= However, I notice that this seems not to be hitting *any* IPV6 addresses. I wonder if there's something in the Postfix config that needs a tweak. I shall investigate and report. > > "Chinanet Backbone"... > sigh. Totally agreed. ip*tables -I INPUT 1 -s CHINA -j DROP The temptation.... Glen From nobody Mon Aug 7 11:45:12 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D664F13253F; Mon, 7 Aug 2017 11:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 i0cxJCyX_jd3; Mon, 7 Aug 2017 11:45:03 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232AE132457; Mon, 7 Aug 2017 11:45:03 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 1503A1C1D0E; Mon, 7 Aug 2017 11:44:49 -0700 (PDT) Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) by c8a.amsl.com (Postfix) with ESMTPSA id A49E81C1B14; Mon, 7 Aug 2017 11:44:48 -0700 (PDT) Received: by mail-lf0-f44.google.com with SMTP id o85so5551432lff.3; Mon, 07 Aug 2017 11:45:02 -0700 (PDT) X-Gm-Message-State: AHYfb5g4Z3UixDxoOajKjmwykY7EHMweI4ymSPzN/hVW81KRuL5+GmAL jhL1ZMQ5ZelWEiUwCG5xvpssBf7fIQ== X-Received: by 10.25.160.84 with SMTP id j81mr489208lfe.168.1502131500880; Mon, 07 Aug 2017 11:45:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.0.195 with HTTP; Mon, 7 Aug 2017 11:44:40 -0700 (PDT) In-Reply-To: References: <26908.1502056909@obiwan.sandelman.ca> <21295.1502117527@obiwan.sandelman.ca> From: Glen Date: Mon, 7 Aug 2017 11:44:40 -0700 X-Gmail-Original-Message-ID: Message-ID: To: wgchairs@ietf.org Cc: tools-development@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Large Spam Attack in progress X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 18:45:05 -0000 On Mon, Aug 7, 2017 at 10:26 AM, Glen wrote: > 2017-08-06T15:01:19.285596-07:00 ietfa postfix/smtpd[17799]: NOQUEUE: > reject: RCPT from unknown[49.88.153.38]: 450 4.7.1 Client host > rejected: cannot find your reverse hostname, [49.88.153.38]; > from= to= proto=ESMTP > helo= > However, I notice that this seems not to be hitting *any* IPV6 addresses. > I wonder if there's something in the Postfix config that needs a > tweak. I shall investigate and report. And it seems there was a little messiness in the configuration. I've cleaned it up, redone all the rules and maps, and we now get: 2017-08-07T11:41:50.491348-07:00 ietfa postfix/smtpd[9330]: NOQUEUE: reject: RCPT from unknown[240e:c0:e007:64f9:44ed:67b3:5d38:3062]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [240e:c0:e007:64f9:44ed:67b3:5d38:3062]; from=<993186736@qq.com> to= proto=ESMTP helo= Woo-hoo! Glen From nobody Wed Aug 9 09:02:39 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCC11323CB for ; Wed, 9 Aug 2017 09:02:37 -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 NM-7VAoUE7Np for ; Wed, 9 Aug 2017 09:02:35 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1178E1323A6 for ; Wed, 9 Aug 2017 09:02:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 311F61C3A5E; Wed, 9 Aug 2017 09:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMfRghhHNyv7; Wed, 9 Aug 2017 09:02:18 -0700 (PDT) Received: from meganfeiussmbp2.fios-router.home (unknown [47.144.132.130]) by c8a.amsl.com (Postfix) with ESMTPA id EFB631C3437; Wed, 9 Aug 2017 09:02:17 -0700 (PDT) From: Megan Ferguson Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Aug 2017 09:02:36 -0700 Message-Id: Cc: tools-development@ietf.org To: henrik@levkowetz.com Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 16:02:37 -0000 Hi Henrik, Mostly small input and notes for our records, so combining several test = docs in the message=20 below (and using continuous numbering).=20 =20 The majority are things that probably deserve no fix unless something is = easy to update. However, the Copyright title fix revisited (#6 below) would be good to = have, IMHO. General feedback that the references to RFCs and other known citation = tags are *much improved*=20 (thank you!). Input file: draft-ietf-ipsecme-rfc4307bis-18 Version: id2xml 1.1.0 Issues: reference parsing (note - this was an xml2rfc file originally) Files available:=20 = https://www.rfc-editor.org/rfc/v3test/draft-ietf-ipsecme-rfc4307bis-18v3.o= riginal = https://www.rfc-editor.org/rfc/v3test/draft-ietf-ipsecme-rfc4307bis-18v3.t= xt = https://www.rfc-editor.org/rfc/v3test/draft-ietf-ipsecme-rfc4307bis-18v3-r= fcdiff.html = https://www.rfc-editor.org/rfc/v3test/draft-ietf-ipsecme-rfc4307bis-18v3.x= ml 1) Not sure what the deal with this reference is. Initially, I got: draft-ietf-ipsecme-rfc4307bis-18v3.txt(915): Warning: Failed parsing a = reference. Are all elements separated by commas (not periods, not just spaces)?: [TRANSCRIPTION] Bhargavan, K. and G. Leurent, "Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH", NDSS , feb 2016. So I updated the weird space/comma and the date, and then I got: Converting 'draft-ietf-ipsecme-rfc4307bis-18v3.txt' draft-ietf-ipsecme-rfc4307bis-18v3.txt(918): Exception: need more than 1 = value to unpack Failure converting draft-ietf-ipsecme-rfc4307bis-18v3.txt: need more = than 1 value to unpack Traceback (most recent call last): File "/usr/bin/id2xml", line 9, in load_entry_point('id2xml=3D=3D1.1.0', 'console_scripts', 'id2xml')() File "/usr/lib/python2.7/site-packages/id2xml/run.py", line 226, in = run xml =3D parser.parse_to_xml() File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 975, in = parse_to_xml doc =3D self.document() File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 1004, = in document self.root.append(self.back()) File "", line 2, in back File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 578, in = dtrace ret =3D fn(self, *params,**kwargs) File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2738, = in back references =3D self.references([ str(self.section_number) ]) File "", line 2, in references File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 578, in = dtrace ret =3D fn(self, *params,**kwargs) File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2786, = in references references =3D self.references(sublist, level+1) File "", line 2, in references File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 578, in = dtrace ret =3D fn(self, *params,**kwargs) File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2797, = in references ref, entity =3D self.reference() File "", line 2, in reference File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 578, in = dtrace ret =3D fn(self, *params,**kwargs) File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2955, = in reference name, value =3D docname.split(None, 1) ValueError: need more than 1 value to unpack The only way I could get it to parse was to remove =93NDSS=94. =20 Just curious about this case as we see other items in that position = frequently that don=92t cause issues. ---- Input file: draft-ietf-mpls-tp-aps-updates-04 Version: id2xml 1.1.0 Issues: Lowercase surnames, References, texttables Files available:=20 = https://www.rfc-editor.org/rfc/v3test/draft-ietf-mpls-tp-aps-updates-04v3.= original = https://www.rfc-editor.org/rfc/v3test/draft-ietf-mpls-tp-aps-updates-04v3.= txt = https://www.rfc-editor.org/rfc/v3test/draft-ietf-mpls-tp-aps-updates-04v3-= rfcdiff.html = https://www.rfc-editor.org/rfc/v3test/draft-ietf-mpls-tp-aps-updates-04v3.= xml 2) It doesn=92t appear that the surnames beginning with a lowercase = letter are recognized. =20 Note - IMHO, this is okay to leave as is because the warning points out = the issue and this=20 is not common, so please feel free to leave as is unless an easy fix. draft-ietf-mpls-tp-aps-updates-04v3.txt(355): Warning: This author is = listed in the Authors' Addresses section, but was not found on the first page: Huub van Helvoort 3) FYI - Here is another case where a texttable was created poorly. Original: The last paragraph in Section 11 of [RFC7271] is modified as follows: --------- Old text: --------- In the state transition tables below, the letter 'i' stands for "ignore" and is an indication to remain in the current state and continue transmitting the current PSC message. --------- New text: --------- In the state transition tables below, the letter 'i' is the "ignore" flag, and if it is set it means that the top-priority global request is ignored. id2xml text output: The last paragraph in Section 11 of [RFC7271] is modified as follows: Ol -- In "i co Ne In gl While this use of dashes is not usual (i.e., around =93Old=94 and = =93New=94), just want to point out in case. ------ Input file: draft-ietf-bmwg-dcbench-terminology-19 Version: id2xml 1.1.0 Issues: Numbered sections after references, sections missing general = text indentation, Acks trouble with ToC Files available:=20 = https://www.rfc-editor.org/rfc/v3test/draft-ietf-bmwg-dcbench-terminology-= 19v3.original = https://www.rfc-editor.org/rfc/v3test/draft-ietf-bmwg-dcbench-terminology-= 19v3.txt = https://www.rfc-editor.org/rfc/v3test/draft-ietf-bmwg-dcbench-terminology-= 19v3-rfcdiff.html = https://www.rfc-editor.org/rfc/v3test/draft-ietf-bmwg-dcbench-terminology-= 19v3.xml 4) The Abstract appeared without any indentation, which made things = weird in the xml (turned everything into s. Original: Abstract The purpose of this informational document is to establish definitions and describe measurement techniques for data center benchmarking, as well as it is to introduce new terminologies applicable to performance evaluations of data center network equipment. This document establishes the important concepts for benchmarking network switches and routers in the data center and, is a pre-requisite to the test methodology publication [draft-ietf-bmwg-dcbench-methodology]. Many of these terms and methods may be applicable to network equipment beyond this publication's scope as the technologies originally applied in the data center are deployed elsewhere. xml: 5) Related to the above: The whole text of the Acknowledgments section = was pulled into the ToC/section title=20 because it was not indented (same as the Abstract). =20 Original: 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17 10.3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 17 ... 10.3. Acknowledgments The authors would like to thank Alfred Morton, Scott Bradner, Ian Cox, Tim Stevenson for their reviews and feedback. id2xml output (removed the numbering): 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 The authors would like to thank Alfred Morton, Scott Bradner, Ian Cox, Tim Stevenson for their reviews and feedback. . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 =85 Acknowledgments authors would like to thank Alfred Morton, Scott Bradner, Ian Cox, Tim Stevenson for their reviews and feedback. =97=97=97=97=97 Input file: draft-ietf-trill-mtu-negotiation-08 Version: id2xml 1.1.0 Issues: Updates values in header, Copyright title Files available:=20 = https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-mtu-negotiation-08v= 3.original = https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-mtu-negotiation-08v= 3.txt = https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-mtu-negotiation-08v= 3-rfcdiff.html = https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-mtu-negotiation-08v= 3.xml 6) It appears that the title =93Copyright and License Notice=94 is not = recognized. =20 Once I updated, I got successful parsing. Just want to revisit this one = as it seems we get this title a lot. Warning: Expected a back section, found '1. Introduction=92 The list of common section titles from my previous mail on the topic: > Copyright > Copyright Notice > Copyright Notice and License > Copyright and License Notice > Copyright, Disclaimer, and Additional IPR Provisions > Copyright and IPR Provisions > Copyright Statement Thanks! Megan From nobody Wed Aug 9 11:53:14 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8CB132064 for ; Wed, 9 Aug 2017 11:53:13 -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 kPs00La6UiQy for ; Wed, 9 Aug 2017 11:53:11 -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 03347132359 for ; Wed, 9 Aug 2017 11:53:11 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:56206 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 1dfW6P-0008Sl-1F; Wed, 09 Aug 2017 11:53:10 -0700 To: Megan Ferguson References: Cc: tools-development@ietf.org From: Henrik Levkowetz Message-ID: Date: Wed, 9 Aug 2017 20:53:00 +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="VsPqgSc6BKbwCsBrguKjsgm9DFplo3pVW" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-development@ietf.org, mferguson@amsl.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: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 18:53:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VsPqgSc6BKbwCsBrguKjsgm9DFplo3pVW Content-Type: multipart/mixed; boundary="nxM20P7K8fKeIFWAlQGuaooxkHBOLeF0d"; protected-headers="v1" From: Henrik Levkowetz To: Megan Ferguson Cc: tools-development@ietf.org Message-ID: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml References: In-Reply-To: --nxM20P7K8fKeIFWAlQGuaooxkHBOLeF0d Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Megan, On 2017-08-09 18:02, Megan Ferguson wrote: > Hi Henrik, >=20 > Mostly small input and notes for our records, so combining several > test docs in the message below (and using continuous numbering). >=20 > The majority are things that probably deserve no fix unless something > is easy to update. However, the Copyright title fix revisited (#6 > below) would be good to have, IMHO. >=20 > General feedback that the references to RFCs and other known citation > tags are *much improved* (thank you!). Oh, good :-) > Input file: draft-ietf-ipsecme-rfc4307bis-18 > Version: id2xml 1.1.0 > Issues: reference parsing (note - this was an xml2rfc file originally) > Files available:=20 > https://www.rfc-editor.org/rfc/v3test/draft-ietf-ipsecme-rfc4307bis-18v= 3.original > https://www.rfc-editor.org/rfc/v3test/draft-ietf-ipsecme-rfc4307bis-18v= 3.txt > https://www.rfc-editor.org/rfc/v3test/draft-ietf-ipsecme-rfc4307bis-18v= 3-rfcdiff.html > https://www.rfc-editor.org/rfc/v3test/draft-ietf-ipsecme-rfc4307bis-18v= 3.xml >=20 >=20 > 1) Not sure what the deal with this reference is. Initially, I got: >=20 > draft-ietf-ipsecme-rfc4307bis-18v3.txt(915): Warning: Failed parsing a = reference. Are all elements separated > by commas (not periods, not just spaces)?: > [TRANSCRIPTION] > Bhargavan, K. and G. Leurent, "Transcript Collision > Attacks: Breaking Authentication in TLS, IKE, and SSH", > NDSS , feb 2016. >=20 >=20 > So I updated the weird space/comma and the date, and then I got: >=20 > Converting 'draft-ietf-ipsecme-rfc4307bis-18v3.txt' >=20 > draft-ietf-ipsecme-rfc4307bis-18v3.txt(918): Exception: need more than = 1 value > to unpack > Failure converting draft-ietf-ipsecme-rfc4307bis-18v3.txt: need more th= an 1 value to unpack > Traceback (most recent call last): > File "/usr/bin/id2xml", line 9, in > load_entry_point('id2xml=3D=3D1.1.0', 'console_scripts', 'id2xml')(= ) > File "/usr/lib/python2.7/site-packages/id2xml/run.py", line 226, in r= un > xml =3D parser.parse_to_xml() > File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 975, i= n parse_to_xml > doc =3D self.document() > File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 1004, = in document > self.root.append(self.back()) > File "", line 2, in back > File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 578, i= n dtrace > ret =3D fn(self, *params,**kwargs) > File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2738, = in back > references =3D self.references([ str(self.section_number) ]) > File "", line 2, in references > File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 578, i= n dtrace > ret =3D fn(self, *params,**kwargs) > File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2786, = in references > references =3D self.references(sublist, level+1) > File "", line 2, in references > File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 578, i= n dtrace > ret =3D fn(self, *params,**kwargs) > File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2797, = in references > ref, entity =3D self.reference() > File "", line 2, in reference > File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 578, i= n dtrace > ret =3D fn(self, *params,**kwargs) > File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2955, = in reference > name, value =3D docname.split(None, 1) > ValueError: need more than 1 value to unpack Oops. Bug. Will be fixed in 1.2.0 > The only way I could get it to parse was to remove =E2=80=9CNDSS=E2=80=9D= =2E =20 > Just curious about this case as we see other items in that position fre= quently that don=E2=80=99t cause issues. The reference patterns that id2xml recognises have either series info or document name in that position. Series info implies at least 2 component= s, the series name and the series number/value. With "NDSS" in this positio= n, id2xml tried to split it in 2, to get at series name and number, and fail= ed spectacularly. After the fix I've put in now, id2xml will just ignore "NDSS", as it real= ly doesn't know what to do with it. > ---- >=20 > Input file: draft-ietf-mpls-tp-aps-updates-04 > Version: id2xml 1.1.0 > Issues: Lowercase surnames, References, texttables > Files available:=20 > https://www.rfc-editor.org/rfc/v3test/draft-ietf-mpls-tp-aps-updates-04= v3.original > https://www.rfc-editor.org/rfc/v3test/draft-ietf-mpls-tp-aps-updates-04= v3.txt > https://www.rfc-editor.org/rfc/v3test/draft-ietf-mpls-tp-aps-updates-04= v3-rfcdiff.html > https://www.rfc-editor.org/rfc/v3test/draft-ietf-mpls-tp-aps-updates-04= v3.xml >=20 > 2) It doesn=E2=80=99t appear that the surnames beginning with a lowerca= se letter are recognized. =20 > Note - IMHO, this is okay to leave as is because the warning points out= the issue and this=20 > is not common, so please feel free to leave as is unless an easy fix. It's not really a simple fix, because it basically requires an understand= ing of what's called surname particles (things like 'van', 'von', 'de', etc.)= =2E In the datatracker, I have a routine which does something like this, and = it currently recognizes the following particles: af|al|Al|de|der|di|Di|du|el|El|Hadi|in 't|Le|st\.?|St\.?|ten|ter|van|va= n der|Van|von|von der|Von|zu and this is not a complete set. I probably can put the same set into id2xml, but it still won't be a complete fix, so it might be better to handle this manually anyway. =20 (In the datatracker case, that option doesn't really exist when serving a= web-page ...) > draft-ietf-mpls-tp-aps-updates-04v3.txt(355): Warning: This author is l= isted in the Authors' Addresses section, but was > not found on the first page: Huub van Helvoort Right; a result of not recognizing the 'van'. > 3) FYI - Here is another case where a texttable was created poorly. >=20 > Original: > The last paragraph in Section 11 of [RFC7271] is modified as follows= : >=20 > --------- > Old text: > --------- > In the state transition tables below, the letter 'i' stands for > "ignore" and is an indication to remain in the current state and > continue transmitting the current PSC message. > --------- > New text: > --------- > In the state transition tables below, the letter 'i' is the > "ignore" flag, and if it is set it means that the top-priority > global request is ignored. >=20 >=20 > id2xml text output: >=20 > The last paragraph in Section 11 of [RFC7271] is modified as follows= : >=20 > Ol > -- > In > "i > co > Ne > In > gl Huh. Ugh. > While this use of dashes is not usual (i.e., around =E2=80=9COld=E2=80=9D= and =E2=80=9CNew=E2=80=9D), just want to point out in case. Right. How have you resolved this in the xml? What would be the desired output,= if it was not made a texttable ? > ------ >=20 > Input file: draft-ietf-bmwg-dcbench-terminology-19 > Version: id2xml 1.1.0 > Issues: Numbered sections after references, sections missing general te= xt indentation, Acks trouble with ToC > Files available:=20 > https://www.rfc-editor.org/rfc/v3test/draft-ietf-bmwg-dcbench-terminolo= gy-19v3.original > https://www.rfc-editor.org/rfc/v3test/draft-ietf-bmwg-dcbench-terminolo= gy-19v3.txt > https://www.rfc-editor.org/rfc/v3test/draft-ietf-bmwg-dcbench-terminolo= gy-19v3-rfcdiff.html > https://www.rfc-editor.org/rfc/v3test/draft-ietf-bmwg-dcbench-terminolo= gy-19v3.xml >=20 > 4) The Abstract appeared without any indentation, which made things > weird in the xml (turned everything into s. Yes. The assumption that paragraphs are indented relative to section titles is rather fundamental. I've tried to get around that in earlier tools, and it creates a lot of other problems. I think this will have to= be handled by adding the appropriate paragraph indentation. > Original: >=20 > Abstract >=20 > The purpose of this informational document is to establish definitions > and describe measurement techniques for data center benchmarking, as > well as it is to introduce new terminologies applicable to performance > evaluations of data center network equipment. This document establishes= > the important concepts for benchmarking network switches and routers in= > the data center and, is a pre-requisite to the test methodology > publication [draft-ietf-bmwg-dcbench-methodology]. Many of these terms > and methods may be applicable to network equipment beyond this > publication's scope as the technologies originally applied in the data > center are deployed elsewhere. >=20 >=20 > xml: > <= note title=3D"the important concepts for benchmarking network switches an= d routers in"/> >=20 >=20 > 5) Related to the above: The whole text of the Acknowledgments section= was pulled into the ToC/section title=20 > because it was not indented (same as the Abstract). Right. That would happen. Sorry ,:-/ =20 >=20 > Original: >=20 > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 1= 6 > 10.1. Normative References . . . . . . . . . . . . . . . . . . 1= 6 > 10.2. Informative References . . . . . . . . . . . . . . . . . 1= 7 > 10.3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 1= 7 >=20 >=20 > ... >=20 > 10.3. Acknowledgments >=20 > The authors would like to thank Alfred Morton, Scott Bradner, > Ian Cox, Tim Stevenson for their reviews and feedback. >=20 >=20 >=20 > id2xml output (removed the numbering): > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 1= 6 > 10.1. Normative References . . . . . . . . . . . . . . . . . . 1= 6 > 10.2. Informative References . . . . . . . . . . . . . . . . . 1= 7 > Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 1= 7 > The authors would like to thank Alfred Morton, Scott Bradner, Ian > Cox, Tim Stevenson for their reviews and feedback. . . . . . . . 1= 7 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 1= 7 >=20 >=20 > =E2=80=A6 > Acknowledgments >=20 > authors would like to thank Alfred Morton, Scott Bradner, Ian Cox, Tim > Stevenson for their reviews and feedback. >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >=20 > Input file: draft-ietf-trill-mtu-negotiation-08 > Version: id2xml 1.1.0 > Issues: Updates values in header, Copyright title > Files available:=20 > https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-mtu-negotiation-= 08v3.original > https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-mtu-negotiation-= 08v3.txt > https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-mtu-negotiation-= 08v3-rfcdiff.html > https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-mtu-negotiation-= 08v3.xml >=20 > 6) It appears that the title =E2=80=9CCopyright and License Notice=E2=80= =9D is not > recognized. Once I updated, I got successful parsing. Just want to > revisit this one as it seems we get this title a lot. Ok. I've added the variations you mention below to the recognized titles= of this section, in 1.2.0. Please note that if the section text doesn't match the recognised boilerplate text, there will still be an error. I'm pushing out 1.2.0 now. Best regards, Henrik >=20 > Warning: Expected a back section, found '1. Introduction=E2=80=99 >=20 > The list of common section titles from my previous mail on the > topic: >=20 >> Copyright >> Copyright Notice >> Copyright Notice and License >> Copyright and License Notice >> Copyright, Disclaimer, and Additional IPR Provisions >> Copyright and IPR Provisions >> Copyright Statement >=20 >=20 >=20 >=20 > Thanks! >=20 > Megan >=20 >=20 >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 --nxM20P7K8fKeIFWAlQGuaooxkHBOLeF0d-- --VsPqgSc6BKbwCsBrguKjsgm9DFplo3pVW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZi1oNAAoJEE6bV0uPuxcaNJoP/j3ol/Q+GgMNIuIMfRiZ35K/ AADTW45tdDoehN/kT3tAGrNNfNjFj59/YbENCrRrnI9khwmuWge1Gn7UxhH1Debo Tfxf4YBtxYsDqxq9YEsXNSodXyqQfgOdaK2TYYfWoQ8O1++L9m0tWA0zgR35r58J xurMZ+Zf/9qiji8qOn4L/eUrUq9YaielEfJxxxi6DxREUaG2Wdb9uM8Q6GuaWFrV goqILMZcfubK5wqtzB9adiv3TQ/p5+QFiKL0eQs+V1Kjj4NyKqmPSSdJmAuyF3Lu 87y0HvNS0D6aAzp5p4iyzBXVuPV0FZk1COC3pPc745+1sHuua3leF5ulERg+KjBf KNuRbScSphR15jQvoaVZvVyLe+48IFSNYbUTBgTpW2Y78FGtgk7UtZX1CA03bpyc HR3LMJTggXV65Lj0edopkYlJwLT9I++7wqhjhm8LsADfh4PkQIxN2VWN+iRpuIqt ergz88BVrWDG0IEIGyxnz3d4k8O+jzk1GpMUZAteeNlPgey0rkjLUwdNXSj5KJDU h0Emy23eiIsnKj38TMl+rdCL+vG3vKMQccmYH7KFl3atsJjNHOiEGAyYeuM3RkXz QzzMW60Adz86JBHIQlZFrdjUQEE+t/k/jjWBpY+y2cbRAaqYcP0i5izxuXN0Oj46 UKl35/hwu943y+B2H13l =H+5c -----END PGP SIGNATURE----- --VsPqgSc6BKbwCsBrguKjsgm9DFplo3pVW-- From nobody Wed Aug 9 21:14:59 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E46D132549 for ; Wed, 9 Aug 2017 21:14:58 -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 adUdg1KfUtMZ for ; Wed, 9 Aug 2017 21:14:55 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8BD132491 for ; Wed, 9 Aug 2017 21:14:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E317D1C3445; Wed, 9 Aug 2017 21:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXK8iqOVC8ni; Wed, 9 Aug 2017 21:14:37 -0700 (PDT) Received: from meganfeiussmbp2.fios-router.home (unknown [47.144.132.130]) by c8a.amsl.com (Postfix) with ESMTPA id 9C0031C3150; Wed, 9 Aug 2017 21:14:37 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: Date: Wed, 9 Aug 2017 21:14:51 -0700 Cc: tools-development@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Henrik Levkowetz X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 04:14:58 -0000 Hi Henrik, Thanks for the prompt reply. =20 Apologies as there was one additional document I missed in my previous = mail: Input file: draft-ietf-trill-rbridge-multilevel-07 Version: id2xml 1.1.0 Issues: Unnumbered references sections, short title = (non-xml2rfc-generated original) Files available:=20 = https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-rbridge-multilevel-= 07v3.original = https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-rbridge-multilevel-= 07v3.txt = https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-rbridge-multilevel-= 07v3-rfcdiff.html = https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-rbridge-multilevel-= 07v3.xml 7) This document used two unnumbered sections: =93Normative References=94 = and =93Informative References=94. =20 id2xml added numbering and a =93References=94 section for them to be = children of, but the titles of=20 the two subsections were =93References=94 so we ended up with: 10. References 10.1. References 10.2. References 8) There was no short title provided in the original. Looks like id2xml = hijacked the author name=20 information to put into this position. Perlman, et al. Expires January 4, 2018 [Page 2] Internet-Draft Perlman, et al July 2017 Thanks again! Megan On Aug 9, 2017, at 11:53 AM, Henrik Levkowetz = wrote: > Hi Megan, >=20 > On 2017-08-09 18:02, Megan Ferguson wrote: >> Hi Henrik, >>=20 >> Mostly small input and notes for our records, so combining several >> test docs in the message below (and using continuous numbering). >>=20 >> The majority are things that probably deserve no fix unless something >> is easy to update. However, the Copyright title fix revisited (#6 >> below) would be good to have, IMHO. >>=20 >> General feedback that the references to RFCs and other known citation >> tags are *much improved* (thank you!). >=20 > Oh, good :-) >=20 >> Input file: draft-ietf-ipsecme-rfc4307bis-18 >> Version: id2xml 1.1.0 >> Issues: reference parsing (note - this was an xml2rfc file = originally) >> Files available:=20 >> = https://www.rfc-editor.org/rfc/v3test/draft-ietf-ipsecme-rfc4307bis-18v3.o= riginal >> = https://www.rfc-editor.org/rfc/v3test/draft-ietf-ipsecme-rfc4307bis-18v3.t= xt >> = https://www.rfc-editor.org/rfc/v3test/draft-ietf-ipsecme-rfc4307bis-18v3-r= fcdiff.html >> = https://www.rfc-editor.org/rfc/v3test/draft-ietf-ipsecme-rfc4307bis-18v3.x= ml >>=20 >>=20 >> 1) Not sure what the deal with this reference is. Initially, I got: >>=20 >> draft-ietf-ipsecme-rfc4307bis-18v3.txt(915): Warning: Failed parsing = a reference. Are all elements separated >> by commas (not periods, not just spaces)?: >> [TRANSCRIPTION] >> Bhargavan, K. and G. Leurent, "Transcript Collision >> Attacks: Breaking Authentication in TLS, IKE, and SSH", >> NDSS , feb 2016. >>=20 >>=20 >> So I updated the weird space/comma and the date, and then I got: >>=20 >> Converting 'draft-ietf-ipsecme-rfc4307bis-18v3.txt' >>=20 >> draft-ietf-ipsecme-rfc4307bis-18v3.txt(918): Exception: need more = than 1 value >> to unpack >> Failure converting draft-ietf-ipsecme-rfc4307bis-18v3.txt: need more = than 1 value to unpack >> Traceback (most recent call last): >> File "/usr/bin/id2xml", line 9, in >> load_entry_point('id2xml=3D=3D1.1.0', 'console_scripts', = 'id2xml')() >> File "/usr/lib/python2.7/site-packages/id2xml/run.py", line 226, in = run >> xml =3D parser.parse_to_xml() >> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 975, = in parse_to_xml >> doc =3D self.document() >> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 1004, = in document >> self.root.append(self.back()) >> File "", line 2, in back >> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 578, = in dtrace >> ret =3D fn(self, *params,**kwargs) >> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2738, = in back >> references =3D self.references([ str(self.section_number) ]) >> File "", line 2, in references >> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 578, = in dtrace >> ret =3D fn(self, *params,**kwargs) >> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2786, = in references >> references =3D self.references(sublist, level+1) >> File "", line 2, in references >> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 578, = in dtrace >> ret =3D fn(self, *params,**kwargs) >> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2797, = in references >> ref, entity =3D self.reference() >> File "", line 2, in reference >> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 578, = in dtrace >> ret =3D fn(self, *params,**kwargs) >> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2955, = in reference >> name, value =3D docname.split(None, 1) >> ValueError: need more than 1 value to unpack >=20 > Oops. Bug. Will be fixed in 1.2.0 >=20 >> The only way I could get it to parse was to remove =93NDSS=94. =20 >> Just curious about this case as we see other items in that position = frequently that don=92t cause issues. >=20 > The reference patterns that id2xml recognises have either series info = or > document name in that position. Series info implies at least 2 = components, > the series name and the series number/value. With "NDSS" in this = position, > id2xml tried to split it in 2, to get at series name and number, and = failed > spectacularly. >=20 > After the fix I've put in now, id2xml will just ignore "NDSS", as it = really > doesn't know what to do with it. >=20 >> ---- >>=20 >> Input file: draft-ietf-mpls-tp-aps-updates-04 >> Version: id2xml 1.1.0 >> Issues: Lowercase surnames, References, texttables >> Files available:=20 >> = https://www.rfc-editor.org/rfc/v3test/draft-ietf-mpls-tp-aps-updates-04v3.= original >> = https://www.rfc-editor.org/rfc/v3test/draft-ietf-mpls-tp-aps-updates-04v3.= txt >> = https://www.rfc-editor.org/rfc/v3test/draft-ietf-mpls-tp-aps-updates-04v3-= rfcdiff.html >> = https://www.rfc-editor.org/rfc/v3test/draft-ietf-mpls-tp-aps-updates-04v3.= xml >>=20 >> 2) It doesn=92t appear that the surnames beginning with a lowercase = letter are recognized. =20 >> Note - IMHO, this is okay to leave as is because the warning points = out the issue and this=20 >> is not common, so please feel free to leave as is unless an easy fix. >=20 > It's not really a simple fix, because it basically requires an = understanding > of what's called surname particles (things like 'van', 'von', 'de', = etc.). >=20 > In the datatracker, I have a routine which does something like this, = and it > currently recognizes the following particles: >=20 > af|al|Al|de|der|di|Di|du|el|El|Hadi|in = 't|Le|st\.?|St\.?|ten|ter|van|van der|Van|von|von der|Von|zu >=20 > and this is not a complete set. >=20 > I probably can put the same set into id2xml, but it still won't be a > complete fix, so it might be better to handle this manually anyway. =20= > (In the datatracker case, that option doesn't really exist when = serving a > web-page ...) >=20 >> draft-ietf-mpls-tp-aps-updates-04v3.txt(355): Warning: This author is = listed in the Authors' Addresses section, but was >> not found on the first page: Huub van Helvoort >=20 > Right; a result of not recognizing the 'van'. >=20 >> 3) FYI - Here is another case where a texttable was created poorly. >>=20 >> Original: >> The last paragraph in Section 11 of [RFC7271] is modified as = follows: >>=20 >> --------- >> Old text: >> --------- >> In the state transition tables below, the letter 'i' stands for >> "ignore" and is an indication to remain in the current state and >> continue transmitting the current PSC message. >> --------- >> New text: >> --------- >> In the state transition tables below, the letter 'i' is the >> "ignore" flag, and if it is set it means that the top-priority >> global request is ignored. >>=20 >>=20 >> id2xml text output: >>=20 >> The last paragraph in Section 11 of [RFC7271] is modified as = follows: >>=20 >> Ol >> -- >> In >> "i >> co >> Ne >> In >> gl >=20 > Huh. Ugh. >=20 >> While this use of dashes is not usual (i.e., around =93Old=94 and = =93New=94), just want to point out in case. >=20 > Right. >=20 > How have you resolved this in the xml? What would be the desired = output, > if it was not made a texttable ? >=20 >=20 >> ------ >>=20 >> Input file: draft-ietf-bmwg-dcbench-terminology-19 >> Version: id2xml 1.1.0 >> Issues: Numbered sections after references, sections missing general = text indentation, Acks trouble with ToC >> Files available:=20 >> = https://www.rfc-editor.org/rfc/v3test/draft-ietf-bmwg-dcbench-terminology-= 19v3.original >> = https://www.rfc-editor.org/rfc/v3test/draft-ietf-bmwg-dcbench-terminology-= 19v3.txt >> = https://www.rfc-editor.org/rfc/v3test/draft-ietf-bmwg-dcbench-terminology-= 19v3-rfcdiff.html >> = https://www.rfc-editor.org/rfc/v3test/draft-ietf-bmwg-dcbench-terminology-= 19v3.xml >>=20 >> 4) The Abstract appeared without any indentation, which made things >> weird in the xml (turned everything into s. >=20 > Yes. The assumption that paragraphs are indented relative to section > titles is rather fundamental. I've tried to get around that in = earlier > tools, and it creates a lot of other problems. I think this will have = to > be handled by adding the appropriate paragraph indentation. >=20 >> Original: >>=20 >> Abstract >>=20 >> The purpose of this informational document is to establish = definitions >> and describe measurement techniques for data center benchmarking, as >> well as it is to introduce new terminologies applicable to = performance >> evaluations of data center network equipment. This document = establishes >> the important concepts for benchmarking network switches and routers = in >> the data center and, is a pre-requisite to the test methodology >> publication [draft-ietf-bmwg-dcbench-methodology]. Many of these = terms >> and methods may be applicable to network equipment beyond this >> publication's scope as the technologies originally applied in the = data >> center are deployed elsewhere. >>=20 >>=20 >> xml: >> >>=20 >>=20 >> 5) Related to the above: The whole text of the Acknowledgments = section was pulled into the ToC/section title=20 >> because it was not indented (same as the Abstract). >=20 > Right. That would happen. Sorry ,:-/ >=20 >>=20 >> Original: >>=20 >> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . = 16 >> 10.1. Normative References . . . . . . . . . . . . . . . . . . = 16 >> 10.2. Informative References . . . . . . . . . . . . . . . . . = 17 >> 10.3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . = 17 >>=20 >>=20 >> ... >>=20 >> 10.3. Acknowledgments >>=20 >> The authors would like to thank Alfred Morton, Scott Bradner, >> Ian Cox, Tim Stevenson for their reviews and feedback. >>=20 >>=20 >>=20 >> id2xml output (removed the numbering): >> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . = 16 >> 10.1. Normative References . . . . . . . . . . . . . . . . . . = 16 >> 10.2. Informative References . . . . . . . . . . . . . . . . . = 17 >> Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . = 17 >> The authors would like to thank Alfred Morton, Scott Bradner, Ian >> Cox, Tim Stevenson for their reviews and feedback. . . . . . . . = 17 >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . = 17 >>=20 >>=20 >> =85 >> Acknowledgments >>=20 >> authors would like to thank Alfred Morton, Scott Bradner, Ian Cox, = Tim >> Stevenson for their reviews and feedback. >>=20 >> =97=97=97=97=97 >>=20 >> Input file: draft-ietf-trill-mtu-negotiation-08 >> Version: id2xml 1.1.0 >> Issues: Updates values in header, Copyright title >> Files available:=20 >> = https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-mtu-negotiation-08v= 3.original >> = https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-mtu-negotiation-08v= 3.txt >> = https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-mtu-negotiation-08v= 3-rfcdiff.html >> = https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-mtu-negotiation-08v= 3.xml >>=20 >> 6) It appears that the title =93Copyright and License Notice=94 is = not >> recognized. Once I updated, I got successful parsing. Just want to >> revisit this one as it seems we get this title a lot. >=20 > Ok. I've added the variations you mention below to the recognized = titles > of this section, in 1.2.0. Please note that if the section text = doesn't > match the recognised boilerplate text, there will still be an error. >=20 > I'm pushing out 1.2.0 now. >=20 >=20 > Best regards, >=20 > Henrik >=20 >=20 >>=20 >> Warning: Expected a back section, found '1. Introduction=92 >>=20 >> The list of common section titles from my previous mail on the >> topic: >>=20 >>> Copyright >>> Copyright Notice >>> Copyright Notice and License >>> Copyright and License Notice >>> Copyright, Disclaimer, and Additional IPR Provisions >>> Copyright and IPR Provisions >>> Copyright Statement >>=20 >>=20 >>=20 >>=20 >> Thanks! >>=20 >> Megan >>=20 >>=20 >>=20 >> _______________________________________________ >> TOOLS-DEVELOPMENT mailing list >> TOOLS-DEVELOPMENT@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-development >>=20 >=20 From nobody Thu Aug 10 04:55:48 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546131326A6 for ; Thu, 10 Aug 2017 04:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VmO-N34Es3RG for ; Thu, 10 Aug 2017 04:55:44 -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 37D271326A4 for ; Thu, 10 Aug 2017 04:55:44 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:60240 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 1dfm3y-0004LN-K9; Thu, 10 Aug 2017 04:55:44 -0700 To: Megan Ferguson References: Cc: tools-development@ietf.org From: Henrik Levkowetz Message-ID: Date: Thu, 10 Aug 2017 13:55:27 +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="0PVjkVQ1lO6GTt4rv0csK3eGp6ktBp1KO" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-development@ietf.org, mferguson@amsl.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: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 11:55:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0PVjkVQ1lO6GTt4rv0csK3eGp6ktBp1KO Content-Type: multipart/mixed; boundary="DFqlOF5TA7f8H24aOf23l5HjSCUSNnvsp"; protected-headers="v1" From: Henrik Levkowetz To: Megan Ferguson Cc: tools-development@ietf.org Message-ID: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml References: In-Reply-To: --DFqlOF5TA7f8H24aOf23l5HjSCUSNnvsp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Megan, On 2017-08-10 06:14, Megan Ferguson wrote: > Hi Henrik, >=20 > Thanks for the prompt reply. =20 >=20 > Apologies as there was one additional document I missed in my previous = mail: >=20 > Input file: draft-ietf-trill-rbridge-multilevel-07 > Version: id2xml 1.1.0 > Issues: Unnumbered references sections, short title (non-xml2rfc-genera= ted original) > Files available:=20 > https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-rbridge-multilev= el-07v3.original > https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-rbridge-multilev= el-07v3.txt > https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-rbridge-multilev= el-07v3-rfcdiff.html > https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-rbridge-multilev= el-07v3.xml >=20 >=20 > 7) This document used two unnumbered sections: =E2=80=9CNormative Refer= ences=E2=80=9D > and =E2=80=9CInformative References=E2=80=9D. id2xml added numbering an= d a > =E2=80=9CReferences=E2=80=9D section for them to be children of, but th= e titles of=20 > the two subsections were =E2=80=9CReferences=E2=80=9D so we ended up wi= th: >=20 > 10. References > 10.1. References > 10.2. References Oops. Bug. Will be fixed in version 1.2.1. > 8) There was no short title provided in the original. Looks like > id2xml hijacked the author name information to put into this > position. >=20 > Perlman, et al. Expires January 4, 2018 [Page 2= ] > Internet-Draft Perlman, et al July 201= 7 Yes. The 'Perlman, et al' in the middle of the header line is in the location where id2xml looks for the short title. I think this is best handled manually -- I might be able to write something to recognize an author name there, but what if for instance the document title is "Flanagan's Wake", for an April 1st RFC authored by Heather; or maybe "Updated Van Jacobson TCP Header Compression" by V. Jacobson -- no, I think I'll leave this as is. Best regards, Henrik >=20 > Thanks again! >=20 > Megan >=20 >=20 > On Aug 9, 2017, at 11:53 AM, Henrik Levkowetz wr= ote: >=20 >> Hi Megan, >>=20 >> On 2017-08-09 18:02, Megan Ferguson wrote: >>> Hi Henrik, >>>=20 >>> Mostly small input and notes for our records, so combining several >>> test docs in the message below (and using continuous numbering). >>>=20 >>> The majority are things that probably deserve no fix unless something= >>> is easy to update. However, the Copyright title fix revisited (#6 >>> below) would be good to have, IMHO. >>>=20 >>> General feedback that the references to RFCs and other known citation= >>> tags are *much improved* (thank you!). >>=20 >> Oh, good :-) >>=20 >>> Input file: draft-ietf-ipsecme-rfc4307bis-18 >>> Version: id2xml 1.1.0 >>> Issues: reference parsing (note - this was an xml2rfc file originally= ) >>> Files available:=20 >>> https://www.rfc-editor.org/rfc/v3test/draft-ietf-ipsecme-rfc4307bis-1= 8v3.original >>> https://www.rfc-editor.org/rfc/v3test/draft-ietf-ipsecme-rfc4307bis-1= 8v3.txt >>> https://www.rfc-editor.org/rfc/v3test/draft-ietf-ipsecme-rfc4307bis-1= 8v3-rfcdiff.html >>> https://www.rfc-editor.org/rfc/v3test/draft-ietf-ipsecme-rfc4307bis-1= 8v3.xml >>>=20 >>>=20 >>> 1) Not sure what the deal with this reference is. Initially, I got: >>>=20 >>> draft-ietf-ipsecme-rfc4307bis-18v3.txt(915): Warning: Failed parsing = a reference. Are all elements separated >>> by commas (not periods, not just spaces)?: >>> [TRANSCRIPTION] >>> Bhargavan, K. and G. Leurent, "Transcript Collision >>> Attacks: Breaking Authentication in TLS, IKE, and SSH", >>> NDSS , feb 2016. >>>=20 >>>=20 >>> So I updated the weird space/comma and the date, and then I got: >>>=20 >>> Converting 'draft-ietf-ipsecme-rfc4307bis-18v3.txt' >>>=20 >>> draft-ietf-ipsecme-rfc4307bis-18v3.txt(918): Exception: need more tha= n 1 value >>> to unpack >>> Failure converting draft-ietf-ipsecme-rfc4307bis-18v3.txt: need more = than 1 value to unpack >>> Traceback (most recent call last): >>> File "/usr/bin/id2xml", line 9, in >>> load_entry_point('id2xml=3D=3D1.1.0', 'console_scripts', 'id2xml')= () >>> File "/usr/lib/python2.7/site-packages/id2xml/run.py", line 226, in = run >>> xml =3D parser.parse_to_xml() >>> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 975, = in parse_to_xml >>> doc =3D self.document() >>> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 1004,= in document >>> self.root.append(self.back()) >>> File "", line 2, in back >>> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 578, = in dtrace >>> ret =3D fn(self, *params,**kwargs) >>> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2738,= in back >>> references =3D self.references([ str(self.section_number) ]) >>> File "", line 2, in references >>> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 578, = in dtrace >>> ret =3D fn(self, *params,**kwargs) >>> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2786,= in references >>> references =3D self.references(sublist, level+1) >>> File "", line 2, in references >>> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 578, = in dtrace >>> ret =3D fn(self, *params,**kwargs) >>> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2797,= in references >>> ref, entity =3D self.reference() >>> File "", line 2, in reference >>> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 578, = in dtrace >>> ret =3D fn(self, *params,**kwargs) >>> File "/usr/lib/python2.7/site-packages/id2xml/parser.py", line 2955,= in reference >>> name, value =3D docname.split(None, 1) >>> ValueError: need more than 1 value to unpack >>=20 >> Oops. Bug. Will be fixed in 1.2.0 >>=20 >>> The only way I could get it to parse was to remove =E2=80=9CNDSS=E2=80= =9D. =20 >>> Just curious about this case as we see other items in that position f= requently that don=E2=80=99t cause issues. >>=20 >> The reference patterns that id2xml recognises have either series info = or >> document name in that position. Series info implies at least 2 compon= ents, >> the series name and the series number/value. With "NDSS" in this posi= tion, >> id2xml tried to split it in 2, to get at series name and number, and f= ailed >> spectacularly. >>=20 >> After the fix I've put in now, id2xml will just ignore "NDSS", as it r= eally >> doesn't know what to do with it. >>=20 >>> ---- >>>=20 >>> Input file: draft-ietf-mpls-tp-aps-updates-04 >>> Version: id2xml 1.1.0 >>> Issues: Lowercase surnames, References, texttables >>> Files available:=20 >>> https://www.rfc-editor.org/rfc/v3test/draft-ietf-mpls-tp-aps-updates-= 04v3.original >>> https://www.rfc-editor.org/rfc/v3test/draft-ietf-mpls-tp-aps-updates-= 04v3.txt >>> https://www.rfc-editor.org/rfc/v3test/draft-ietf-mpls-tp-aps-updates-= 04v3-rfcdiff.html >>> https://www.rfc-editor.org/rfc/v3test/draft-ietf-mpls-tp-aps-updates-= 04v3.xml >>>=20 >>> 2) It doesn=E2=80=99t appear that the surnames beginning with a lower= case letter are recognized. =20 >>> Note - IMHO, this is okay to leave as is because the warning points o= ut the issue and this=20 >>> is not common, so please feel free to leave as is unless an easy fix.= >>=20 >> It's not really a simple fix, because it basically requires an underst= anding >> of what's called surname particles (things like 'van', 'von', 'de', et= c.). >>=20 >> In the datatracker, I have a routine which does something like this, a= nd it >> currently recognizes the following particles: >>=20 >> af|al|Al|de|der|di|Di|du|el|El|Hadi|in 't|Le|st\.?|St\.?|ten|ter|van|= van der|Van|von|von der|Von|zu >>=20 >> and this is not a complete set. >>=20 >> I probably can put the same set into id2xml, but it still won't be a >> complete fix, so it might be better to handle this manually anyway. =20 >> (In the datatracker case, that option doesn't really exist when servin= g a >> web-page ...) >>=20 >>> draft-ietf-mpls-tp-aps-updates-04v3.txt(355): Warning: This author is= listed in the Authors' Addresses section, but was >>> not found on the first page: Huub van Helvoort >>=20 >> Right; a result of not recognizing the 'van'. >>=20 >>> 3) FYI - Here is another case where a texttable was created poorly. >>>=20 >>> Original: >>> The last paragraph in Section 11 of [RFC7271] is modified as follow= s: >>>=20 >>> --------- >>> Old text: >>> --------- >>> In the state transition tables below, the letter 'i' stands for >>> "ignore" and is an indication to remain in the current state and >>> continue transmitting the current PSC message. >>> --------- >>> New text: >>> --------- >>> In the state transition tables below, the letter 'i' is the >>> "ignore" flag, and if it is set it means that the top-priority >>> global request is ignored. >>>=20 >>>=20 >>> id2xml text output: >>>=20 >>> The last paragraph in Section 11 of [RFC7271] is modified as follow= s: >>>=20 >>> Ol >>> -- >>> In >>> "i >>> co >>> Ne >>> In >>> gl >>=20 >> Huh. Ugh. >>=20 >>> While this use of dashes is not usual (i.e., around =E2=80=9COld=E2=80= =9D and =E2=80=9CNew=E2=80=9D), just want to point out in case. >>=20 >> Right. >>=20 >> How have you resolved this in the xml? What would be the desired outp= ut, >> if it was not made a texttable ? >>=20 >>=20 >>> ------ >>>=20 >>> Input file: draft-ietf-bmwg-dcbench-terminology-19 >>> Version: id2xml 1.1.0 >>> Issues: Numbered sections after references, sections missing general = text indentation, Acks trouble with ToC >>> Files available:=20 >>> https://www.rfc-editor.org/rfc/v3test/draft-ietf-bmwg-dcbench-termino= logy-19v3.original >>> https://www.rfc-editor.org/rfc/v3test/draft-ietf-bmwg-dcbench-termino= logy-19v3.txt >>> https://www.rfc-editor.org/rfc/v3test/draft-ietf-bmwg-dcbench-termino= logy-19v3-rfcdiff.html >>> https://www.rfc-editor.org/rfc/v3test/draft-ietf-bmwg-dcbench-termino= logy-19v3.xml >>>=20 >>> 4) The Abstract appeared without any indentation, which made things >>> weird in the xml (turned everything into s. >>=20 >> Yes. The assumption that paragraphs are indented relative to section >> titles is rather fundamental. I've tried to get around that in earlie= r >> tools, and it creates a lot of other problems. I think this will have= to >> be handled by adding the appropriate paragraph indentation. >>=20 >>> Original: >>>=20 >>> Abstract >>>=20 >>> The purpose of this informational document is to establish definition= s >>> and describe measurement techniques for data center benchmarking, as >>> well as it is to introduce new terminologies applicable to performanc= e >>> evaluations of data center network equipment. This document establish= es >>> the important concepts for benchmarking network switches and routers = in >>> the data center and, is a pre-requisite to the test methodology >>> publication [draft-ietf-bmwg-dcbench-methodology]. Many of these term= s >>> and methods may be applicable to network equipment beyond this >>> publication's scope as the technologies originally applied in the dat= a >>> center are deployed elsewhere. >>>=20 >>>=20 >>> xml: >>> >>>=20 >>>=20 >>> 5) Related to the above: The whole text of the Acknowledgments secti= on was pulled into the ToC/section title=20 >>> because it was not indented (same as the Abstract). >>=20 >> Right. That would happen. Sorry ,:-/ >>=20 >>>=20 >>> Original: >>>=20 >>> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . = 16 >>> 10.1. Normative References . . . . . . . . . . . . . . . . . . = 16 >>> 10.2. Informative References . . . . . . . . . . . . . . . . . = 17 >>> 10.3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . = 17 >>>=20 >>>=20 >>> ... >>>=20 >>> 10.3. Acknowledgments >>>=20 >>> The authors would like to thank Alfred Morton, Scott Bradner,= >>> Ian Cox, Tim Stevenson for their reviews and feedback. >>>=20 >>>=20 >>>=20 >>> id2xml output (removed the numbering): >>> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . = 16 >>> 10.1. Normative References . . . . . . . . . . . . . . . . . . = 16 >>> 10.2. Informative References . . . . . . . . . . . . . . . . . = 17 >>> Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . = 17 >>> The authors would like to thank Alfred Morton, Scott Bradner, Ian >>> Cox, Tim Stevenson for their reviews and feedback. . . . . . . . = 17 >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . = 17 >>>=20 >>>=20 >>> =E2=80=A6 >>> Acknowledgments >>>=20 >>> authors would like to thank Alfred Morton, Scott Bradner, Ian Cox, Ti= m >>> Stevenson for their reviews and feedback. >>>=20 >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>>=20 >>> Input file: draft-ietf-trill-mtu-negotiation-08 >>> Version: id2xml 1.1.0 >>> Issues: Updates values in header, Copyright title >>> Files available:=20 >>> https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-mtu-negotiatio= n-08v3.original >>> https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-mtu-negotiatio= n-08v3.txt >>> https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-mtu-negotiatio= n-08v3-rfcdiff.html >>> https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-mtu-negotiatio= n-08v3.xml >>>=20 >>> 6) It appears that the title =E2=80=9CCopyright and License Notice=E2= =80=9D is not >>> recognized. Once I updated, I got successful parsing. Just want to >>> revisit this one as it seems we get this title a lot. >>=20 >> Ok. I've added the variations you mention below to the recognized tit= les >> of this section, in 1.2.0. Please note that if the section text doesn= 't >> match the recognised boilerplate text, there will still be an error. >>=20 >> I'm pushing out 1.2.0 now. >>=20 >>=20 >> Best regards, >>=20 >> Henrik >>=20 >>=20 >>>=20 >>> Warning: Expected a back section, found '1. Introduction=E2=80=99 >>>=20 >>> The list of common section titles from my previous mail on the >>> topic: >>>=20 >>>> Copyright >>>> Copyright Notice >>>> Copyright Notice and License >>>> Copyright and License Notice >>>> Copyright, Disclaimer, and Additional IPR Provisions >>>> Copyright and IPR Provisions >>>> Copyright Statement >>>=20 >>>=20 >>>=20 >>>=20 >>> Thanks! >>>=20 >>> Megan >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> TOOLS-DEVELOPMENT mailing list >>> TOOLS-DEVELOPMENT@ietf.org >>> https://www.ietf.org/mailman/listinfo/tools-development >>>=20 >>=20 >=20 > _______________________________________________ > TOOLS-DEVELOPMENT mailing list > TOOLS-DEVELOPMENT@ietf.org > https://www.ietf.org/mailman/listinfo/tools-development >=20 --DFqlOF5TA7f8H24aOf23l5HjSCUSNnvsp-- --0PVjkVQ1lO6GTt4rv0csK3eGp6ktBp1KO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZjEm2AAoJEE6bV0uPuxcah7MP/3QTxJFd8Ih3VT/hwFFXWIxY S4zzCKYBMl0IPbzmTDlBn+hiq6lALDjcCHbmOI+EFlQ06XMpBkNhopQrzsNI63DA 3U6FzgtLfwtrIKvo10o0CZ2GrRQO3xP8JEv6XCrM4gIDJ501p/rULrfTQR5jzK7j nQvP54j4OzfzPCRuDrrBIU/FMC9jryLvz1DhakmGmkDPUhT00nT7ssBjemVFPzCx WgJ8kN5uFGG5R7jtPzOWzU8LMDKnNXNUp31tSMZIxU6ZzAUUa6wYR8iTTufftB+K 0HSPT91cblB3oxW5rhTa5ejBS1Yp3GnsKxl8+wwAk/oFFUIvG4QTeQszEAgzz4g/ A6CCkeGUp6YzzOZl/t9Uat8ROEpqCQFjnYHgX4x73V/ynjaeX5g7T6sas8EH7zXu Acsj5WSb1NEITM1QUfFud+ICAg4fvJdNKSrKUmwHcyVmYSjC4TScNzgE22BvIk/D 2tan/W0EU2TIxSayb5KbuSQKKeDpcyOu8TIJjI2IXwtVlmJnV7VxuIOkh6dzPlvP 60NmFqnMJrSXNfirjw8HGoJpCzMKBpjYF2GqxE3huj5ws3cUhRalyXPgE+pVjt+K kVoWd7PYVGH5iBUPy+ZdvFiGjHYZKJsgsti/rchMEfEvU8pssgOFbdoW2C8Z0YrQ 9JD1ZejoLwmHumJhMxlJ =CgqI -----END PGP SIGNATURE----- --0PVjkVQ1lO6GTt4rv0csK3eGp6ktBp1KO-- From nobody Thu Aug 10 06:26:59 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB381326B5 for ; Thu, 10 Aug 2017 06:26:57 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 iTLoDIlRZcyt for ; Thu, 10 Aug 2017 06:26:56 -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 42416132153 for ; Thu, 10 Aug 2017 06:26:55 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v7ADP2If042410; Thu, 10 Aug 2017 09:26:26 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 2c8mux574a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Aug 2017 09:26:26 -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 v7ADQPxF006766; Thu, 10 Aug 2017 09:26:25 -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 v7ADQKNU006635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 Aug 2017 09:26:23 -0400 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 10 Aug 2017 13:26:11 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.132]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0319.002; Thu, 10 Aug 2017 09:26:11 -0400 From: "HANSEN, TONY L" To: Henrik Levkowetz , Megan Ferguson CC: "tools-development@ietf.org" Thread-Topic: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml Thread-Index: AQHTEUDZdvM24rTIoEuY0xDCzcRRBKJ9PviAgACAsYD//9ZKAA== Date: Thu, 10 Aug 2017 13:26:11 +0000 Message-ID: <39F643F2-83BE-45CB-88B5-DCBF434706DC@att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.210.8.4] Content-Type: text/plain; charset="utf-8" Content-ID: <3AE411612913884F986BC1B09E900936@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-08-10_03:, , 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-1706020000 definitions=main-1708100221 Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 13:26:58 -0000 T24gOC8xMC8xNywgNzo1NiBBTSwgIlRPT0xTLURFVkVMT1BNRU5UIG9uIGJlaGFsZiBvZiBIZW5y aWsgTGV2a293ZXR6IiA8dG9vbHMtZGV2ZWxvcG1lbnQtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgaGVucmlrQGxldmtvd2V0ei5jb20+IHdyb3RlOg0KDQogICAgSGkgTWVnYW4sDQogICAg DQogICAgT24gMjAxNy0wOC0xMCAwNjoxNCwgTWVnYW4gRmVyZ3Vzb24gd3JvdGU6DQogICAgPiBI aSBIZW5yaWssDQogICAgPiANCiAgICA+IFRoYW5rcyBmb3IgdGhlIHByb21wdCByZXBseS4gIA0K ICAgID4gDQogICAgLi4uDQogICAgPiA4KSBUaGVyZSB3YXMgbm8gc2hvcnQgdGl0bGUgcHJvdmlk ZWQgaW4gdGhlIG9yaWdpbmFsLiBMb29rcyBsaWtlDQogICAgPiBpZDJ4bWwgaGlqYWNrZWQgdGhl IGF1dGhvciBuYW1lIGluZm9ybWF0aW9uIHRvIHB1dCBpbnRvIHRoaXMNCiAgICA+IHBvc2l0aW9u Lg0KICAgID4gDQogICAgPiBQZXJsbWFuLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBKYW51YXJ5 IDQsIDIwMTggICAgICAgICAgICAgICAgW1BhZ2UgMl0NCiAgICA+IEludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgUGVybG1hbiwgZXQgYWwgICAgICAgICAgICAgICAgICAgIEp1bHkgMjAxNw0K ICAgIA0KICAgIFllcy4gIFRoZSAnUGVybG1hbiwgZXQgYWwnIGluIHRoZSBtaWRkbGUgb2YgdGhl IGhlYWRlciBsaW5lIGlzIGluIHRoZQ0KICAgIGxvY2F0aW9uIHdoZXJlIGlkMnhtbCBsb29rcyBm b3IgdGhlIHNob3J0IHRpdGxlLiAgSSB0aGluayB0aGlzIGlzIGJlc3QNCiAgICBoYW5kbGVkIG1h bnVhbGx5IC0tIEkgbWlnaHQgYmUgYWJsZSB0byB3cml0ZSBzb21ldGhpbmcgdG8gcmVjb2duaXpl IGFuDQogICAgYXV0aG9yIG5hbWUgdGhlcmUsIGJ1dCB3aGF0IGlmIGZvciBpbnN0YW5jZSB0aGUg ZG9jdW1lbnQgdGl0bGUgaXMNCiAgICAiRmxhbmFnYW4ncyBXYWtlIiwgZm9yIGFuIEFwcmlsIDFz dCBSRkMgYXV0aG9yZWQgYnkgSGVhdGhlcjsgb3IgbWF5YmUNCiAgICAiVXBkYXRlZCBWYW4gSmFj b2Jzb24gVENQIEhlYWRlciBDb21wcmVzc2lvbiIgYnkgVi4gSmFjb2Jzb24gLS0gbm8sIEkNCiAg ICB0aGluayBJJ2xsIGxlYXZlIHRoaXMgYXMgaXMuDQoNCisxIGZvciBsZWF2aW5nIHRoYXQgYXMg aXQgaXMuIEl0IG1pZ2h0IGJlIHdvcnRoIGEgd2FybmluZyB0aG91Z2gsIGlmIHRoZSBmb3VkIHRp dGxlIGhhcyBvbmUgb2YgdGhlIGF1dGhvcuKAmXMgbmFtZXMgd2l0aGluIGl0Lg0KDQoJVG9ueSAN Cg0K From nobody Thu Aug 10 06:32:00 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DD91326C5 for ; Thu, 10 Aug 2017 06:31:57 -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 JNJEbSXgOUTe for ; Thu, 10 Aug 2017 06:31:56 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59A931326C6 for ; Thu, 10 Aug 2017 06:31:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 232491C3178; Thu, 10 Aug 2017 06:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAV2AjXHlcfv; Thu, 10 Aug 2017 06:31:17 -0700 (PDT) Received: from meganfeiussmbp2.fios-router.home (unknown [47.144.132.130]) by c8a.amsl.com (Postfix) with ESMTPA id EC5531C2BA0; Thu, 10 Aug 2017 06:31:16 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: <39F643F2-83BE-45CB-88B5-DCBF434706DC@att.com> Date: Thu, 10 Aug 2017 06:31:33 -0700 Cc: Henrik Levkowetz , "tools-development@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <39F643F2-83BE-45CB-88B5-DCBF434706DC@att.com> To: "HANSEN, TONY L" X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 13:31:58 -0000 Hi Tony, On Aug 10, 2017, at 6:26 AM, HANSEN, TONY L wrote: > On 8/10/17, 7:56 AM, "TOOLS-DEVELOPMENT on behalf of Henrik Levkowetz" = = wrote: >=20 > Hi Megan, >=20 > On 2017-08-10 06:14, Megan Ferguson wrote: >> Hi Henrik, >>=20 >> Thanks for the prompt reply. =20 >>=20 > ... >> 8) There was no short title provided in the original. Looks like >> id2xml hijacked the author name information to put into this >> position. >>=20 >> Perlman, et al. Expires January 4, 2018 [Page = 2] >> Internet-Draft Perlman, et al July = 2017 >=20 > Yes. The 'Perlman, et al' in the middle of the header line is in = the > location where id2xml looks for the short title. I think this is = best > handled manually -- I might be able to write something to recognize = an > author name there, but what if for instance the document title is > "Flanagan's Wake", for an April 1st RFC authored by Heather; or = maybe > "Updated Van Jacobson TCP Header Compression" by V. Jacobson -- no, = I > think I'll leave this as is. >=20 > +1 for leaving that as it is. It might be worth a warning though, if = the foud title has one of the author=92s names within it. Thanks for this idea. Especially because htmlwdiffs don=92t include the = running title, this might be good to have. =20 I am assuming we will be using rfcdiff anyway, but this would be a good = fail-safe, IMHO. Megan >=20 > Tony=20 >=20 From nobody Thu Aug 10 08:10:45 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51951321D0 for ; Thu, 10 Aug 2017 08:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hLiZ8UUGdxEV for ; Thu, 10 Aug 2017 08:10:41 -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 323A21321BB for ; Thu, 10 Aug 2017 08:10:41 -0700 (PDT) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:61212 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 1dfp6e-0002bL-DH; Thu, 10 Aug 2017 08:10:40 -0700 To: "HANSEN, TONY L" , Megan Ferguson References: <39F643F2-83BE-45CB-88B5-DCBF434706DC@att.com> Cc: "tools-development@ietf.org" From: Henrik Levkowetz Message-ID: <6fe02216-6432-79bb-4e0c-a89cf67e27c4@levkowetz.com> Date: Thu, 10 Aug 2017 17:10:32 +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: <39F643F2-83BE-45CB-88B5-DCBF434706DC@att.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KpMlHb7Tp4aG6wFw78W2jaHc8jPGlMVgD" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: tools-development@ietf.org, mferguson@amsl.com, tony@att.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: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 15:10:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KpMlHb7Tp4aG6wFw78W2jaHc8jPGlMVgD Content-Type: multipart/mixed; boundary="0SqNfnRl1S2PtNU33WUDUD3DrgncIsb2f"; protected-headers="v1" From: Henrik Levkowetz To: "HANSEN, TONY L" , Megan Ferguson Cc: "tools-development@ietf.org" Message-ID: <6fe02216-6432-79bb-4e0c-a89cf67e27c4@levkowetz.com> Subject: Re: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml References: <39F643F2-83BE-45CB-88B5-DCBF434706DC@att.com> In-Reply-To: <39F643F2-83BE-45CB-88B5-DCBF434706DC@att.com> --0SqNfnRl1S2PtNU33WUDUD3DrgncIsb2f Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2017-08-10 15:26, HANSEN, TONY L wrote: > On 8/10/17, 7:56 AM, "TOOLS-DEVELOPMENT on behalf of Henrik Levkowetz" = wr= ote: >=20 > Hi Megan, > =20 > On 2017-08-10 06:14, Megan Ferguson wrote: > > Hi Henrik, > >=20 > > Thanks for the prompt reply. =20 > >=20 > ... > > 8) There was no short title provided in the original. Looks like > > id2xml hijacked the author name information to put into this > > position. > >=20 > > Perlman, et al. Expires January 4, 2018 [= Page 2] > > Internet-Draft Perlman, et al Ju= ly 2017 > =20 > Yes. The 'Perlman, et al' in the middle of the header line is in t= he > location where id2xml looks for the short title. I think this is b= est > handled manually -- I might be able to write something to recognize= an > author name there, but what if for instance the document title is > "Flanagan's Wake", for an April 1st RFC authored by Heather; or may= be > "Updated Van Jacobson TCP Header Compression" by V. Jacobson -- no,= I > think I'll leave this as is. >=20 > +1 for leaving that as it is. It might be worth a warning though, if > the foud title has one of the author=E2=80=99s names within it. Good point. Warning added in version 1.2.2 Henrik --0SqNfnRl1S2PtNU33WUDUD3DrgncIsb2f-- --KpMlHb7Tp4aG6wFw78W2jaHc8jPGlMVgD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJZjHdoAAoJEE6bV0uPuxca6FEP/1ukfKBQjGGjnYQeRlIvknrp 9bh2+ZnWC92leLFu1LQUvcJXFPLtpiPty4T152UdgQTQv4EfnOuXlyd05p7ZkIa4 ikTtqxBayjEiyBMcg2cBXHCjWb1jlmwzbxevnsdEhn6+zIs1eiJb4xTjrlZ7xmvv M1M9h4LHEnzTrBUSzy+J24uN8m5QMjG2q5ES74/xP8fvFiP7el/+3Rak06yBhIyl JSdmqBt1Eij6r42HJ6p5yZLBMUVNHm4mYJ87AIzfvf/umjLLWs7Fc9rxnAQssv8h WtNiC8H3hu45D+pqqSP97KFNEUHkuPjKyrQc77elQysS2W4j9suwT0zqdWO4v06a XPDwQ8aVwMnd00u2pVvbAq6qszoUIBwHhOnoYJr7xRq0XMNC1GyiX5XblnalsphD 0cs1f87lggy0Mua66N6PhsA/43/YoOLkyh5gH+OZfY35BV0VwQQxG5tSQdZG2pBL H/ITsMFel2CJRdH9IV4og9f6vmpVVUrEVLVuxODUsm15GSmIbkJz7cyOIIaEXVMq jMs2gjRaOo5+Jj71ce33GZwDtdeq4xCpmT8ht6svsqV76I9yBX62QNwLBUyESQ9c xx/UEcWjmdqSrWskieR1DyMqNd5yD5a0f70Loebzk63cPGMzh/6cVhWH2jcXqQS2 vqngTrfY8Kx4/kR/fhzv =M1ea -----END PGP SIGNATURE----- --KpMlHb7Tp4aG6wFw78W2jaHc8jPGlMVgD-- From nobody Wed Aug 23 22:14:43 2017 Return-Path: X-Original-To: tools-development@ietfa.amsl.com Delivered-To: tools-development@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB981321CB for ; Wed, 23 Aug 2017 22:14:42 -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 Em6Uk-NhbOAx for ; Wed, 23 Aug 2017 22:14:39 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DFD13214D for ; Wed, 23 Aug 2017 22:14:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 1BD141C4A2E; Wed, 23 Aug 2017 22:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK6QurgqrClT; Wed, 23 Aug 2017 22:14:01 -0700 (PDT) Received: from meganfeiussmbp2.fios-router.home (unknown [47.144.132.130]) by c8a.amsl.com (Postfix) with ESMTPA id E18B11C4A2C; Wed, 23 Aug 2017 22:14:00 -0700 (PDT) From: Megan Ferguson Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Aug 2017 22:14:38 -0700 Message-Id: <30D82D2F-567B-4327-8783-EF281B8C96DF@amsl.com> Cc: tools-development@ietf.org To: Henrik Levkowetz Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [TOOLS-DEVELOPMENT] Preview release of Text Submission Converter, id2xml X-BeenThere: tools-development@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Tools Development list server List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 05:14:42 -0000 Hi Henrik, Input file: draft-ietf-trill-rbridge-multilevel-07 (& RFC 8123) Version: id2xml 1.2.2 Issues: draft strings in references, missing xrefs, extra vspace, list = indicator (REQ#) Files available:=20 = https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-rbridge-multilevel-= 07v3.original = https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-rbridge-multilevel-= 07v3.txt = https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-rbridge-multilevel-= 07v3-rfcdiff.html = https://www.rfc-editor.org/rfc/v3test/draft-ietf-trill-rbridge-multilevel-= 07v3.xml Notes: This file is a revisit. I actually moved this document through = our editing process and=20 spotted a few more items based on actually using the xml file in that = process. =20 Level: minor 1) Building on the use of citation tags to pull references from bibxml3 = (which is working out=20 very nicely so far), is there any way that we could identify draft = strings in reference entries=20 and pull the corresponding most-recent version ref from bibxml3 even if = the citation tag is not=20 in the format I-D.ietf-blah=85? An example reference is below. = Obviously, there would be=20 limitations such as the draft string not appearing in the same order, = missing a version number, etc. draft-ietf-trill-rbridge-multilevel-07v3.txt(1677): Warning: Failed = parsing a reference. Are all=20 elements separated by commas (not periods, not just spaces)?: [DraftUnique] - M. Zhang, D. Eastlake, R. Perlman, M. Cullen, H. Zhai, D. Liu, "TRILL Multilevel Using Unique Nicknames", draft- ietf-trill-multilevel-unique-nickname, Work In Progress. 2) This file was missing s for the following. The first one uses = Sections X through Y. =20 The other is missing the -s on Section, so not really surprising that it = was missed. Original: Partitioning the network into areas directly solves the first four scalability issues listed above as described in Sections 1.2.1 through 1.2.4. Multilevel also contributes to solving issues 5 and 6 as discussed in Section 1.2.5 and 1.2.6 respectively. In id2xml xml output:
Partitioning the network into areas directly solves the first four scalability issues listed above as described in Sections 1.2.1 through 1.2.4. Multilevel also contributes to solving issues 5 and 6 as discussed in and 1.2.6 = respectively. 3) A little extra whitespace is inserted before a list item in two = places in this example: Original: There are at least two ways areas could be identified. One method would be to assign each area a 16-bit nickname. This would not be the nickname of any actual TRILL switch. Instead, it would be the nickname of the area itself. Border TRILL switches would know the area nickname for their own area(s). For an example of a more specific multilevel proposal using unique nicknames, see [DraftUnique]. Alternatively, areas could be identified by the set of nicknames that identify the border routers for that area. (See [SingleName] for a multilevel proposal using such a set of nicknames.) The TRILL Header nickname fields in TRILL Data packets being transported through a multilevel TRILL campus with aggregated nicknames are as follows: - When both the ingress and egress TRILL switches are in the same area, there need be no change from the existing base TRILL protocol standard in the TRILL Header nickname fields. - When being transported between different Level 1 areas in Level 2, the ingress nickname is a nickname of the ingress TRILL id2xml text output: There are at least two ways areas could be identified. One method would be to assign each area a 16-bit nickname. This would not be the nickname of any actual TRILL switch. Instead, it would be the nickname of the area itself. Border TRILL switches would know the area nickname for their own area(s). For an example of a more specific multilevel proposal using unique nicknames, see [UNIQUE]. Alternatively, areas could be identified by the set of nicknames that identify the border routers for that area. (See [SingleName] for a multilevel proposal using such a set of nicknames.) The TRILL Header nickname fields in TRILL Data packets being transported through a multilevel TRILL campus with aggregated nicknames are as follows: - When both the ingress and egress TRILL switches are in the same area, there need be no change from the existing base TRILL protocol standard in the TRILL Header nickname fields. In xml: One method would be to assign each area a 16-bit nickname. This would not be the nickname of any actual TRILL switch. Instead, it would be the nickname of the area itself. Border TRILL switches would know the area nickname for their own area(s). For an example of a more specific multilevel proposal using unique nicknames, see . Alternatively, areas could be identified by the set of nicknames that identify the border routers for that area. (See for a multilevel proposal using such a set of nicknames.) The TRILL Header nickname fields in TRILL Data packets being transported through a multilevel TRILL campus with aggregated nicknames are as follows: When both the ingress and egress = TRILL switches are in the same area, there need be no change from the existing base TRILL protocol standard in the TRILL Header nickname fields. When being transported between different Level 1 areas in = Level 2, the ingress nickname is a nickname of the ingress TRILL switch's area while the egress nickname is either a nickname of the egress TRILL switch's area or a tree nickname. When being transported from Level 1 to Level 2, the ingress nickname is the nickname of the ingress TRILL switch itself while the egress nickname is either a nickname for the area of the egress TRILL switch or a tree nickname. When being transported from Level 2 to Level 1, the ingress nickname is a nickname for the ingress TRILL switch's area while the egress nickname is either the nickname of the egress TRILL switch itself or a tree nickname. 4) I=92m wondering if there is a way to include =93REQ#=94 as a list = indicator? I tried a test file=20 based on RFC 8123 (we don=92t have any files doing this in the current = queue), and it doesn=92t=20 seem to be one. =20 In the text: 5. Logme Marking Requirements 5.1. Message Logs REQ1: If a SIP message is logged then the entire SIP message (SIP headers and message body) MUST be logged using standard logging format such as SIP CLF defined in [RFC6873]. REQ2: Header fields SHOULD be logged in the form in which they appear in the message, they SHOULD NOT be converted between long and compact forms described in [RFC3261] clause 7.3.3. In the xml this is made a hanging list:
headers and message body) MUST be logged using standard logging format such as SIP CLF defined in . appear in the message, they SHOULD NOT be converted between long and compact forms described in = clause 7.3.3. Thanks! Megan=