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

[Carsten Bormann <[e-mail]>]

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