I have held off commenting until I saw what the IETF community at large
would have to say. Disclosure: I work for Network Appliance, was involved
in the very early stages (though not latterly) of NECP and fully support
its publication as an Informational RFC. I am also co-chair of WREC.
As has happened when this document was previously discussed by the IESG,
the discussion inevitably takes a turn towards a discussion of
"transparent" caching (latterly renamed "interception proxies" by WREC).
Let me be absolutely clear, NECP is about communication between server
load-balancers (SLB) and the back-end servers they speak to. Nothing more,
nothing less. The fact that one common use of these is for caching proxies,
and that these are used as an example, does not mean that NECP in any way
specifies how "transparent" or "redirection" takes place.
[In fact, the most common deployment of these type of service load
balancers is non-transparent (i.e. where the user configures their browser
with a proxy IP address which is, in fact, a load-balancing element talking
to a number of back-end servers). For a discussion of "transparent" versus
"non-transparent" proxies, please refer to draft-ietf-wrec-taxonomy-03.txt.]
However, that is by far not the only application. DNS, web servers and
firewall load balancing are the three other main applications for SLBs.
Now, let me address each of the original concerns in turn. Note that I have
done this privately to Keith on many occasions as well as to the IESG, IAB
and others on the WREC WG list.
At 12:41 PM 06/04/00 -0400, Keith Moore wrote:
1. The document repeatedly, and misleadingly, refers to NECP as a
standard. I do not believe this is appropriate for a document
which is not on the IETF standards track. It also refers to
some features as "mandatory" even though it's not clear what
it means for a non-standard to have mandatory features.
The document is not an IETF standard but it does describe a protocol. For
protocols to work correctly, there must be certain "mandatory" minimal
requirements on those implementing that protocol.
I can see one or two places where the word "standard" might be
misinterpreted by readers if used out of context.
Section 5.2, 5.2.1, 5.2.2, 5.5.1
"The version number of the protocol defined by this standard is 1."
"All implementations that adhere to the standard specified in
this document MUST set the version number to 0x1."
"This type of payload has no structure imposed by this standard."
"For reasons explained in Section 6.11, this standard only
defines a single performance query type that MUST be
implemented by all NECP nodes:"
I see no problem with changing these. In most cases, simply replacing the
word "standard" with the word "protocol" would convey the correct meaning
beyond any reasonable doubt.
2. A primary purpose of the NECP protocol appears to be to
facilitate the operation of so-called interception proxies.
Wrong. The primary purpose of NECP is to facilitate a load-balancing
between SLBs and the services to which they direct traffic. "so-called
interception proxies" are just one such service.
Such proxies violate the Internet Protocol in several ways:
This is not about those proxies - that is a different argument.
I don't think it is appropriate to be drawn into an argument about the
rights and wrongs of "interception proxies" when discussing NECP. I am more
than happy to justify their existence - with hard facts, of course - in a
separate thread.
Regards,
John
---------------------------------------------------------------
Network Appliance Direct / Voicemail: +31 23 567 9615
Kruisweg 799 Fax: +31 23 567 9699
NL-2132 NG Hoofddorp Main Office: +31 23 567 9600
---------------------------------------------------------------