mirjak / draft-kuehlewind-update-tag Goto Github PK

There seems to be broad consensus by the stream managers that this change should apply to all stream. If finally agreed this must be reflected in the document. There is also a questions is RFC could be amended/extended cross-stream.

I guess the IESG...?

Currently this document is intended for BCP. However, there were some indications that this should be run as a revertible experiment first. The design for a proper experiment needs more work. To start, I think there are the following options (order from less inversive to most inversive):

1. Only use the new tags for drafts but not for final published RFC. This would mean we would replace this new tags with the old "updates" tag before publication. This would give us some experience with the use of these new tags without changing anything in the actual RFC series. (I personally would not want to go for this option because it looks like a lot of work without any benefit and therefore may increase the risk of failure)

2. Only add the new tags as meta data but not as a canonical part of the published RFC (note that "updated by" is meta data anyway as it gets added to an existing unalterable RFC). This option would need further consideration, also regarding tooling, as it is not clear if we have such a feature currently. Further I think still having the "updates" tag as canonical part of the RFC while the new tag are "only" meta data might be confusing. Also it is not clear to me what we would do if the experiment succeeds. Would we then publish new RFC with the new tags (and obsolete updates) or keep these tags forever in meta data only...? But maybe that last question is to decide later.

3. Publish RFCs with both the old "updates" tag as well as the new tags for the time of the experiment. This would means we cannot remove the new tags if the experiment fails but we would have a continuous use of the "updates" tag.

4. Use only the new tags during the experiment and revert to "updates" if the experiment fails. I think this is still a good option because the important part is that there is a forwarding reference from the old RFC to a new one. Which word we exactly use to provide this reference is secondary. And we have other examples in the history were the format and style of RFC changed. I cannot believe that would add more confusion to where we already are but of course that just my personal guess and I understand if people want to be more conservative here.

Did I forgot something?

There was some discussion to what for the new RFC editor model to be implemented and publish this document on the new RFC series stream. The option is to publish with IETF consensus for the IETF stream. Of course we could also coordinate with the other stream and see if they are interested in this change as well.

I think if we actually run this as an experiment we should do it now for the IETF stream, such that we have the needed experience later and can then publish a BCP on the new RFC series stream.

e.g. optional extensions typically are use of options or optional flags. What's about a new version of a protocol?

This draft proposed to use three new tags to replace the "updates" tag. However, there having been various other proposals basically to use any other number of tags:

0. No tag at all; just remove "updates".
   1.1) Keep "updates" and clarify that there is no clear definition -> This was tried by the IESG with an IESG statement but the community feedback was clear that this option is not preferred.
   1.2) Keep "updates" and provide a clear definition (I guess either limit it to one use case, e.g. the amends case, or keep all use cases in scope but write this down)
   1.3) Rename the tag and provide a clear definition (probably, this would be "amends")
1. Only have "amends" and "extends" but not "see also"
2. three tags as proposed in the current draft

As an author of this individual draft, I'm happy to discuss if "see also" is needed or not. I noted that the definition of "see also" is not entirely clear and maybe there is also an option for a better word (also we didn't really came up with one). I opened a separate issue for that, see #15.

However, for people that would prefer any of the other options, I think they should propose an own draft, as I personally don't believe those options would address the problem adequately and therefore as an author would not be able to stand behind that.

Is there any point in trying to merge in (some of) the content of the abandoned draft-roach-bis-document?

I personally think that "see also" is valuable for the following reasons:

1. If we don't have it, use of "extends" risks to be more blurred.
2. "See also" provide a reference from an existing RFC to a new RFC. As such the intention is to consider if the new RFC is a valuable read for a reader of the old RFC. This is very different from references in the new RFC, because a reference means that this RFC is an interested or require read for a reader of the new RFC.

Those points should probably be clarified in the draft.

If there is another term we can use instead of "see also" that would make this clearer, I'd be very happy about it. But at least I wasn't able to come up with one.