Split draft into several others?

[rikard-sics]

For instance split out:

• Key Update (KUDOS)
• Limits
• ID update parts

Based on feedback from Göran during IETF 114.

[rikard-sics]

Let us check what the feeling is about splitting out section 5 "Update of OSCORE Sender/Recipient IDs", if people are positive we move it.

[rikard-sics]

For the KUDOS/Limits splitting it's probably better to wait and see. Also considering core-wg/oscore-key-limits#1

[rikard-sics]

• Keep things as is
• Split message processing part into appendix
• Split all limit related things + message processing part into new draft

[rikard-sics]

From interim September 28: Preference seemed to be to split out the limits related sections As for splitting out the ID update Göran supported it, but others were neutral.

[rikard-sics]

Was discussed during the CoRE interim on September 28: https://datatracker.ietf.org/doc/minutes-interim-2022-core-13-202209281600/#kudos

This may be good to raise in London again, we should also decide how to deal with the new drafts. Should they be automatically adopted since they came from an adopted draft?

Opinions from the interim seem to be that splitting out the limits part is good, splitting out the ID update parts also had support but less.

[rikard-sics]

Also beneficial to split the limits out to simplify potential future updates, like due to addition of new algorithms.

[rikard-sics]

If we do the split it may also make sense to move "Current methods for Rekeying OSCORE" to after "Key Update for OSCORE (KUDOS)".

[rikard-sics]

Feedback from IETF 115 London CoRE session on Monday November 7: Consensus to split out the limits part. We will go ahead and do this.

Then consider a possible split of the part on OSCORE IDs update later on.

[rikard-sics]

Make new issue about splitting the ID update content.

[rikard-sics]

Splitting out the limits part was done in commit: b26abc1c4ad943408fe36d2a7d83877de7a08294