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

[Jaime Jiménez <[e-mail]>]

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