JinHyeock Choi
2018-03-13 11:29:10 UTC
Bill
so that per-resource alternate locations can also be supported.
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
- 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.
/
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
Hi Jaime,
Dear authors,
I had some time to review
draft-silverajan-core-coap-protocol-negotiation-07, below is the feedback.
- 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
- 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.
- 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.
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
https://www.ietf.org/mailman/listinfo/core
Dear authors,
I had some time to review
draft-silverajan-core-coap-protocol-negotiation-07, below is the feedback.
- 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
- 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.
- 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.
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
https://www.ietf.org/mailman/listinfo/core