[procon] Re: downref registry --- who, what, and how much?

[Brian E Carpenter <[e-mail]>]

On 29-Nov-25 10:57, Michael Richardson wrote:
> 
> The restriction:
>      " Standards track specifications normally must not depend on other
>        standards track specifications which are at a lower maturity level
>        or on non standards track specifications other than referenced
>        specifications from other standards bodies."
> 
> is from RFC2026, 

I assume the next word should be 'but' rather than 'not'...

> not 2026bis-01 does not roll up RFC3897 or RFC8067 in.

You mean RFC3967, I hope.

> The word downref is not in 2026 (not surprising since they were not permitted
> at all before). 

Well, I think the 'normally' did in fact permit them.

> I think that at least 2026bis needs to reference 8067 and
> 3897 in section 6?

Yes, and also in section 9.2.

> RFC3897 and RFC8067 establish the downref process.
> I guess because 8067 has not sunk in for me, I still think of downrefs as an
> expensive (in brain power) and tedious thing that should be avoided.
> Maybe that's not the case anymore, but then I also wonder if the restriction
> is still meaningful.

I think it is, because in reality a downref promotes the target
to the standards track. So it's a bit more than box-ticking.

> 
> I also think that section 6.2.1 on Experimental is not consistent with
> draft-bonica-gendispatch-exp.  I realize that document has no standing as yet.
> I think we need "Experimental" and differently "Experiment" :-)
> I also think that section 6.2.3 is wrong, given the ISE process.
> I wonder if Historical should be part of the Standards "Track".. cycle of life.

I'd go a bit further. We should consider whether the whole of
subsection 6.2 belongs in this document at all, rather than in the
RFC Editorial stream. So in 2026bis we'd end up with something
like this as the whole subsection:

- - - - - - - -

6.2. Non-Standards Track Maturity Levels

Not every specification is on the standards track. A specification may not be intended to be an Internet Standard, or it may be intended for eventual standardization but not yet ready to enter the standards track. A specification may have been superseded by a more recent Internet Standard, or have otherwise fallen into disuse or disfavor.

Specifications that are not on the standards track are labeled with one of three "off-track" maturity levels: "Experimental", "Informational", or "Historic" {{RFC7841}}. The documents bearing these labels are not Internet Standards in any sense. If they are published in the IETF stream {{RFC7841}}, IETF Consensus is required {{!RFC8789}}.

- - - - - - - -

This takes away the concern that Experimental is badly defined;
if we make that out of scope it becomes someone else's problem.

BTW, there's a gap in RFC 8789: it doesn't mention moving an
IETF stream document to "Historic."I've submitted an erratum:
https://www.rfc-editor.org/errata/rfc8789

    Brian