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.


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

Reply via email to