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

[JinHyeock Choi <[e-mail]>]

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 <[e-mail]>님이 작성:

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>
>