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

[tom petch <[e-mail]>]

From: art <[e-mail]> on behalf of Martin J. Dürst <[e-mail]>
Sent: 05 July 2022 09:09
To: Carsten Bormann; Francesca Palombini
Cc: Thomas Fossati; [e-mail] WG; Applications and Real-Time Area Discussion; [e-mail]; [e-mail]
Subject: Re: [art] [core] [Last-Call] Artart last call review of draft-ietf-core-problem-details-05

<tp>
In answer to Martin's question with a trimmed list

Hello Francesca, Carsten, others,

On 2022-07-05 02:00, Carsten Bormann wrote:
> Hi Francesca,
>
> On 2022-07-04, at 18:06, Francesca Palombini <francesca.palombini=[e-mail]> wrote:
>>
<snip>

Looking at the RFCs, it's not that RFC 8949 updated RFC 7049. RFC 8949
*obsoleted* RFC 7049. The IANA registry for CBOR Tags now points at an
obsoleted document.

I hope I'm not alone in thinking that this is an unacceptable situation.
My understanding of *obsolete* is that the whole of the document is no
longer relevant. I think that's in line with the general understanding
of the word "obsolete".

If somebody has a pointer to an official IETF definition of "obsoletes"
that differs from this general understanding, I'd appreciate it.

<tp>

Martin

No I do not but see it come up regularly in WG and with ADs.

There might be an IESG statement but is not.

There might be something in the RFC Editor Style Guide but is not.

What there is is a definition in SMIv2 (RFC2578 s.6.1) which has been inherited by YANG (RFC7950 s.7.21.2) so that is where I point people.

More generally, I think that the problem arises when authors include material with different life cycles in the one document.  I see that now with YANG where the one document contains:
- the initial version of an IANA-maintained module, never to be updated, never to be obsoleted
- a protocol module which will evolve over time with the protocol and with experience.

When it is time to update the protocol module, the IANA-maintained module must not be reissued so the original document must be torn apart and now part of the original document is obsolete, part is not; there is no good way to handle this.  What the benefits are to the author of putting disparate material in one I-D I know now, but I see the cost to the IETF.  This is not peculiar to YANG but could apply to other situations involving IANA.

I realise that the discussion about this I-D being divided or not is resolved but did think during it that keeping the document as one might be storing up such problems in the future.

Tom Petch

> Yes, we discussed this quite a bit as a WG.)

If you discussed leaving dangling references to obsolete documents in
the IANA registry, and came to the conclusion above, I think the IESG or
IANA or somebody else should clearly have stopped you.

You don't free memory that still has active pointers to it, and you
don't obsolete a document that still has active pointers to it.


> I don’t think this document *can* prevent us from at some point deciding we want to stop updating Tag 38 and address its use cases by something shiny and new — even if this seems a bit far-fetched now.  It certainly shouldn’t try to.

I don't think that's the issue at hand. CBOR has all the mechanisms to
define some new kind of Tag for human language strings if that's seen as
a good idea.

There are two other things we have to worry more:

1) Even if a new, better idea comes along, we can't obsolete the
definition of Tag 38 because there's still data out there with Tag 38.

2) If core-problems needs to be updated, and it's done in the way CBOR
was "updated" in RFC 8949, leaving a dangling reference from the IANA
CBOR Tag registry to an *obsoleted* first version of core-problems, then
we easily might get into the following situation:
- CBOR "user" to I18N expert: What would you use for
   human language strings in CBOR?
- I18N expert to CBOR user: Go for Tag 38, that will do it.
- CBOR "user" to I18N expert: That's in RFC XXXX, so it's obsolete.
- I18N expert to CBOR user: Well, actually not.
- CBOR "user" to I18N expert: Should I believe you or the RFC editor?

It often takes quite some time and effort to talk people into doing the
right thing for I18N. We don't want this to be more difficult and
tedious than necessary because of references to *obsolete* documents.


> So half of this addition isn’t needed, and the other half isn’t quite the right recommendation about the evolution of this document.

My conclusion now is that while the specific language may benefit from
some tweaking, some strong statements are clearly needed because some
people indeed don't know how to brush their teeth (or manage references
to documents).

Regards,    Martin.

_______________________________________________
art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/art