Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt]

    Yes, basically. The difference in terms it is just for (I guess) to
differentiate a proxy (near the user) from a reverse-proxy (near the
server). It is "reverse" because the reference point is the user.

    I have no problem in using "proxy" alone or "reverse-proxy", just
not use something new or not very well defined as "translucent".

Regards,
as

On 25/10/2012 11:11, Brian E Carpenter wrote:
> But what is "reverse" about it? As far as I can see it's just
> a proxy that happens to be near the server rather than near
> the client.
>
> Regards
>    Brian
>
> On 25/10/2012 12:55, Arturo Servin wrote:
>> 	Although it may not be correct, "reverse-proxy" is the well known term
>> accepted by the technical community. I prefer this term (that IMHO
>> people is familiar with) rather than a new or not well known such as
>> "translucent proxy".
>>
>> 	I would suggest to add something like:
>>
>> "for example by running what is operationally known as a reverse proxy
>> [REF] that handles IPv6 customers"
>>
>> 	And add the REF to [1] for example.
>>
>> http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
>>
>> 	
>> Just my humble 20 cents.
>> /as
>>
>> On 25/10/2012 06:54, Mark Smith wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
>>>> To: Erik Nygren <erik+ietf@nygren.org>
>>>> Cc: IPv6 Operations <v6ops@ietf.org>
>>>> Sent: Thursday, 25 October 2012 6:04 PM
>>>> Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt]
>>>>
>>>> Hi Erik,
>>>>
>>>> On 24/10/2012 23:00, Erik Nygren wrote:
>>>>>  On Fri, Aug 31, 2012 at 3:14 AM, Brian E Carpenter
>>>>>  <brian.e.carpenter@gmail.com> wrote:
>>>>>>  [...]
>>>>>>
>>>>>>  Other changes were relatively minor, but there are several new points 
>>>> from
>>>>>>  Erik Nygren's extensive review (thanks, Erik!). Here are some 
>>>> detailed responses
>>>>>>  to Erik's suggestions:
>>>>>>
>>>>>>  [...]
>>>>>>
>>>>>>  We prefer to refer to RFC2616 where proxy behaviour is actually 
>>>> specified.
>>>>>>  RFC3040 is only a taxonomy document from a not-very-successful WG. (BC: 
>>>> I've also never
>>>>>>  understood the phrase "reverse proxy"; it's just a proxy 
>>>> that happens to be near the
>>>>>>  server instead of near the client, but what it actually does is the 
>>>> same. Also,
>>>>>>  "proxy" and "surrogate" mean the same thing in 
>>>> English.)
>>>>>  RFC2616 would indicate that what is labelled in the diagram in section
>>>>>  7 isn't strictly a proxy
>>>>>  (for example, proxies receive URLs in absolute form, and in many
>>>>>  typical contexts, clients
>>>>>  may be aware that they are communicating with a proxy or are
>>>>>  configured to use non-transparent
>>>>>  proxies, which is not the case here). In the common scenario that ICPs
>>>>>  are likely to deploy
>>>>>  (where the AAAA record  is handed out), the client is unaware that it
>>>>>  is talking to a surrogate/gateway
>>>>>  rather than to an origin.  A "gateway" as described in RFC2616 
>>>> might
>>>>>  be a better but less frequently used term?
>>>> I'm not convinced, because "gateway" is an even more general term 
>>>> than "proxy".
>>>> Personally, I hate the term "transparent proxy", because it's a 
>>>> lie.
>>>>  
>>> I agree, I use the term "translucent proxy" because I think it is much
>>> more accurate. If "transparent proxies" were truly transparent, it wouldn't be possible to
>>> find them in the network by comparing the output of traditional traceroute
>>> to a host with a tcptraceroute to a service residing on that same host.
>>>
>>> Regards,
>>> Mark.
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>