Re: [COSE] New option going forward for COSE struct
Speaking with no hat ... My personal preference would be to deprecate counter-signatures from -struct so it can progress, and document the v2 in a separate document. I have small personal preference for deprecating the v1 counter-signature in -struct while keeping its process documented, but it's a small preference. I'm in favor of two documents, but not three. For me, I think that means either counter-signatures are consolidated into a single document, or the v1 is left in RFC 8152. As a radical opinion, maybe consider leaving the v1 mechanism behind in RFC 8152 and only discuss its deprecation in -struct. - m Matthew A. Miller On 20/08/24 10:17, Jim Schaad wrote: > At the virtual IETF meeting where had a long discussion on how the structure > document should progress without getting any type of final conclusions. > Since that time I have come up with a new option which I think should be > added to the discussion. > > 1. Have a single document with the new countersignature algorithm added. > This has the advantage that everything is in one place, it is easy to tag > the current countersignature algorithm header parameters as deprecated > because there is a new replacement in the document. > > 2. Have two documents (version 1): Fix the description of the current > countersignature algorithm in the bis document and progress that. Create a > new document which contains the new countersignature algorithm. This would > be an odd choice because I am not sure how the current countersignature > algorithm should be tagged. Not deprecating seems wrong but trying to > deprecate later also seems to be a strange thing to do. > > 3. Have two documents (version 2): Pull the current countersignature > algorithm out of the core document and allow it to progress to full standard > without a countersignature algorithm at all. Create a new document with > both the new and old countersignature algorithms tagging the old one as > deprecated. This can then be added to the STD number in the future. > > 4. Have two documents (version 3): Pull the current countersignature > algorithm out of the core document and add the new countersignature > algorithm to it. Create new document which contains the old > countersignature algorithm and publish it as historical. This is cleaner in > many respects as the deprecated version of the countersignature algorithm > would be in a document which is clearly marked as not being what is to be > used. > > 5. Have three documents: Pull the current countersignature algorithm out of > the core document and advance it to full standard. Create two new > documents, one for each of the countersignature algorithms. The old > countersignature algorithm would be published as historic and the new > document can be cycled as needed until it is ready and then added to the STD > number as a second document. > > I suggested the last option to the chairs in a private email mostly as an > option that exists but I was not really serious about it. However, in > retrospect I am starting to warmup to the way of doing things as it has > several advantages. The current structure document can progress without any > big problems. (Yes I still need to deal with Ben's discuss, but it is kind > of meta.) It also means that the two countersignature algorithms are > separated and clearly marked in the RFCs themselves as to what there > statuses are. There are no issues with having multiple documents in the > full standard so adding the countersignature v2 document later is not a > problem. > > Jim > > > ___ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > signature.asc Description: OpenPGP digital signature ___ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
Re: [COSE] New option going forward for COSE struct
-Original Message- From: Benjamin Kaduk Sent: Monday, August 24, 2020 9:43 AM To: Russ Housley Cc: Jim Schaad ; cose Subject: Re: [COSE] New option going forward for COSE struct On Mon, Aug 24, 2020 at 12:24:51PM -0400, Russ Housley wrote: > As I said on the call, I think that one document is better, even if it causes a short delay for progress of the I-D toward RFC. IIUC, the "one document" approach would lead to a more-than-short delay in STD number assignment. [JLS] I tend to agree with Ben on this. Stripping out all of the countersignature text could move the document back to the IESG by the end of September and then into the RFC Editor queue. Adding the new text means back to the IESG probably in Nov, add a new IETF last call and then, at least for me to feel comfortable about it, a one year minimum wait before moving the document up to full standard. I am not sure that I would consider 18 months at a minimum as a short delay. Jim -Ben ___ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
Re: [COSE] New option going forward for COSE struct
Jim Schaad wrote: > At the virtual IETF meeting where had a long discussion on how the structure > document should progress without getting any type of final conclusions. > Since that time I have come up with a new option which I think should be > added to the discussion. You have five choices, but I think that I there are actually two decisions: a) the base document will advance with: 1) no countersignature algorithm 2) the old(current) countersignature algorithm 3) the new countersignature algorithm b) one or two documents will be created to document and deprecrate the old algorithm, and document the new way. > 5. Have three documents: Pull the current countersignature algorithm out of > the core document and advance it to full standard. Create two new > documents, one for each of the countersignature algorithms. The old > countersignature algorithm would be published as historic and the new > document can be cycled as needed until it is ready and then added to the STD > number as a second document. This is A1, and B-with-two-documents. I am fine with that in the end. Russ Housley wrote: > As I said on the call, I think that one document is better, even if it > causes a short delay for progress of the I-D toward RFC. I estimate it will be a six month delay. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
Re: [COSE] New option going forward for COSE struct
On Mon, Aug 24, 2020 at 12:24:51PM -0400, Russ Housley wrote: > As I said on the call, I think that one document is better, even if it causes > a short delay for progress of the I-D toward RFC. IIUC, the "one document" approach would lead to a more-than-short delay in STD number assignment. -Ben ___ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
Re: [COSE] New option going forward for COSE struct
As I said on the call, I think that one document is better, even if it causes a short delay for progress of the I-D toward RFC. Russ > On Aug 24, 2020, at 12:17 PM, Jim Schaad wrote: > > At the virtual IETF meeting where had a long discussion on how the structure > document should progress without getting any type of final conclusions. > Since that time I have come up with a new option which I think should be > added to the discussion. > > 1. Have a single document with the new countersignature algorithm added. > This has the advantage that everything is in one place, it is easy to tag > the current countersignature algorithm header parameters as deprecated > because there is a new replacement in the document. > > 2. Have two documents (version 1): Fix the description of the current > countersignature algorithm in the bis document and progress that. Create a > new document which contains the new countersignature algorithm. This would > be an odd choice because I am not sure how the current countersignature > algorithm should be tagged. Not deprecating seems wrong but trying to > deprecate later also seems to be a strange thing to do. > > 3. Have two documents (version 2): Pull the current countersignature > algorithm out of the core document and allow it to progress to full standard > without a countersignature algorithm at all. Create a new document with > both the new and old countersignature algorithms tagging the old one as > deprecated. This can then be added to the STD number in the future. > > 4. Have two documents (version 3): Pull the current countersignature > algorithm out of the core document and add the new countersignature > algorithm to it. Create new document which contains the old > countersignature algorithm and publish it as historical. This is cleaner in > many respects as the deprecated version of the countersignature algorithm > would be in a document which is clearly marked as not being what is to be > used. > > 5. Have three documents: Pull the current countersignature algorithm out of > the core document and advance it to full standard. Create two new > documents, one for each of the countersignature algorithms. The old > countersignature algorithm would be published as historic and the new > document can be cycled as needed until it is ready and then added to the STD > number as a second document. > > I suggested the last option to the chairs in a private email mostly as an > option that exists but I was not really serious about it. However, in > retrospect I am starting to warmup to the way of doing things as it has > several advantages. The current structure document can progress without any > big problems. (Yes I still need to deal with Ben's discuss, but it is kind > of meta.) It also means that the two countersignature algorithms are > separated and clearly marked in the RFCs themselves as to what there > statuses are. There are no issues with having multiple documents in the > full standard so adding the countersignature v2 document later is not a > problem. > > Jim ___ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
[COSE] New option going forward for COSE struct
At the virtual IETF meeting where had a long discussion on how the structure document should progress without getting any type of final conclusions. Since that time I have come up with a new option which I think should be added to the discussion. 1. Have a single document with the new countersignature algorithm added. This has the advantage that everything is in one place, it is easy to tag the current countersignature algorithm header parameters as deprecated because there is a new replacement in the document. 2. Have two documents (version 1): Fix the description of the current countersignature algorithm in the bis document and progress that. Create a new document which contains the new countersignature algorithm. This would be an odd choice because I am not sure how the current countersignature algorithm should be tagged. Not deprecating seems wrong but trying to deprecate later also seems to be a strange thing to do. 3. Have two documents (version 2): Pull the current countersignature algorithm out of the core document and allow it to progress to full standard without a countersignature algorithm at all. Create a new document with both the new and old countersignature algorithms tagging the old one as deprecated. This can then be added to the STD number in the future. 4. Have two documents (version 3): Pull the current countersignature algorithm out of the core document and add the new countersignature algorithm to it. Create new document which contains the old countersignature algorithm and publish it as historical. This is cleaner in many respects as the deprecated version of the countersignature algorithm would be in a document which is clearly marked as not being what is to be used. 5. Have three documents: Pull the current countersignature algorithm out of the core document and advance it to full standard. Create two new documents, one for each of the countersignature algorithms. The old countersignature algorithm would be published as historic and the new document can be cycled as needed until it is ready and then added to the STD number as a second document. I suggested the last option to the chairs in a private email mostly as an option that exists but I was not really serious about it. However, in retrospect I am starting to warmup to the way of doing things as it has several advantages. The current structure document can progress without any big problems. (Yes I still need to deal with Ben's discuss, but it is kind of meta.) It also means that the two countersignature algorithms are separated and clearly marked in the RFCs themselves as to what there statuses are. There are no issues with having multiple documents in the full standard so adding the countersignature v2 document later is not a problem. Jim ___ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
