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

[peter van der Stok <[e-mail]>]

Hi Esko,

So it is indeed a small change to handle the coap-http case as well and 
does not warrant a different document.


Peter

Dijk, Esko schreef op 2013-04-12 09:06:
> 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: [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.