Subject: [COSE] Shepherd questions about countersign

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Mar 2021 17:38:38 -0500

Should draft-ietf-cose-countersign-02 be marked as Updates: RFC8152 (Amends).

I guess the IPR declation will require an AD override.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 7 Mar 2021 13:47:33 -0800

> Should draft-ietf-cose-countersign-02 be marked as Updates: RFC8152 (Amends).

Just to confirm: you are specifially asking about 8152, not 8152bis?

> I guess the IPR declation will require an AD override.

That should be doable.

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Mon, 08 Mar 2021 13:44:27 -0500

> Just to confirm: you are specifially asking about 8152, not 8152bis?

Yes.
I think that both 8152bis documents Obsolete: RFC8152, and this document also
continues/replaces 8152, so I think that there should be a link of some kind.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 8 Mar 2021 15:21:19 -0800

> continues/replaces 8152, so I think that there should be a link of some kind.

Having a link of some kind sounds good.  I think that, just as you argue
here for an "Updates: 8152", one might also argue that "Updates:
8152bis-struct" is appropriate, since we are filling a void that was
deliberately left in -struct.  I do not claim to say that one is clearly
preferred over the other.

-Ben

---

From: Matthew Miller <[email-masked]>
Date: Mon, 8 Mar 2021 16:52:04 -0700

(with no hat)

At the least -countersign should have "Updates: rfc8152bis-struct",
since this document fills the void left by deprecating the original
countersignature scheme.  I have no objections to also have "Updates:
8152".

- m&m
Matthew A. Miller

On Mon, Mar 8, 2021 at 4:21 PM Benjamin Kaduk <[email-masked]> wrote:
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Michael Richardson <[email-masked]>
Date: Tue, 09 Mar 2021 10:02:55 -0500

Benjamin Kaduk <[email-masked]> wrote:
    >> Benjamin Kaduk <[email-masked]> wrote: > On Fri, Mar 05, 2021 at
    >> 05:38:38PM -0500, Michael Richardson wrote:
    >> >>
    >> Yes.  I think that both 8152bis documents Obsolete: RFC8152, and this
    >> document also continues/replaces 8152, so I think that there should be
    >> a link of some kind.

    > Having a link of some kind sounds good.  I think that, just as you
    > argue here for an "Updates: 8152", one might also argue that "Updates:
    > deliberately left in -struct.  I do not claim to say that one is
    > clearly preferred over the other.

Oh, I see.
I agree that it could say Updates: 8152bis-struct as well.

---

From: Russ Housley <[email-masked]>
Date: Wed, 10 Mar 2021 12:46:51 -0500

That makes sense, but I do not think we need to wait for rfc8152bis-struct to get an RFC number so that we can add it to the upper left corner of the title page.

Russ

> On Mar 8, 2021, at 6:52 PM, Matthew Miller <[email-masked]> wrote:
> 
> (with no hat)
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Mar 2021 18:13:48 -0500

Russ Housley <[email-masked]> wrote:
    > That makes sense, but I do not think we need to wait for
    > rfc8152bis-struct to get an RFC number so that we can add it to the
    > upper left corner of the title page.

I assumed that the document would wind up in a cluster anyway :-)
Perhaps it's weird to update a document which we are still processing. Hmm.

Anyway, the shepherd template asked this question, so I was forced to think
about this.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Mar 2021 18:16:37 -0500

And as a further followup, I-D.ietf-cose-countersign is already mentioned
several times in rfc8152bis-struct, and is an informative reference.

As an informative reference, it won't prevent rfc8152bis-struct from
waiting on countersign, but actually I rather think we should reference the
new RFC#.  But, it shouldn't be a normative reference.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 10 Mar 2021 15:27:48 -0800

> new RFC#.  But, it shouldn't be a normative reference.

If I'm reading correctly, https://www.rfc-editor.org/current_queue.php
shows that -algs and -hash-algs have had their copyediting pass and are
waiting to enter the RFC-EDITOR state along with -struct, while -struct is
in the EDIT state (and has been for 5 weeks).  With the average time in
EDIT being about 6 weeks, the cluster C416 should be able to progress
fairly quickly.

It's a supported operation to ask the RFC Editor to add a new document
(-countersign) to the existing cluster if we want to do that, but I do not
think we could use the Updates: mechanism to do that and would instead want
to make -countersign a normative reference from -struct.  That, in turn, is
dicey from the downref perspective and might require another IETF LC.

To me, that suggests not adding -countersign to the cluster and sticking
with Updates, but I'd like to hear from others before taking any action
here.

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Mar 2021 22:03:39 -0500

Benjamin Kaduk <[email-masked]> wrote:
    >> And as a further followup, I-D.ietf-cose-countersign is already
    >> mentioned several times in rfc8152bis-struct, and is an informative
    >> reference.
    >>
    >> waiting on countersign, but actually I rather think we should
    >> reference the new RFC#.  But, it shouldn't be a normative reference.

    > waiting to enter the RFC-EDITOR state along with -struct, while -struct
    > is in the EDIT state (and has been for 5 weeks).  With the average time
    > in EDIT being about 6 weeks, the cluster C416 should be able to
    > progress fairly quickly.

Yeah, I noticed that later today too.
I thought the 8152bis were still in the IESG :-)

    > To me, that suggests not adding -countersign to the cluster and
    > sticking with Updates, but I'd like to hear from others before taking
    > any action here.

I agree with just adding the two Updates: to countersign.