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
Attachment:
pgp3wTzMoyWWx.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf