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

[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