Re: Follow-up on IESG Comment #6

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

> The suggested change to section 2.1 of epp-07 was to change this line:
> 
> - The transport mapping MUST manage congestion.
> 
> to:
> 
> - The transport mapping MUST only be to an IETF standards
> track congestion control protocol such as TCP or SCTP, or to
> a protocol which uses one of these.

Well, that's sort of an improvement, since now I won't have attempt to make
the case that EPP/SMTP/TCP (or EPP/HTTP/TCP) doesn't need an explicit form
of congestion control, as that exists in the lower layer ...


BUT

I can't think of a reason why EPP/SMTP/UUCP isn't just as useful (if not
more useful) than EPP/SMTP/TCP. But then UUCP isn't an IETF standards
track congestion control protocol. UUCP isn't an IETF standard at all.

What are we trying to do here? Prevent an EPP/FOO draft from publication
(in any of experimental, informational, best practices, standard niches),
or require that interoperable EPP implementations are capable of using
congestion control in the presence (or possibility) of congestive collapse?

If the former, I'm not interested. It isn't a technical issue.

If the latter, I'm interested. It is both a technical (how to) issue, and
a operational best-practices (when to) issue.

I'm not too keen on the prescriptive presumption. This may be an aesthetic
issue, or my personal skepticism about practice and theory.

So, my two beads worth of wampum is:

The transport mapping MUST provide a mechanism to detect congestion,
and to apply standards track congestion control, e.g., TCP or SCTP,
when congestion is detected.

It is the ABSURDLY STRONG RECOMMENDATION that the EPP implementations
attempt to detect congestion, and when congestion is present, that the
TCP transport mapping, or the SCTP transport mapping, if available, is
used.

Well, a diaper calls.
Eric