--On Friday, June 24, 2022 17:14 +0200 Carsten Bormann
<cabo@xxxxxxx> wrote:
> On 2022-06-24, at 16:53, John C Klensin <john-ietf@xxxxxxx>
> wrote:
>>
>> FWIW, strongly agree on both points, especially the first.
>
> And, as I have said, I strongly disagree that there is any
> problem here at all — we already have the processes to
> handle upgrades.
Carsten,
Unfortunately, we also have many years of painful experiences
trying to sort out the details of the meaning of one document
replacing ("obsoleting") or even updating another and what that
means for references that still point to the original one. If
you are referring to the normal IETF/RFC "processes to handle
upgrades", that experience, reinforced by some recent
discussions about kinds of updates, is evidence that those
processes don't work very well. If you had some processes
specific to CORE or CBOR in mind, I couldn't find a normative
reference in the document. Separating the two sets of
definitions just makes any evolution much more clear and easy to
handle without having to deal with those problems.
You could, of course, turn that around and say "well, we have
been dealing with that sort of mess for years, what difference
will one more case make?", but I, at least, don't find that very
persuasive.
Editorially, putting essential normative definitions into an
Appendix aggravates the problem: the normal definition of
"Appendix" is about supplemental, rather than
normative-essential, material. In that context, replacing the
body of a document without bothering to copy the appendices over
or discuss them makes perfect sense, but it is exactly what you
presumably would not want here. It does look from this draft
as if the same thing was done in RFC 8610 (a quick glance at the
latter seems to confirm that). My reaction to that is, more or
less, "shame on the RFC Editor process but let's not use it as a
precedent". You probably disagree.
Not speaking for Harald but, if you want to (and can) persuade
the IESG that there is rough consensus in the WG and the
community for leaving the two together, I think the document
would be strengthened by a brief paragraph about possible
updates, pointing out that Tag 38 and the rest of the spec might
be altered separately and urging that any updating documents be
clear about what is being altered (and what is not) and that any
replacement document either copy everything or split things up.
That might include an explicit warning against leaving parts of
this spec as normative while replacing other parts. If you are
correct that it is not likely to be a problem, than such a
paragraph is cheap. If you are not, then it would be quite
helpful in flagging the issue so that future documents do not
create the ambiguous mess that I (and I presume Harald) fear.
john
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
