Dave, here is a longer answer to your specific questions; I hope this
helps calibrate where I'm coming from at least:
On 2/4/2016 8:22 PM, Dave Täht wrote:
I realize now that there was a call as to what status it should be
a while. I figured silence meant there was consensus on informational,
so I was a bit surprised when it was changed. You got my attention!
I think we had discussed focusing on document quality and collecting
evaluations, test results, etc., and then when ready to publish each
algorithm, deciding what document track to go on.
For the DOCSIS one, I'm pretty sure there was never any other option
than Informational, since it was not something IETF was working on. I
think it is similar in a way to RFC 6057, and others.
so, what criteria apply for experimental vs informational vs standards
track?
For Informational vs Experimental, there is the IESG statement:
https://www.ietf.org/iesg/informational-vs-experimental.html
For the relation with the standards track, I don't know anything that
describes Experimental vs Standards Track outside of RFC 2026.
AQM's charter allows us to publish on the Standards Track. I haven't
seen very much push to do so, personally, and IMHO the standards track
is not to be taken lightly. If a lot of people say "yes, definitely,
algorithm X should be on standards track, and we're comfortable with
that", that will be convincing ... but the feedback is really light so far.
What blockers apply later, were, for example, another RFC to rely on an
experimental vs informational fq_codel rfc? For example, right now,
fq_codel is the defacto fq+aqm for homenet...
vs standards track?
I don't think there's really any distinction there. For the IESG,
Standards Track (or BCP) is definitely better to normatively reference
from other documents going onto Standards Track, since otherwise the AD
has to do explain and catalogue the "downref" for IETF Last Call.
However, this is not uncommon, or very burdensome. There is a running
list of downrefs, and once an RFC is on it, that can be referenced for
future IETF LCs:
https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry
No field data exists for docsis-pie. Most of the data on pie is from
sims. Outside of the docsis standard I know of no deployments of pie
and no hardware support for it (please, someone? is there a roadmap from
any manufacturer with pie in it?).
I don't know about this, but it sounds like a good reason why
Informational and Experimental tracks would be preferable at the moment
to Standards Track.
and conversely, since the fq-codel draft describes what has already been
done in linux, deployed in systemd, openwrt, the edgerouter products (as
what it is), as part of more than a few other products, (rebranded),
inside several major cos, and with at least one well known deployed ISP...
...
I regarded fq_codel as experimental 4 years ago. it has survived the
test of time with no substantial changes. Certainly I'd like it to be
self tuning below 2.5mbits, but pie does badly there also without tuning.
...
I believe the Experimental vs Standards Track decision on FQ-CoDel is
independent of anything to do with PIE.
As for declaring a "proposed standard", it seems as though pie's
standardization status itself has not yet been discussed on this list,
either.
I also would like to see more discussion of what people want to do with
these documents. I've tried to be clear about my own thoughts. As a
chair, my default is to NOT go standards track unless there's explicit
push from the working group.
My vote is for docis-pie, pie and fq_codel to have the same status,
whatever it winds up being. Informational seemed fine, across the board.
I'm all in favor of more deployment experience.
Understood, though I'm doubtful that our publication track will impact
deployment. I believe we need to make the proper choice for each
algorithm on its own merits, and not tie them together, personally.
However, if the working group wants to keep everything at an even status
though, please shout and tell us what that status is!
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
