On Thu, 24 May 2018 at 20:44, Michael Richardson
wrote:
>
> Mališa Vučinić wrote:
> > @Michael, @Christian
>
> > I am re-reading RFC7252, Section 5.7.2:
>
> okay, but I'm not claiming that the Join Proxy is a CoAP Proxy by the rules
> given in
Mališa Vučinić wrote:
> @Michael, @Christian
> I am re-reading RFC7252, Section 5.7.2:
okay, but I'm not claiming that the Join Proxy is a CoAP Proxy by the rules
given in 7252. It started as just a circuit proxy (i.e. algorithm gateway), but
we wanted it to be
@Michael, @Christian
I am re-reading RFC7252, Section 5.7.2:
Unless a proxy is configured to forward the proxy request to another proxy,
> it MUST translate the request as follows: the scheme of the request URI
> defines the outgoing protocol and its details (e.g., CoAP is used over UDP
> for
Pascal Thubert (pthubert) wrote:
> I understood so far sar the CoAP URI host is the same as the http host:
> header parameter. If I m correct then this is normally a string with
> the dns name and port to reach the server. Without it, the proxy
> wouldn’t know
Mališa Vučinić wrote:
> I am not sure I follow. How come is it not the case that this well-known
> host name is resolved to an IP address?
We don't need to map this name to an IP address, nor could we have a
consistent mapping world-wide. The IP address is known to
I’m lost as well;
I understood so far sar the CoAP URI host is the same as the http host: header
parameter. If I m correct then this is normally a string with the dns name and
port to reach the server. Without it, the proxy wouldn’t know how to reach the
server in the first place. Without it,
Pascal Thubert (pthubert) wrote:
>> I don't understand at all. Would a PCE provide enrollment services?
pt> [PT>] We are talking to a stateless CoAP proxy, giving an alias to a
pt> service that it will map into the IP address of the server, here the
pt>
Hello Michael
> -Original Message-
> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Michael Richardson
> Sent: vendredi 18 mai 2018 17:10
> To: Pascal Thubert (pthubert) <pthub...@cisco.com>
> Cc: 6tisch@ietf.org
> Subject: Re: [6tisch] On minimal-s
Pascal Thubert (pthubert) wrote:
>>> Suggestion: "default-jrc.6tisch.arpa".
>>
>> Why make it longer? Note that it's already to a unique Path-URI (/j), so
we
>> can add new things if it's CoAP.
> The point is that 6TiSCH.arpa doesn’t dénote what 6TISCH
we were told to use a form like “IEEE Std. 802.15.4” to
> refer to the IEEE standards. Note that one should avoid dating the IEEE
> spec references unless there is a quote or a pointer that is specific to a
> particular year.
>
Removed date from th
Hello Michael:
Regards,
Pascal
> Le 15 mai 2018 à 21:07, Michael Richardson a écrit :
>
>
> Pascal Thubert (pthubert) wrote:
>pt> ·We should not say the following:
>
>txt> When the JRC is not co-located with the 6LBR, then the
Pascal Thubert (pthubert) wrote:
pt> ·We should not say the following:
txt> When the JRC is not co-located with the 6LBR, then the code point
txt> provides a clear indication to the 6LBR that this is join response
txt> traffic.
pt> This seems to
Thanks for this review, Pascal. I went quickly through your comments and I
should be able to fix all of this for -06. My goal is to have -06 ready for
WGLC.
On Tue, May 15, 2018 at 4:00 PM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:
> Hello Mališa
>
>
>
> As you are getting ready to
Hello Mališa
As you are getting ready to publish a next rev, please find simple comments on
05 that you may want to act upon in 06.
·As mentioned earlier in the draft, the most probable collocation for
the JRC would be the 6LBR, and probably not a JP deep in the network.
Why did you
14 matches
Mail list logo