--On Friday, June 20, 2025 15:46 -0700 Watson Ladd <[email protected]> wrote:
> On Fri, Jun 20, 2025, 3:22 PM Rob Sayre <[email protected]> wrote: >> >> On Fri, Jun 20, 2025 at 3:08 PM Joel Halpern >> <[email protected]> wrote: >>> >>> It seems to me that "do not affection operational concerns" is >>> either too vague to be useful or significantly broader than most >>> of us intend. >> >> >> What's the difference? >> >> "Once published, RFCs may be reissued, but only syntactic or >> superficial changes that do not affect the syntax for protocols >> themselves may be made." >> >> or >> >> "Once published, RFCs may be reissued. Changes that do not affect >> operational concerns are acceptable." > The second I would read as much broader than the first. I would have said both broader and narrower because, at least in my vocabulary, a change could affect the definition of the specified protocol, and even prove an interoperability challenge, without creating (rather vague, as Joel pointed out) "operational concerns". And it seems to me that one could create operational concerns without changes to a narrowly defined protocol definition/ specification. > I think both > of these are IMHO way broader than we would like and too narrow; if > there's a verified erratum of "oh everyone does x but we wrote y due > to a hex/dec confusion" shouldn't that be fixable? And _that_ is a rather good example of why I continue believe to that we are trying to swim through an alligator-populated swamp here. If that occurred, there is no question in my mind that it should be fixed, so we agree that far. However, suppose, following your example, that this was a hex/dec confusion, perhaps in a key identifier of the protocol. Suppose, too, that the confusion lasted long enough that we could not _prove_ that there were no deployed implementations of the original (hex-based?) form. At that point, a change creates an interoperability problem between old and new versions, possibly a serious one. "Fixing" that by an erratum would be bad news, but at least such an erratum would presumably contain an explanation. "Fixing" it by simply reissuing the RFC with the text value changed would be nothing short of a disaster if we expected implementations of the original version and implementations of the reissued one to interoperate. I think that is an excellent example of where we'd want a new RFC, one that specified what was intended but also explained the original, erroneous spec, and probably discussed transition strategies, etc. If the hex form affected an IANA registry, we'd probably want to permanently reserve it with a pointer to that new RFC. And so on. Nothing is going to make this easy or every change something that could be covered by a simple rule or automated. Even assuming we can correctly cover all the cases by the right choice of words in a sentence or two is probably delusional. Maybe what we should do is to add more words explaining that, no matter what terms we use, there may be edge cases, that the RPC should be very suspicious of, and cautious about, anything suspicious or marginal and punt it back to the relevant stream. And the streams should be thinking in terms of community evaluation and consensus or their equivalent, not one or two overworked people doing a quick check and signing off. john -- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
