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

[Jaime Jiménez]

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?
- what happens if any of the context on “at” is different than the one used to register the endpoint.
- is the lifetime of the registration also carried to the other transport (is the ep being registered on both transports)?
- are security associations between client and server reset when switching transport?
- I think the lookup example could benefit from a more complex lookup, for instance using “rt” or “et” with “tt”.

* Alternative transports option:
- I’m not sure about this but wouldn’t this force to mandate specific CoAP ports per transport?
- 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?

* “ol” attribute:
- typo: availabilty
- 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?
- OCF uses a similar link attribute called “eps”.
- there should at least exist an informative ref to core-link format.

The security considerations part will require quite a bit of work.
Implications on ETCH?
This draft is intended as informational, however at some point we should have some normative text too for implementors, right?

Ciao!
- - Jaime Jiménez

[Bill Silverajan]

Hi Jaime,

Post by Jaime Jiménez
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.

Post by Jaime Jiménez
- 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.

Post by Jaime Jiménez
- 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.

Post by Jaime Jiménez
- are security associations between client and server reset when switching transport?

Currently, yes. There are no session resumption/information exchanged
between transports defined yet.

Post by Jaime Jiménez
- 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

Post by Jaime Jiménez
- 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

Post by Jaime Jiménez
- 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.

Post by Jaime Jiménez
- typo: availabilty

Thanks, fixed.

Post by Jaime Jiménez
- 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.

Post by Jaime Jiménez
- 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/

Post by Jaime Jiménez
- there should at least exist an informative ref to core-link format.

I missed this comment for -08, sorry. Will be added for -09.

Post by Jaime Jiménez
The security considerations part will require quite a bit of work.

Particularly for alternate locations, agree on this.

Post by Jaime Jiménez
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.

Post by Jaime Jiménez
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