Mitchell-
The SHOULD type terminology is
what I thought is standard.
This is not a protocol spec. Such language is a little fuzzy in
documents that are not specs. Unless folks loudly and broadly complain
it seems to me that the language in the current document has been agreed
to.
And why wouldn't a minimum timeframe be specified? And items
listed that state how an implementation exits this experimental
phase, versus subjective evaluation. Ie, a vote of a working
group that requires xx% acceptance.
We don't vote. It happens to be part of our charm. :)
I personally don't see why we'd place a time frame on things. It seems
more important to look at the available evidence and experimental
results than to try to pick some arbitrary amount of time. Again,
unless others start yelling, I think we have consensus on this
document.
Secondly, I have never understood the non-requirment
of a REFERENCE implementation. The Reference implmentation
IMO, doesn't have to be source.
I am not sure how an "reference implementation" does not "have to be
source". But, we're talking about algorithms here. It seems clear that
these algorithms will have to be well-specified or the WG (whatever WG
that happens to be) is not going to consider the spec.
Lastly, should a accepted CC algor ever be re-reviewed
to see if it has aged well??? And needs updating.
I think that any time folks have an update they should bring it up. I
would consider that what has actually happened in practice.
4) Support for a CC algorithm in one environment, ie LFN..
I don't understand what you are getting at here. But, see guideline
(2).
Can a implimentation be offered to work in ONLY 1 environment?
See guideline (8):
As a similar concern, if the alternate congestion control
mechanism is intended only for specific environments (and not
the global Internet), the proposal should consider how this
intention is to be carried out. The community will have to
address the question of whether the scope can be enforced by
simply stating the restrictions or whether additional protocol
mechanisms are required to enforce the scoping. The answer will
necessarily depend on the change being proposed.
(Which is slightly tweaked wording from the current version in the
repository (in response to an IESG comment), but the intent is the
same.)
All implementations that I have worked on, have a stated
set of configurables with default values. If a well known accepted
implimentation is significantly modified, at what point is it
considered a new implementation. Ie: Removing fast acks in
small in-flight segment environments
I don't think I can give you a hard-and-fast rule. This is just
something the WG would have to work through.
allman
pgptTkMXp31IS.pgp
Description: PGP signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf