I want to support John Klensin here. I have always thought that the ~immutability~ of RFCs was one of their greatest strengths.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] On Wed, Jun 18, 2025 at 9:59 AM John C Klensin <[email protected]> wrote: > > Michael and Brian, > > I was prepared to let this drop, but parts of Michael's note > reinforce my concerns, shows that we are not in agreement either. > So... > > Responding first to Brian's suggestion, then some additional comments > that I hope might be helpful in thinking about the general RFC Editor > Model situation rather than necessarily belonging in any specific > document (and that some may want to just skip). > > --On Wednesday, June 18, 2025 08:25 +1200 Brian E Carpenter > <[email protected]> wrote: > > > On 18-Jun-25 08:03, Michael Richardson wrote: > >> > >> I share John's apprehension about the words "preserved to the > >> greatest extent possible". There are certainly many failures > >> possible here. I don't share John's slipery slope concern that it > >> leads to "can't trust an RFC" > > > > Nevertheless, I think this whole discussion would go away if we > > simply changed the key sentence to: > > > > "Once published, RFCs may be reissued, but the semantic content of > > publication versions shall be preserved." > > I don't know if it is good enough, but one of Michael's comments > points to a problem that applies even to this. "Semantic content" > is, itself, normally inherently fuzzy and may require subject matter > expertise to evaluate. That immediately leads, as Michael mentioned > and is discussed in more detail below, to delegation of the decision > about what is, or is not, semantic. On that basis, the suggestion > above is far better than anything involving "greatest extent > possible". But Michael's comments suggest to me that he sees a clear > dichotomy between "semantic" and "syntactic". I think that, unlike > "semantic", we have a fairly clear and shared understanding of > "syntactic", one that is free of requirements for subject matter > expertise. If there is agreement about that, then an even better > sentence would be: > > "Once published, RFCs may be reissued, but only syntactic > changes that do not affect the syntax for protocols > themselves may be changed." > > Still not perfect, but at least avoids the subject matter expertise > issues with "semantic". > > TL;DR note: What follows in response to the details of Michael's note > is essentially an explanation of the above and some information that > might be of help more generally with the RSWG/RSAB mission rather > than this particular sentence. Read it or not as you have time and > inclination. > > > --On Tuesday, June 17, 2025 16:03 -0400 Michael Richardson > <[email protected]> wrote: > > > > > I share John's apprehension about the words "preserved to the > > greatest extent possible". There are certainly many failures > > possible here. I don't share John's slipery slope concern that it > > leads to "can't trust an RFC" > > > > I think that the goal here is allow for significant syntactical > > updates to documents. That would include possibly recoding them. > > I'm for that. (Imagine if the world suddenly decided UTF-16 was > > really the right choice. Unlikely, but that's a syntactical change > > with no semantic impact). > > Really? Depends on where the change from (presumably) UTF-8 to > UTF-16 occurred. If it were a matter of re-rendering the text from > of a document to UTF-16 from UTF-8, then clearly no semantic impact. > However, even then, there are tools that work with UTF-8 and not with > UTF-16 (e.g., things that assume that X'00' octets might be > string-ending but are certainly not part of characters) and hence > such a change could have significant impact on readers or systems > trying to parse and/or analyze RFCs. And something that changed a > specification for a protocol from "MUST use UTF-8" to "MUST use > UTF-16" would certainly be a semantic change. We agree that any > such change would be extremely unlikely, but your example illustrates > why "greatest extent" is a problem. > > And I probably should have used different wording than "can't > trust..." but, if the assumption that an old version and a new one > are semantically identical and all we promise is "greatest extent > possible", then there is a potential problem. > > > We can fix the "postal" situation, etc. > > It's also to allow us to fix gramatical, spelling and dumb > > situations where we omitted the word "not" via errata. > > I think that we are generally in agreement as to goals. > > Sure. On the other hand, if the text said "MUST do foo" and the > change is to "MUST NOT do foo", that change may be appropriate as a > correction, but it _is_, without question, a semantic change and, if > such a change is made, it almost certainly needs to be explained in > text (e.g., "this used to say "MUST do", but was wrong because ... > and has been corrected) and I'm not sure that sort of thing is what > people are contemplating. > > > We could go on list things that violate the expectations. > > For instance, a bits-on-the-wire change would not be semantic > > preserving. I don't think it's a good idea. > > See above. > > > Maybe someone can come up with better text than "greatest extent > > possible" > > That was my point; I hope Brian's suggestion meets people's needs. > Or see below. > > > My view is that we should enable the RPC to do the right thing, and > > that we should trust them to: > > 1. know what is semantic and what is syntactic > > 2. know when the situation is unclear to ask the stream manager > > (e.g., IESG) 3. trust the IESG to figure it out, and consult the > > community. > > In a way, my concern is about your #1: I think there are cases -- > possibly even some extreme ones illustrated above -- in which drawing > the boundary between semantic and anything else requires substantive > technical knowledge and understanding. The RPC has, to my knowledge, > not claimed that type of expertise since before we invented the "RPC" > terminology. That is different from trusting them to understand when > they encounter a possible edge case and that they need to consult > elsewhere. But then I think there needs to be a clear understanding > (not necessarily with details in the text of this document) that > "consult elsewhere" usually involves stream managers, not just > someone's favorite expert of the day. > > > (Decades ago I heard about the ossification that occurs to > > organizations that make more and more rules to deal with concerns > > like this. They eventually can't do anything. I asked a prominent > > Cdn Sociologist[%], I know about what this is called... best he > > could come up with was "rule based culture", and he mentioned that > > there was extensive literature on this. The origin of this problem > > is lack of interpersonal trust, which fundamentally boils down to > > not drinking enough beer with others. We want to be a value-based > > culture, and that means establishing principles, not proceedures > > I am, for better or worse, fairly familiar with that literature. In > the IETF, the same cultural principles are what led, years ago and > due initially to Spencer Dawkins, to encouragement to "Do the Right > Thing" rather than writing more rules. So, without getting into the > beer-based meta-principle, yes. However, there is often another > force at play than the one you describe. That is the evolution from > (using IETF-like vocabulary) a consensus-based organization to one > that creates more and more staff structure, staffed by people with > different skill sets that are (or are supposed to be) than those of > the original organization and its decision processes. When one then > delegates decisions to those staff teams, either there needs to be a > clear understanding of boundaries, and general trust in that > understanding on both sides, or more and more rules, and rules to > patch problems that develop with earlier rules, become inevitable. > That leads to ossification (and worse) too, but the patterns are > different. > > john > > _______________________________________________ > rfc-interest mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ rfc-interest mailing list -- [email protected] To unsubscribe send an email to [email protected]
