IETF Logo Mail Archive

Re: [lamps] Preparing the shepherd write-up for rfc6844bis

Sean Turner <sean@sn3rd.com> Wed, 28 November 2018 18:13 UTC

Return-Path: <sean@sn3rd.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0A7127B92 for <spasm@ietfa.amsl.com>; Wed, 28 Nov 2018 10:13:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC51kXMfZdFm for <spasm@ietfa.amsl.com>; Wed, 28 Nov 2018 10:13:29 -0800 (PST)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0260130E0F for <spasm@ietf.org>; Wed, 28 Nov 2018 10:13:28 -0800 (PST)
Received: by mail-qt1-x82e.google.com with SMTP id y20so26911475qtm.13 for <spasm@ietf.org>; Wed, 28 Nov 2018 10:13:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0XYAjBT+3U8tjABIjTZtTfPSk0WO/WT1kTao8QWCtrI=; b=UWvs+Fb5bV3n9ZCN8t4JI5A0qL/OEdd6j8RW8yhTHQs6QUXPvFTSY2ZTSx2lEMI49s YiKT9dXkCx2SJwQpQ2h6YG4cYfl6H+bP0nvV9PuGY9QaOuVuztdZ6ESI4Yqs+Mav5qfR 9JDr+S0tGfO7YvuVRJKkujuPq1WLkiTkp0Ztw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0XYAjBT+3U8tjABIjTZtTfPSk0WO/WT1kTao8QWCtrI=; b=dfzdKho6LYsjRpmgAPgMk6gezf/Q7pw/yij4tyaqSBvtuhxzz+FxtzniOqIx2OLBRu jA3zTi79+5Ge16KIMP0bKhGsArYGRBhIFHCwTTrUSIpVbyB/grRXIbNMd34EFYNAQZ74 ZwECcupUxyOxRQ/lh884oWkXGGDVZ5fhuBagCnqbpa6jMItPClScNnGwEMtf9F/5wLgW eQmg9LvihN+4aoCOVLmE++qEUe45wXQvw2iaL0W7p+yPoxkwnGQt7TTchLIYwPE1SwCP pmXwi/GfeBIZ/jn+Lm9VZkDCBMYRkIaV9TpxSniVFvG2GdeGqaRM6UhjsFk+twWsMQ3S vKfg==
X-Gm-Message-State: AA+aEWYXjyDckhF3PqK3rnAOWBz4KtKO2rGJmeCTZVeM+eW4HrIiPfff O2Lv5imm9g9ku0np0E0huj+41w==
X-Google-Smtp-Source: AFSGD/WqOrH9oiMIoAHBSXlYjHjtF8zvQCIcBnLV3IGgQPdAaQ8AFhmcYNiPnhZMbFM+9QYEwccX9Q==
X-Received: by 2002:a0c:8542:: with SMTP id n60mr36164910qva.205.1543428807989; Wed, 28 Nov 2018 10:13:27 -0800 (PST)
Received: from [172.16.0.18] ([96.231.221.42]) by smtp.gmail.com with ESMTPSA id x7sm3323420qti.76.2018.11.28.10.13.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Nov 2018 10:13:27 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <11295b14-5424-ba55-630e-6f22fa44b45d@eff.org>
Date: Wed, 28 Nov 2018 13:13:26 -0500
Cc: fujiwara@jprs.co.jp, Russ Housley <housley@vigilsec.com>, SPASM <spasm@ietf.org>, jsha@letsencrypt.org, Rob Stradling <rob.stradling@comodo.com>, phill@hallambaker.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <27D5EE88-234D-401B-847E-D536A34DE10C@sn3rd.com>
References: <7FC03EEB-0D87-4454-805C-62DBCBA845C3@vigilsec.com> <20181126.140929.1660685088175275606.fujiwara@jprs.co.jp> <11295b14-5424-ba55-630e-6f22fa44b45d@eff.org>
To: Jacob Hoffman-Andrews <jsha@eff.org>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/h7t5Lwg_2sP584o3wX8Sq_bDYAI>
Subject: Re: [lamps] Preparing the shepherd write-up for rfc6844bis
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Nov 2018 18:13:31 -0000

So it depends.  Regardless, I know IANA will ask if you wanted the IANA registry references updated to thisRFC. So if you want:

A clean break from the old RFC, you can just copy the whole section forward and also ask IANA to update the references to “thisRFC”: IANA is requested to use [thisRFC] as the reference for the Certification Authority Restriction Flags and Certification Authority Restriction Properties registries.

Less in the draft then assuming everything was setup in RFC6844 and all the tweak were done via errata (and implemented correctly), then you can leave it blank.  But, you might consider leaving it blank of content and just “IANA is requested to add [thisRFC] as a reference for the Certification Authority Restriction Flags and Certification Authority Restriction Properties registries.”

spt

> On Nov 26, 2018, at 20:38, Jacob Hoffman-Andrews <jsha@eff.org> wrote:
> 
> On 11/25/18 9:09 PM, fujiwara@jprs.co.jp wrote:
> > 2. At section 9 IANA considerations, Reference should be changed as this draft
> >     because this draft obsoletes RFC 6844.
> 
> This and Sean Turner's comment both relate to the IANA Considerations section. I have to admit I'm not familiar with best practice for an IANA Considerations section when writing an "Obsoletes" RFC. Should RFC6844bis have an empty section, since the relevant registries were already established by RFC6844bis? That's what I tried to do in this doc, though I accidentally left in one of the sub-sections ("Certification Authority Restriction Flags").
> 
>> 1. Before proceeding, please fix errata of RFC 6844.
>>    Most of them still remain.
>>    See https://www.rfc-editor.org/errata/rfc6844
> 
> Related to IANA Considerations section:
> 
> https://www.rfc-editor.org/errata/eid3547
> https://www.rfc-editor.org/errata/eid3528
> https://www.rfc-editor.org/errata/eid3532
> 
> Addressed:
> https://www.rfc-editor.org/errata/eid3532
> - We no longer treat DNAME specially.
> 
> https://www.rfc-editor.org/errata/eid5200
> - Parameters are now split by semicolons.
> 
> https://www.rfc-editor.org/errata/eid5244
> - We added explicit wording about non-empty CAA RRsets.
> 
> https://www.rfc-editor.org/errata/eid5452
> - We fixed the ABNF.
> 
> https://www.rfc-editor.org/errata/eid5065
> - This was the discovery algorithm change.
> 
> https://www.rfc-editor.org/errata/eid5091
> - This was obsoleted by the revised language we used for the discovery algorithm.
> 
> 
> Needs addressing:
> https://www.rfc-editor.org/errata/eid4062
> https://www.rfc-editor.org/errata/eid4070
> 
> I'll work on those last two.
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm

v2.23.0 | Report a Bug | By Email