[Rswg] gating factor(s) for when we publish format changes as an RFC

[Alexis Rossi <[e-mail]>]

I would like to refocus the conversation around documenting our current v3 vocabulary. Can we pull back a little and 

I think these things are true:

1. The format of the archival series must be documented as part of the archival series

We have already published RFCs using this bespoke v3 format - that is a done deal - and these are archival documents that we want others to understand decades from now. 

RFC 7991 was a best guess at how the format would work in reality, but in practice we have made changes. We have published RFCs that do not follow 7991. Someone reading these RFCs in the future should not need to guess what we meant. Transitory resources like github or authors.ietf.org are insufficient as long term documentation.

For archival integrity of the series, at some point we need to document the format of these published RFCs in an archival document (ie an RFC).


2. The format and how it is used will continue to evolve over time

We’re never going to be “done” with making changes to the format. Those changes will eventually need to be documented and published in an RFC. We need to understand the gating factor(s) for when the updated RFCs should be published.

Is it based on backwards compatibility? Is it a time-based commitment (e.g. “every 2 years we will publish a new RFC that updates the format documentation")? Something else?


3. There should be clear path(s) for how the format evolves

When a new issue comes up that seems to warrant a format decision, interpretation, or change, we rely on RPC (who might consult RPAT), RSAB, and RSWG depending on the situation, as described in RFC 9280. Are there issues with those paths?

Regarding the concern that v3 changes did not go through a proper process to get community consensus, I think that is a “going forward” issue. Since we have already published RFCs using the changes, they have to be documented regardless of whether they went through the right channels. Maybe the resulting RFC should specify that the changes didn’t have consensus, but they need to be documented in the archive regardless.


4. There should be an evolving resource that describes the format as it is used today

There should be a resource for Readers, Authors and Editors that tells them what the current accepted usage is for the format. That might be “see this RFC plus these changes that are not in an RFC yet” or something else. But since we currently do not issue a new RFC every time we make a decision, those decisions need to live somewhere until the next RFC is written. 

It sounds like that is currently in github, although someone not in this conversation might think it is at authors.ietf.org. All of our sources/information should probably agree where this lives. 

Future RFCs that document the format should probably acknowledge that the RFC itself is only accurate as of a certain time, and let readers know where changes can be found until the next RFC is issued. 


I think the question of when we publish https://datatracker.ietf.org/doc/draft-irse-draft-irse-xml2rfcv3-implemented/ or  similar as an RFC is centered mostly on point 2 above. What are the gating factors for when we publish format changes as an RFC?

Thanks,
Alexis