--On Wednesday, June 29, 2022 17:48 +0100 Thomas Fossati
<tho.ietf@xxxxxxxxx> wrote:
> Hi Francesca,
>
> On Thu, Jun 16, 2022 at 2:33 PM Francesca Palombini
> <francesca.palombini=40ericsson.com@xxxxxxxxxxxxxx> wrote:
>> [...] you do suggest this document be split in two, the error
>> format and the internationalized string format. I considered
>> that too, but seeing that the CBOR tag is already registered,
>> and this document merely updates that definition and the
>> reference, I evaluated that it was ok to have it in one
>> document; moreover in this way you have both the tag and one
>> example of the tag in usage in the same doc, I think that is
>> valuable. If you think Appendix is considered less important,
>> I would not object to moving it into a main section of the
>> document.
>
> I've been silent on this thread because I don't have the
> internationalisation expertise to be able to debate with
> competence on the finer points. So I stood back while trying
> to learn a thing or two in the process :-)
>
> However, on this more procedural / editorial point I'd like to
> chime in as co-editor of the spec to say that I very much
> agree with all the points you make above about keeping the two
> things in one lump. Also, I'd be happy to move Tag38 from the
> appendix to a "proper" section if that helps increasing its
> "status", though I don't think that'd make a substantial
> difference.
>
> In hindsight, I reckon that it may have been (much) better to
> split the work and progress it in parallel with the right
> communities. This is a lesson I've learned the hard way here
> and I'm sure I have now developed the immune response that
> will allow me to identify the early signals to make sure
> similar patterns do not resurface. But we can't rewrite the
> past, so here we are at the end of a pretty messy process that
> we still managed to make work thanks to the crucial help and
> active engagement of wonderful experts, which I consider a
> success of this organisation.
>
> That said I don't think the risks that Harald and Martin see
> with bundling Tag38 and PD together WRT any future update
> process are going to hurt us (or our children's children)
> because ultimately the CBOR tag registry is the SOA here and
> the right RFC will be dispatched from there. Personally, I am
> open to the suggestion made by John to add some clarifying
> text to that purpose.
Thomas,
Since my name has been invoked (and the i18n issues aside [1]),
a few comments:
(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.
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.
(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."
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. 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).
(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. If the
appendix is not to be removed into a separate document, I
believe it should be made a normal section of the document.
FWIW, I have not, personally, seen evidence of IETF consensus
for or against separating the two documents or moving the
current appendix into the text and I do consider the issue to be
of some importance. If the main reason for not making the move
at this point is that doing so would be likely to introduce
errors (an argument that carries a lot of weight with me), I
would hope that the IESG would carefully consider the question
of how much Harald's Last Call review position constituted a
late surprise.
(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.
(5) I believe it is improper for the IESG to sign off on (and
approve publication of) a document that does not exist. that is
substantively different fro the version that went into Last
Call, and that the community has not had time to even check, so,
if either the content of the appendix is to be moved into the
body of the text or that paragraph is to be added (or both),
draft-ietf-core-problem-details-08 should be posted and,
consistent with Francesca's note, at least a few days should be
allowed for the community and the WG to check it before the IESG
formally signs off and issues a Protocol Action notice. I'd
feel differently if the changes were only small ones with
editorial impact only, but one of those changes would involve a
significant rearrangement of text that is referenced from
several places in the document and the other would involve
completely new text.
(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.
> Cheers and thanks all for pushing me up this steep but
> enjoyable learning curve.
Thanks for taking this process in good humor. I understand the
stresses and the steepness of the curve and very much appreciate
that.
best,
john
p.s., since I'm guilty of suggesting the explanatory paragraph,
I'd be willing to work with you, Carsten, or others on getting a
draft version together if that would help.
[1] Martin and I still do not completely agree but I do not
believe the differences need to affect this document. The
discussion should continue elsewhere at a different time and
when more of those involved and with the requisite expertise
have the energy. However and again relative to the "strong
foundation", the CORE and CBOR WGs should not more forward on
the assumption that what goes into this document is the last
word on the subject and be surprised if questions are raised
when attempts are made to apply the document's conclusions in
other contexts.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
