Re: TCP Mapping

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

Hong,

I'm sure Scott will be gratified.

Some observations:

	o NeuStar's rtk packages may need only minor or no modification to
	  skip the tcp header length error check, and not discard a message
	  which appears to be corrupted,

	o Liberty's rtk package's also may be easily modified to skip the
	  same apparent error condition,

	o It is unlikely that ordinary interoperability testing would ever
	  initiate a transfer of size 2^^24 bits, as you observed in your
	  initial note, and discover an unexpected return value,

	o I expect that the NeuStar's rtk packages can be modified to
	  reduce the probability of triggering a "large" return, exceeding
	  the 2^^24 bit size limit (or 2^^31 for that matter), quite possibly
	  it can't support large messages anyway,

	o I expect that ICANN could be pursuaded that "very large" queries
	  (made by non-NeuStar rtks, should any be used to connect to the
	  NeuStar registry, lacking the above "throttling limit"), are not
	  good policy, and so may be truncated (or discarded) at the whim
	  of the registry (or near 2^^24 bits).

In short, if you were willing to create an exception to the eventual status
docs this WG may produce, and simply require that length-based error check
not be used when clients connect your server, no one would ever have known
that NeuStar is using one or more low-probability-of-use bits in the tcp
header.


It used to be necessary to turn off udp checksums to run nfs (version 2) on
any kind of network. Turning off length-based error checking when connecting
to the NeuStar registry would be no stranger to experienced operators. It is
hard to distinguish from turning off parser validation.

I look forward to a draft.

Eric