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