On Fri, Jan 26, 2024, at 12:32, Joel Halpern wrote: > Your draft, as I read it, calls for removing the notion of draft > expiry. If you want to move the marking for expiry to the datatracker > and associated metadata, that would not be a "no-expiry" It would be a > "move-expiry" request. If that is what you want, then write that. In a move, you have an origin and a destination. This is the origin part of that move only. A draft, which might become RFC, only needs to do the origin part. This one goes further, based on feedback from the design team, and has some non-normative text that suggests how the datatracker (as the destination for that move) might accept the responsibility for expiration or what-have-you. This doesn't need to be documented in an RFC, because it is then a policy that can be managed through the datatracker change management processes. The draft includes some suggestions to highlight that there are a range of options available, because people were concerned that we hadn't paid sufficient attention to the receiving end.
