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
<brian.e.carpen...@gmail.com> 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
<mcr+i...@sandelman.ca> 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
--
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org
