Re: [core] [Last-Call] [art] Artart last call review of draft-ietf-core-problem-details-05

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

Carsten,

Let me clarify something in a top post.  I don't think debating
you on the individual points would do either of us or the IETF
any good.

I have never been opposed to "making progress" ... either "in
this space" or on this particular document, nor have I ever
adopted anything I would describe as a "fundamentalist view".
If either were the case, I would be taking the position now that
the document has changed sufficiently that a new Last Call (on
draft-ietf-core-problem-details-07 or
draft-ietf-core-problem-details-08) was needed and that the IESG
review should restart only after it was completed.  I would
probably also be threatening to appeal if that was not done.  I
don't believe that either is necessary in this case and I have
tried to figure out ways to move things forward (including
dropping the proposal for an extension to BCP 47 when you
decided that approach wasn't necessary and dropping my
disagreement with Martin about a fairly subtle i18n issue
because I decided it didn't belong in the critical path for this
document).  

Where we may disagree (while agreeing that it should not hold up
this document) is on a subject that I hope does not get into the
critical path for this document either.  I hope we actually
agree and that my reaction exaggerates what you intended to say.
If so, what follows in a caution about slipperly slopes. 

I do think one of your comments raises an important issue for
the IESG and the IETF generally.  You wrote "I probably should
point out that I do expect people who help with reviewing
documents to have some respect for the context in which the
documents are being created."  Up to a point, I think that is
entirely reasonable.  However, and without knowing how much
context you expect reviewers to have and respect, it is easy to
imagine situations in which the only way to get an adequate
understanding of the context for a document requires
participation in the WG (not just participation in the IETF and
looking at a document from the outside). As long as we take the
position that standards track documents are the products of, and
represent consensus of, the IETF and not just that of a
particular WG, a strong requirement to understand, much less
respect, context is nearly impossible, at least without changes
to other rules.   For example, we could start to insist that
every WG produce, either as part of its charter or as a first
product, a careful explanation of its context and assumptions.
My personal view is that such a requirement would be a terrible
idea in most cases, costing a great deal of time and energy for
relatively little value.  I hope even those you identify as
"fundamentalists" would agree with that view.  But without such
requirements and clear definitions of what people are expected
to understand (and understand in the same way that you do), I
think some caution is in order about anything that would
establish qualifications for reviewers, allowing authors or WGs
to determine who is qualified to do a review (and/or what they
are allowed to so), and/or attributing motivations to reviewers
(including "opposition to making progress").

thanks,
   john



--On Thursday, June 30, 2022 00:55 +0200 Carsten Bormann
<[e-mail]> wrote:

> John,
> 
> thank you for detailing some of the misunderstandings on which
> your opposition to making progress in this space are based.
> 
> Let me quickly respond to those.
> I have already spent way more energy on this little sidetrack
> than is healthy, and clearly a better approach would have been
> to not try to make any progress at all on i18n.  But we are
> where we are.
> 
>> (1) I can't remember whether the comments went to the WG or in
>> private correspondence with Carsten, but I believe I raised
>> the "separate document" issue even before the Last Call
>> started.
> 
> That may very well be.
> I probably explained why this Appendix A is an appendix to the
> very spec that could have benefitted from addressing the
> problem better.
> 
> It would still be wrong to change this, exactly because tag 38
> is not (and needs not be) the final ultimate solution to i18n
> language and directionality indication.
> 
>> Whatever the tradeoffs are about making the split this late,
>> the issue should not be treated entirely as a late surprise
>> to the authors and the WG.
> 
> That delay would be another side effect of doing the wrong
> thing. I probably should point out that I do expect people who
> help with reviewing documents to have some respect for the
> context in which the documents are being created.
> 
>> (2) My willingness to let that go, despite the objections that
>> Harald spelled out well, were partially based on an assumption
>> derived from earlier discussions that Tag 38 and its
>> description were unlikely to set a major precedent.  I may
>> well have misunderstood.  But, in his note yesterday, Carsten
>> said 
>> 
>> 	"But I also think we now have a solid foundation for
>> 	including at least some forms of human-readable text in
>> 	future CBOR-based data formats, which should enable us
>> 	to make indications of language and directionality more
>> 	of a routine occurrence even in constrained
>> 	environments."
> 
> Yes!
> "At least some forms of…"
> "More of a routine occurrence…"
> CoRE has been built for constrained devices that usually have
> little way to make allowance for human readability of text,
> and adding a CBOR tag to the toolkit that we can use in CoRE
> for slowly changing this is a small step forward.
> 
> Again, I have pointed out a lot that I'm aware that the area
> is a construction site, and there are few good solutions that
> even apply to the constrained space for which this spec has
> been designed.  And I was happy that we were finally making it
> more likely that people would start using this.  Maybe not.
> 
>> That directly contradicts my assumption and, IMO, considerably
>> strengthens the argument for pulling that definition out into
>> a separate document no matter how much energy it takes.  
> 
> The misunderstanding here is that defining a tag for CBOR
> suddenly makes this tag the center of the universe. That's
> not the way it works, and new or updated tag definitions get
> defined all the time when there is new information or new
> requirements. Some of these registrations are in the FCFS
> space!
> 
>> That
>> view is further strengthened by the understanding that CBOR
>> and CORE are separate WGs, with separate audiences and
>> constituencies so that understandings or commitments in one do
>> not necessarily extend to the other (if that is not the case,
>> they should be [re-]combined).
> 
> Absolutely.  This is why this was done in CoRE — this
> particular tag is not fundamental CBOR infrastructure. CBOR
> has been designed with extension points that can be exercised
> by specific interest groups, and that was what was meant to
> happen here.
> 
>> (3) It is a personal opinion and matter of editorial taste,
>> but I really do not like normative appendices whose contents
>> are critical to both the present document and others.  
> 
> I'll ignore this part because there is also different
> editorial taste. I have explained why it is better to put this
> into an appendix, and giving up on that would make things
> worse. Making things worse is not the purpose of the review
> process!
> 
>> (4) If the Tag 38 definition is not to be moved to a separate
>> document and especially if it is to be retained as an
>> appendix, I think that explanatory text is mandatory,
>> especially in the light of the "solid foundation" assertion.
>> I would, personally, consider the combination of the
>> retention of the appendix model an that assertion to be a
>> showstopper in the absence of such an explanation.
> 
> The explanatory text that was proposed reads like a set of
> admonishments "do brush your teeth in the morning before
> working on this document". It describes obvious
> considerations for any document that has more than one section.
> Thomas may be ready for putting some of this in; I think this
> would only confuse people that will then try hard to
> understand why brushing your teeth is more important for this
> document than for any other. We are insulting our readers
> enough already.
> 
>> (5) I believe it is improper for the IESG to sign off on (and
>> approve publication of) a document that does not exist. […]
> 
> This should no longer be relevant to the document at hand, but
> it is a worrying development that apparently is.
> 
> I didn't join the discussion that went off track into this
> fundamentalist view of the IETF review process. Let me just
> quickly point out that the point of the review process is to
> create high quality documents. If picking up any reviewer
> suggestion leads to a process rewind, the willingness to do so
> will suffer; the review process will simply no longer be the
> exchange of knowledge based on the trust that the ultimate
> goal is to make progress. By trying to remedy the occasional
> process misstep, you are jeopardizing the Crown Jewels of the
> IETF: its strong multi-perspective review..
> 
> Of course there is a limit to the level of changes that can be
> accepted as a result of review without consulting the larger
> community, and maybe that limit needs to be adjusted
> occasionally. But this can be done in a continuous improvement
> process, and making use of human judgement for running the
> review properly (and transparently!) is the remediation
> against needing to resort to fundamentalist process blocks,
> making any change need a rewind.
> 
> The fact that you have chosen this document as a toy to
> exercise this rising fundamentalist view saddens me. I will
> not accept that my work needs to be the collateral damage here.
> Maybe ignoring that an organization is built out of people who
> do occasionally need to be afforded some respect for their
> work is just a symptom of this kind of fundamentalism.
> 
> Sorry for the off-topic, and for making it clear how I feel as
> a human about this ordeal.
> 
>> (6) Independent of what decisions are made about this
>> particular document, if we have, as you suggest, learned some
>> useful lessons in this process, it would be really helpful if
>> the IESG and/or the EMO-dir would take notice and incorporate
>> appropriate guidance into advice for other (and future) WGs
>> and authors.
> 
> There are lots of learnings here, indeed, but I'm not going
> to detail them any further here.
> 
> Grüße, Carsten