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 <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/cose
