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

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Sun, 4 Nov 2018 11:26:46 -0800

I've now uploaded draft-02 with these fixes. 
https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-02

On 10/31/2018 12:49 PM, Russ Housley wrote:
> The document is missing a revision number.  I am assuming that will get filled in properly when you do the post.
>
> Otherwise, it looks good to me.
>
> Russ
>
>
>> On Oct 30, 2018, at 6:45 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:
>>
>> I've now made these fixes in the latest working copy at https://github.com/jsha/caa-simplification/blob/master/draft-ietf-lamps-rfc6844bis.md. The uploading tool is closed until 2018-11-03 23:59 +07, so I can't upload a fresh draft. I can provide rendered .txt or .xml format of the current working copy to anyone who would prefer to read in those formats.
>>
>> On 10/30/18 10:04 AM, Russ Housley wrote:
>>> IDnits reports the following problems:
>>>
>>> idnits 2.16.0
>>>
>>>    Checking nits according to https://www.ietf.org/id-info/checklist :
>>>    ----------------------------------------------------------------------------
>>>
>>>    == The 'Obsoletes: ' line in the draft header should list only the
>>>       _numbers_ of the RFCs which will be obsoleted by this document (if
>>>       approved); it should not include the word 'RFC' in the list.
>>>
>>> {{{ Easy to fix, and I would not say anything if this was the only issue. }}}
>>>
>>>
>>>    -- The draft header indicates that this document obsoletes RFC6844, but the
>>>       abstract doesn't seem to mention this, which it should.
>>>
>>> {{{ Please add a sentence to the Abstract. }}}
>>>
>>>
>>>    Checking references for intended status: Proposed Standard
>>>    ----------------------------------------------------------------------------
>>>
>>>       (See RFCs 3967 and 4897 for information about using normative references
>>>       to lower-maturity documents in RFCs)
>>>
>>>    == Missing Reference: 'STD13' is mentioned on line 194, but not defined
>>>
>>> {{{ Perhaps you meant to reference RFC 1035 here. }}}
>>>
>>>
>>>    ** Downref: Normative reference to an Informational RFC: RFC 3647
>>>
>>> {{{ Can this be moved to an Informational reference? }}}
>>>
>>>
>>>    ** Obsolete normative reference: RFC 5070 (Obsoleted by RFC 7970)
>>>
>>> {{{ Is there a reason to not reference RFC 7970? }}}
>>>
>>>
>>>    ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
>>>
>>> {{{ Is there a reason to not reference RFC 8126? }}}
>>>
>>> Russ
>>>
>>>
>>>
>> _______________________________________________
>> Spasm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/spasm
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Sean Turner <[email-masked]>
Date: Sun, 25 Nov 2018 13:32:53 -0500

Russ,

While probably not strictly part of the shepherd write-up it might be good to note that the expert(s) for the Certification Authority Restriction Properties remains “Unassigned”:

https://www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml#caa-properties

One minor nittty nit on the draft:

s9.1 (remove stray “>”): r/Reserved>/Reserved

spt

> On Oct 30, 2018, at 13:04, Russ Housley <[email-masked]> wrote:
>

---

From: [email-masked]
Date: Mon, 26 Nov 2018 14:09:29 +0900 (JST)

# Sorry I missed WGLC mails.

1. Before proceeding, please fix errata of RFC 6844.
   Most of them still remain.

   See https://www.rfc-editor.org/errata/rfc6844

2. At section 9 IANA considerations, Reference should be changed as this draft
   because this draft obsoletes RFC 6844.

   See RFC 6891. The RFC changed reference from obsoleted RFC 2671 to this RFC.

I believe IESG and IANA will find and fix them, but please fix before them.

--
Kazunori Fujiwara, JPRS <[email-masked]>

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Nov 2018 13:03:01 -0500

Thanks Sean.

> https://www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml#caa-properties <https://www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml#caa-properties>

I added that to the write-up.

> s9.1 (remove stray “>”): r/Reserved>/Reserved

I leave that to the authors when the address the other nits.

Russ

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 26 Nov 2018 14:09:47 -0500

I did volunteer to be the expert when the registry was set up and was under
the impression that I was. I note that there is also a PKIX SRV Protocol
Labels registry which has arguably been overtaken by events and should have
been a DNS registry, not a PKIX registry all along.

On Mon, Nov 26, 2018 at 1:03 PM Russ Housley <[email-masked]> wrote:

> Thanks Sean.
>
> While probably not strictly part of the shepherd write-up it might be good
> to note that the expert(s) for the Certification Authority Restriction
> Properties remains “Unassigned”:
>
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Nov 2018 15:12:50 -0500

> On Nov 26, 2018, at 2:09 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> I did volunteer to be the expert when the registry was set up and was under the impression that I was. I note that there is also a PKIX SRV Protocol Labels registry which has arguably been overtaken by events and should have been a DNS registry, not a PKIX registry all along. 
> 
> On Mon, Nov 26, 2018 at 1:03 PM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> Thanks Sean.
>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 26 Nov 2018 17:38:50 -0800

>     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").

>     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.

---

From: Sean Turner <[email-masked]>
Date: Wed, 28 Nov 2018 13:13:26 -0500

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 <[email-masked]> wrote:
> 
> 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").
> 
> - This was obsoleted by the revised language we used for the discovery algorithm.
> 
> 
> Needs addressing:

---

From: Tim Hollebeek <[email-masked]>
Date: Wed, 28 Nov 2018 19:11:22 +0000

Jacob,

Thanks for the excellent analysis and timely analysis of 
the outstanding errata.  I agree with your analysis
except where noted inline.

> https://www.rfc-editor.org/errata/eid3532

Copy/paste error: You meant eid5097 here.

> https://www.rfc-editor.org/errata/eid4070

eid5090?

-Tim

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 30 Nov 2018 15:37:36 -0800

Thanks for the eagle eye, Tim!

 > Copy/paste error: You meant eid5097 here.

Yep.

> eid5090?

Thanks for spotting this one. I consider it addressed.

Addressed:

https://www.rfc-editor.org/errata/eid5090

  - The current language says "A set of Resource Records of a particular 
owner name, class, [etc]"

---

From: Tim Hollebeek <[email-masked]>
Date: Fri, 30 Nov 2018 23:50:10 +0000

For those following on the list, I've worked with ekr to look at the errata
that Jacob noted in his analysis as fixed by -bis, and get them transitioned
to the "Held for document update" state.

The statuses should now correctly show that -bis will fix all the accepted
errata.

-Tim

> -----Original Message-----
> From: Jacob Hoffman-Andrews <[email-masked]>
> Sent: Friday, November 30, 2018 6:38 PM
> To: Tim Hollebeek <[email-masked]>; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [lamps] Preparing the shepherd write-up for rfc6844bis
> 
owner
> name, class, [etc]"