Subject: [core] coap #72 (new): Proxy versus Gateway

From: "core issue tracker" <[email-masked]>
Date: Sun, 21 Nov 2010 21:12:31 -0000

#72: Proxy versus Gateway

 The current terminology used in the draft about intermediary nodes doesn't
 differentiate between proxies and gateways. ([http://www.ietf.org/mail-
 archive/web/core/current/msg00862.html Proxy versus Gateway])

-- 
----------------------------+-----------------------------------------------
 Reporter:  hartke@…        |       Owner:  zach@…            
     Type:  task            |      Status:  new               
 Priority:  minor           |   Milestone:                    
Component:  coap            |     Version:                    
 Severity:  -               |    Keywords:                    
----------------------------+-----------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/72>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Tue, 23 Nov 2010 08:57:51 -0000

Changes (by zach@…):

  * owner:  zach@… => brian@…
  * type:  task => enhancement

Comment:

 A summary of the suggested terminology from Klaus and Peter:

 * Intermediary CoAP end-points act as both a client and a server in
 order to forward, with possible translation, requests and responses.

 * A proxy is an intermediary selected by a client. A client can
 delegate all CoAP requests it can't do itself to a proxy.
 Configuration of this proxy for a particular node is an administrative
 function outside the scope of CoAP.

 * A gateway (a.k.a., reverse proxy, big brother, ...) is an
 intermediary imposed by the origin server to support sleeping nodes or
 perform any other role that might be hidden behind the authority part
 of a URI. The origin server may be unaware of the presence of a gateway.
 The network may impose the gateway.

 * Caching in turn is a function that may be paired with a proxy or
 with a gateway, but is not inherently coupled to either one.

-- 
----------------------------+-----------------------------------------------
 Reporter:  hartke@…        |       Owner:  brian@…             
     Type:  enhancement     |      Status:  new                 
 Priority:  minor           |   Milestone:                      
Component:  coap            |     Version:                      
 Severity:  -               |    Keywords:                      
----------------------------+-----------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/72#comment:1>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Thu, 25 Nov 2010 17:15:17 -0000

#72: Proxy versus Reverse proxy

Comment(by hartke@…):

 Fielding's dissertation uses the term "gateway" for what is commonly known
 as "reverse proxy". Carsten and Zach agree that the term gateway has too
 broad connotations, so it would be good to have a term that is different
 from Fielding's.

 That makes two types of intermediaries, "proxy" and "reverse proxy" (term
 for the latter to be decided).

 It would also be good to have an encompassing term for a CoAP intermediary
 that performs caching (which can be true of both "proxies" and "reverse
 proxies").

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/72#comment:2>
core <http://tools.ietf.org/core/>

---

From: Peter Bigot <[email-masked]>
Date: Thu, 25 Nov 2010 12:31:07 -0600

The two distinct entities I want to make sure are not confused are:

* That entity to which a client intentionally delegates the responsibility
  of executing a REST-layer transaction.  The URI may influence the client's
  selection of an appropriate delegate, but its authority part does not
  resolve to that proxy, not even to the client.

* Entities through which transaction messages pass due to network
  configuration, without visibility to the origin client or origin server.

A CoAP client that is using an entity of the first type ("a Proxy") is
specifically doing something different than a client that isn't, even if the
only difference is the client placing the Request-Proxy option in the
header.  This type of proxy service embodies an application that is
specifically different from an origin server.  Conceptually, the same role
could be applied by encapsulating the CoAP message in an envelope and using
a different protocol to transmit it to the delegate.

As outlined in my original email, a constrained device network is likely to
have to delegate certain operations due to limited resources (DNS
implementation, duty cycle, ...).  Although dirty DNS and IP packet
rewriting tricks could allow a client to operate in ignorance of this
delegation, by introducing the concept that motivated what's now proposed as
the Request-Proxy option CoAP has recognized this role.  I think it's
important to have a name for it.

Referring to the Apache HTTP server glossary, we have:

Proxy
    An intermediate server that sits between the client and the origin
    server. It accepts requests from clients, transmits those requests on to
    the origin server, and then returns the response from the origin server
    to the client. If several clients request the same content, the proxy
    can deliver that content from its cache, rather than requesting it from
    the origin server each time, thereby reducing response time.

Reverse Proxy
    A proxy server that appears to the client as if it is an origin
    server. This is useful to hide the real origin server from the client
    for security reasons, or to load balance.

These definitions seem more to be what people have in mind, but to my mind
do not make clear the intentional configuration of a client to delegate
responsibility for a transaction to another agent.  Also, I think one reason
people have a problem with "gateway" as used by Fielding is that by his
definition (or at least my interpretation of it) a gateway node might not
even look at the CoAP layer to do its job (e.g., a NAT service at a 6lowpan
border).

Can we use Proxy for the first entity I describe, and Reverse Proxy for the
second entity, with the understanding that Reverse Proxy refers to an entity
operating at the CoAP level?  This leaves us without a name for intermediary
nodes that manipulate transactions below the CoAP level, but perhaps we
don't need one.

Peter

On Thu, Nov 25, 2010 at 11:15 AM, core issue tracker <[email-masked]>wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Zach Shelby <[email-masked]>
Date: Fri, 26 Nov 2010 09:59:10 +0200

> nodes that manipulate transactions below the CoAP level, but perhaps we

Works for me. In my opinion we don't have the need to define/name (in this document) an entity manipulating transactions below L5. 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297