Re: [I18ndir] I-D on filesystem I18N

[John C Klensin <[e-mail]>]

Nico,

We are not communicating very well or at all.   It might be my
fault, so, after this note (which I hope will help), I'm going
to withdraw from the conversation for at least a few days.

--On Tuesday, July 7, 2020 16:45 -0500 Nico Williams
<[e-mail]> wrote:

> On Tue, Jul 07, 2020 at 05:13:22PM -0400, John C Klensin wrote:
>> What I'm concerned about -- and what caused that question
>> about priorities -- is, at an even higher level, the sort of
>> issue covered by the note I just sent in response to
>> Patrik's.  With one qualification below (which I predict you
>> won't like), if the IESG (via IETF LC), a WG, an AD, or maybe
>> an individual author who is proposing an update in line with
>> documents that have already achieved IETF consensus requests
>> a review _from the directorate_, and Pete assigns that review
>> to someone and they do it, then that is great.  
>> 
>> The qualification is that, if the review was requested from
>> the directorate about a document that has been written
>> consistent with established IETF consensus documents _and_
>> that does not reopen or contradict the questions that were
>> presumed to be settled by that consensus, then that review
>> ought to respond to the i18n issues raised by the document
>> and suggest issues with them, not say "well, the whole
>> concept of which the spec under review is a {proposed) part
>> is broken and I have a better idea". Should the latter occur,
>> I believe that, if we are really functioning as a
>> directorate, a second reviewer should immediately be
>> recruited and assigned to provide the review that was
>> requested.
> 
> Yours is an argument for stare decisis.  Once wrong, always
> wrong.  As if consensus, once found, can never change.

No it isn't.  I've been arguing against positions like that, I
think consistently, for many years, including in a recent appeal
to the IESG.  I am, first, trying to make a distinction between
a review request to a directorate with expertise in particular
mechanisms and a more general review request or spontaneous
review.  If you had written exactly the same notes  (to the
authjor or to the WG list) because you were following the WG's
work and felt a desire to speak up, I think that would have been
perfectly reasonable.  For a directorate (as compared to a
review team or some other arrangements) review, I think there is
an assumption that, at least at a high level that other experts
would agree with you.  Perhaps they do, perhaps they don't, but
I don't think it is appropriate for you to use a
directorate-assigned review to push your particular ideas about
a replacement protocol approach .

I also think that a certain amount of respect is due to
established protocols that have gotten IETF consensus and broad
deployment.  That does not mean they can't be changed.  It does
not mean they are not wrong-headed either.  But it seems to me
that "I have an idea that I think is better" is not sufficient
to cause a reset to zero, treating the new idea as inherently at
least as valid as the older, established, one on an equal
comparison basis or as inherently better.  If nothing else, long
experience with trying to get people to discard something they
think works (or at least are used to) in favor of something new
should set a relatively high bar because, from a pragmatic
engineering standpoint, replacement protocols or models that
cannot be deployed are fairly useless except as learning
exercises associated with how to think about problems.  Because
this is an i18n effort, I think we have a worked example of what
I'd consider the right way (or at least a right way) to approach
a situation in which an established protocol needs changing or
replacement.  One starts with a careful analysis of what is
wrong with the old one, not just an assertion that it is broken
or that one has a better idea.  One seeks consensus about that
analysis of difficulties (see RFC 4690 as an example).  Then one
sorts out new/revised protocols (in a WG if there is any
controversy at all) that address those deficiencies and any
others that can be identified.

Now, if you think there is going to be sufficient support for
your proposal, by all means ask for a BOF.  Or ask for a mailing
list and use it to demonstrate sufficient interest and
commitment that you can go to the ADs and persuade them to get a
WG going without a BOF.  I just object to your using the
directorate as a substitute for that when the directorate has
other work to do.   And, if you think the right solution to
getting your draft (and maybe other things) the attention they
deserve, by all means go for it.  I'd expect the issue of our
not being able to get sufficient energy and commitment to move
i18n-related WGs forward to be raised (as evidenced by EAI and
PRECIS being clearly completely out of energy by the time their
work wound down) but perhaps you have a good theory as to why
the effort you are contemplating is different.

> I reject that argument, at least as to our documents.

Ok.  But the argument you are rejecting is, AFAICT, a complete
strawman... certainly nothing I was advocating.

> It seems, too, like you're conceding that our approach to
> NFSv4 I18N was wrong, but you want to keep that old concensus
> untouched.  Of course, I welcome your concession even as I
> reject your argument that we must never revisit consensus
> findings.

Someday I will tell you how I feel about NFS, how long I have
felt that way, and what I think of the additions, revisions, and
patches to it... and why.  But, from that point of view, the
situation is not a lot different from what it was when RFC 1094
was published in 1989: The thing is out there, it is widely used
and widely deployed and someone who wants to replace it with a
different model quite appropriately needs to explain not only
why their model is better but it is enough better that there is
a reasonable expectation that it will be adopted.

>...

Enough.  I need some sleep and a break from this discussion.

    john