Subject: Re: [core] Review of draft-silverajan-core-coap-protocol-negotiation

From: JinHyeock Choi <[email-masked]>
Date: Tue, 13 Mar 2018 11:29:10 +0000

Bill

>> - OCF uses a similar link attribute called “eps”.
>
> The idea was to align "ol" with OCF's "eps"
> so that per-resource alternate locations can also be supported.
> This came from Dave's slides in IETF 99. See slide 19:
>
https://datatracker.ietf.org/meeting/99/materials/slides-99-core-consolidated-slides
/

good that "ol" & "eps" would be aligned. They are almost equivalent.
For example,

    ol=http://[FDFD::123]:61616, coap://[2001:db8:f1::2]:5683

corresponds to

    "eps": [
      {"ep": "http://[FDFD::123]:61616"},
      {"ep": "coaps://[2001:db8:f1::2]:5683"}
    ]

There still exisit some differences
(e.g., URI in "ep" shall have IP address in its authority.),
which, I hope, we would discuss in joint meeting next FRI.

best regards

JinHyeock

2018년 3월 8일 (목) 오전 2:47, Bill Silverajan <[email-masked]>님이 작성:

> Hi Jaime,
>
> Thanks for reviewing the document! Below are responses to what you wrote:
>
>
> Jaime Jiménez wrote:
>
> Dear authors,
>
> I had some time to review
> draft-silverajan-core-coap-protocol-negotiation-07, below is the feedback.
>
> * The RD option:
> - have you thought about using this mechanism as a NAT traversal tool?
>
> It potentially can, if the RD is reachable by both client and server, and
> there is some sort of keep-alive mechanism at the NAT. There was also a
> discussion about a potential "coap+at", or an "all-transports" happy
> eyeballs approach based on Thin ICE which might also help.
>
> - what happens if any of the context on “at” is different than the one
> used to register the endpoint.
>
> If you're referring to the usage of "at" to the use of "con", it's
> specifically because we wanted to avoid overloading the semantics of "con",
> which can be used by commissioning tools. So, you can have both parameters
> present.
>
> - is the lifetime of the registration also carried to the other transport
> (is the ep being registered on both transports)?
>
> In short, yes. We thought of introducing lifetime per transport but it
> turned out to make it more complicated. The current approach allows the
> server to update the "at" list every time it sends a registration update on
> RD. This way, transports discovered from RD are always available.
>
> - are security associations between client and server reset when switching
> transport?
>
> Currently, yes. There are no session resumption/information exchanged
> between transports defined yet.
>
> - I think the lookup example could benefit from a more complex lookup, for
> instance using “rt” or “et” with “tt”.
>
> That's a good idea and we introduced that now in version -08
>
>
> * Alternative transports option:
> - I’m not sure about this but wouldn’t this force to mandate specific CoAP
> ports per transport?
>
> Yes they should be standard, but the idea was also to show non-standard
> ports as there will always be endpoints exposing transports on different
> ports than the standard ones
>
> - How large can the payload get? How many alternative transports are
> there? Can’t we assume that we keep the scheme and simply answer with the
> transport supported?
>
> We can't do that all the time and elide the authority. For example
> supporting sms, you'd have a different authority. There could also be many
> alternative transports available, e.g. exposing on different ports.
>
> * “ol” attribute:
> - typo: availabilty
>
> Thanks, fixed.
>
> - this option, with no comment to how the context should be the same can
> redirect a client to another server, right? Is that what we want?
>
> Not necessarily to another server but to another location, could be hosted
> on the same server. Obviously, if the authority changes, the security
> considerations for these kinds of alternate endpoints (that OCF also
> proposed) should be looked at more carefully.
>
> - OCF uses a similar link attribute called “eps”.
>
> The idea was to align "ol" with OCF's "eps" so that per-resource alternate
> locations can also be supported. This came from Dave's slides in IETF 99.
> See slide 19:
> https://datatracker.ietf.org/meeting/99/materials/slides-99-core-consolidated-slides/
>
>
> - there should at least exist an informative ref to core-link format.
>
> I missed this comment for -08, sorry. Will be added for -09.
>
>
> The security considerations part will require quite a bit of work.
>
> Particularly for alternate locations, agree on this.
>
> Implications on ETCH?
>
> Did you mean using FETCH to request for alternate locations? That would
> work as a substitute for the Alternative-transports Option, if we can
> devise a CoRE link that can express alternate transport endpoints on a
> server.
>
> This draft is intended as informational, however at some point we should
> have some normative text too for implementors, right?
>
> That would be great. Also for some feedback from implementers!
>
> Best regards,
> Bill
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: Bill Silverajan <[email-masked]>
Date: Thu, 15 Mar 2018 10:52:31 +0200

Hello JinHyeock,

Thanks for your comments!

>       {"ep": "coaps://[2001:db8:f1::2]:5683"}
That is good. Going forward, the mapping would become easier: We've 
defined "ol" to be repeatable instead of a comma separated list of base 
URIs. For example, 
https://tools.ietf.org/html/draft-silverajan-core-coap-protocol-negotiation-08#section-6.1 

> which, I hope, we would discuss in joint meeting next FRI.
If you are participating in IETF 101, we can also arrange a corridor 
discussion around this topic. I'd be interested in hearing your thoughts 
here too.

Best regards,
Bill

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 16 Mar 2018 10:03:31 +0900

Bill

> That is good. Going forward, the mapping would become easier: We've defined
> "ol" to be repeatable instead of a comma separated list of base URIs. For
> example,

thanks for the clarification. I mistakenly referred the examples from v08.

> discussion around this topic. I'd be interested in hearing your thoughts

Unfortunately IETF 101 conflicts with OCF meeting in Prague.
However FRI afternoon, we will have a T2TRG/ OCF/ WoT joint meeting there,
https://github.com/t2trg/2018-03-ocf-wot
so your participation would be much appreciated.

best regards

JinHyeock

---

From: Jaime Jiménez <[email-masked]>
Date: Mon, 19 Mar 2018 10:50:10 +0000

Hi JinHyeock, hi T2TRG chairs,

would it be possible for you to share in this thread the remote participation details of the T2TRG/ OCF/ WoT join meeting?

Thanks!
- - Jaime Jiménez

> On 16 Mar 2018, at 1.03, JinHyeock Choi <[email-masked]> wrote:
> 
> Bill
>

---

From: Ari Keränen <[email-masked]>
Date: Mon, 19 Mar 2018 15:40:37 +0000

The remote participation details are now available in the meeting github page:
https://github.com/t2trg/2018-03-ocf-wot

Cheers,
Ari

> On 19 Mar 2018, at 10.50, Jaime Jiménez <[email-masked]> wrote:
>