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

["Dijk, Esko" <[e-mail]>]

Hi Peter,

thanks for your comments. About your main concerns:
1. Proxy definition could be updated. There was already an email thread on this; where I propose to define the forward/reverse proxy in such a way that the "client awareness" does not play a role anymore. (So: only the syntax used to access the proxy determines forward or reverse.)
2. URI naming convention for reverse proxy will be added in the next version.
3. CoAP-to-HTTP conversion: this part was removed earlier based on WG feedback that our scope is too wide. I do agree that this topic is also useful. As a separate I-D perhaps?

regards,
Esko

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of peter van der Stok
Sent: Tuesday, April 09, 2013 10:46
To: [e-mail]
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
[e-mail]
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.