Hi Paul,
Thank you for your time to review the document.
On 27/6/23 03:55, Paul Wouters wrote:
Hi,
I have three questions, in order of importance :)
Why does "CoAP-EAP Exporter Label" need to be an IANA registry? These
are free
form strings, no limited numbers, etc. If there is a risk someone uses
the same
label for a different operation, even having the registry wouldn't
gain us that
much? Also, if it is needed, should it not also contain "CoAP-EAP DTLS
PSK" ?
Thank you for this comment, you are right. Not being associated with a
specific number, we shall leave out the IANA requirement.
Minimum MTU. Lower layers need to provide an EAP MTU size of
1020 octets or greater. CoAP assumes an upper bound of 1024 for
its payload which covers the requirements of EAP.
Is the "EAP MTU size" amd the "upper bound for its payload" the exact same
thing? Or is there a framing/prefix/header difference? Because there
is only
4 bytes leeway here.
This is a very good point, and surely needs to be clarified. On the one
hand, the "EAP MTU size” refers to the requirement that an EAP
lower-layer must provide to EAP for transport (1020). On the other
hand, [CoAP]"upper bound for its payload” means what is the size that
CoAP the lower-layer can provide (1024). Since any EAP method is
conveyed in the payload and 1020 < 1024 and there is no any framing when
transporting any EAP method then we are set. Having said that, a
particular clarification is required with respect to Message 1 and 2 in
Fig. 3. Those messages have extra information apart from EAP .
Nevertheless, the EAP Req/Id has a fixed length of 5 bytes, we see no
issues. Message 2 with the Response Identity, this would limit the
length of the identity being used to the CoAP payload maximum size
(1024) - len( CS || RID-I ) - EAP Response header (5 bytes), but still,
we believe it should be enough space for sending even lengthy identities.
There is a consideration that needs to be considered when using
proxies in the CoAP-EAP, as the exchange contains a role-reversal
process at the beginning of the exchange. In the first message,
the IoT device acts as a CoAP client and the Controller as the
CoAP server. After that, in the remaining exchanges the roles
are reversed, being the IoT device, the CoAP server and the
Controller, the CoAP client.
So what is the "consideration" that "needs to be considered" ?
You are correct, the text needs to be corrected. The considerations here
are the following:
For the first message (0) the proxy will act as forward proxy, and for
the rest as reverse proxy. Additionally, in the first exchange, the EAP
peer acting as CoAP client, sends the URI for the next CoAP message in
the payload of a request. This is not the typical behaviour, as URIs
referring to new services/resources appear in Location-Path and/or
Location-Query Options in CoAP responses. Hence, we understand that the
proxy will need to be "CoAP-EAP aware" to treat the payload of the "POST
/.well-known/coap-eap" as if it were a Location-Path Option.
Thank you,
Dan.
Thanks,
Paul
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
