Mikael Abrahamsson <[email protected]> wrote: > > The first thing that came to my mind, is that recommending RED is > something I would like to stop doing, instead I would like to recommend > something else. What this means in terms of status of 2309, I have no > idea.
There are several different ways to accomplish this, but basically, _any_ BCP we publish will trump that recommendation of 2309. I merely am recommending that we state our intent clearly. > For instance 7141 updates 2309, if we obsoleted 2309, what would that mean > to 7141? Although I'm pretty familiar with 7141, I wanted to re-read it before responding. It's not an easy read, at 41 pages, largely in academic-paper style. (In fact, this reading did nothing to change my answer, but I'm cautious about such things.) 7141 is tolerably clear about what portion of 2309 it "updates" and it lists 2309 in its Normative References. As phrased, Mikael's question asks what would be different if AQM-REC _obsoletes_ rather than _updates_ 2309 -- with respect to interpretation of 7141 itself. The answer to that question is: most likely no difference at all. A Normative Reference, by definition, is something which must be read to understand the RFC referencing it. This need-to-read survives any future classification of the referenced RFC to obsolete or historic. There's a separate question (not asked) of what it would mean if AQM both obsoleted 2309 and listed it as a Normative reference. This is not fully-settled: I believe the RFC Editor tries to avoid such cases. > My thinking here was that people perhaps could stop implementing RED when > they do new products, so in 2020 an implementor feels no need to implement > RED-functionality, but instead only implements whatever we come up with > here. By doing a BCP, I think we would achieve that? Actually, IMHO, we'd achieve that even if we never mentioned 2309 at all. But it is clearly easier for future implementors if we state that intent clearly in AQM-REC, regardless of metadata about "update", "obsolete", or "historic", which are after all merely aids to readers: not part of the RFCs themselves. -- John Leslie <[email protected]> _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
