Re: [core] Call for reviews of draft-castellani-core-http-mapping

Hi Peter,

Forgot to mention about the case CoAP-HTTP: another reason the authors did not pursue this was that a CoAP client can simply use the CoAP forward proxying functionality (i.e. a CoAP request with a Proxy-URI option or Proxy-Scheme option containing a http:// URI) to access HTTP servers.

Esko

-----Original Message-----
From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of peter van der Stok
Sent: Tuesday, April 09, 2013 10:46
To: core@ietf.org
Subject: Re: [core] Call for reviews of draft-castellani-core-http-mapping

Dear wg,

Review of draft-castellani-core-http-mapping, including coap-14 section 10.

For me text and objective have become clearer compared to earlier versions.
The objective of the document to describe proxies such that proxies from different manufacturers can be exchanged is a valid motivation for the document.

My first concern is the uri naming convention and proxy definition.
Concerning proxy definition:
I am happy with the explanation of forward, cross and reverse proxy, it clarifies the bit opaque text of coap-14. However, it does not help me much because the cullen example of I-D.bormann-core-cross-reverse-convention is presented as reverse proxy example while the text in castellani made me think it is a forward proxy example, because the client seems to be aware that translation takes place. There still seems to be a gap in my understanding from purely reading the texts.
Concerning naming convention:
The document does not help much in restricting the URI naming conventions. I would expect one of two things:
1)      Strict guidelines how to translate uris (restrict the number of
possibilities)
2)      Provide means to define the uri translation on the proxy.
I do not see any other way of making sure that proxies of different manufacturers can be exchanged.

My second concern is that the document only treats http-coap translation. The case coap-http seems more urgent. We do not want to provide the small devices with a http/tcp code next to the coap/udp code, while these devices will need to talk to “legacy” http back-end servers. Suggestion: add the coap-http part.

Individual nits and suggestions.
Page 6, section 5, all 2, line 5…….explicitly indicates THAT it targets …… (that forgotten?) Section 5, all 3, unicast http to multicast coap is a completely different document (remove the currently in the “currently out of scope”. Wouldn’t you discourage the unicast to multicast aspect in a standardized proxy?
Section 5.1 caching: add “given” to …. all request traffic to a given COAP server…….
Sec 5.1 Multicast; possibly the wrong reason for a valid efficiency
argument: to connect a proxy interface to the mesh network.
Sec 5.1 TCP/UDP: I do not see the placement aspect here Sec 5.2 Notes. Do you not need to give formulas? For example in note 8, the determination of max-age value Sec 5.4 how to configure the limit and queuing/dropping behavior? The document should specify an interface.
Sec 5.5 and 5.6 I like the effort to specify limits of behaviors.
Sec 7. I understand that a proxy represents the typical “man in the middle” threat. Having it securely connected to the network before any access and a regular reconnection may have a positive effect.

hope this helps,

peter

Carsten Bormann schreef op 2013-03-24 23:33:
> In Orlando, we said we were trying to increase the level of attention
> on the HTTP mapping draft with a view to making it a WG document very
> soon.
> So, if you have comments on it now, please send them to the list.
> We had a few people volunteering to review the draft as a prerequisite
> to a call for WG adoption, so please do send in these (short or long,
> as you like) reviews.
> Of course WG adoption means that the WG starts considering this as a
> WG draft, not that we all already agree with every detail, but any
> concerns about scoping and general approach should be discussed now.
>
> Grüße, Carsten
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.