Dear Eric,
Thank you for the review and comments,
Please see answers inline.
El 21/11/24 a las 8:53, Éric Vyncke via Datatracker escribió:
Éric Vyncke has entered the following ballot position for
draft-ietf-ace-wg-coap-eap-11: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer tohttps://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!D9dNQwwGXtA!TZVBHRgLFp62FB9L066Rg1uOAr0aHmrHHnhTt83Cnn0wPOjyV-cPEqyRb-Ke5YxTja0P9YnVbV4wQ_-p$
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-ace-wg-coap-eap/__;!!D9dNQwwGXtA!TZVBHRgLFp62FB9L066Rg1uOAr0aHmrHHnhTt83Cnn0wPOjyV-cPEqyRb-Ke5YxTja0P9YnVbRbcVXsJ$
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
# Éric Vyncke, INT AD, comments for draft-ietf-ace-wg-coap-eap-11
Thank you for the work put into this document. I like the idea of using EAP to
authenticate and secure CoAP.
Authors > Thank you for the feedback.
Please find below one blocking DISCUSS points (easy to address by the
shepherd), some non-blocking COMMENT points (but replies would be appreciated
even if only for my own education), and some nits.
Thanks to Loganaden Velvindron for the shepherd's detailed write-up including
the WG consensus *but it lacks* the justification of the intended status. It is
also to vague, hence a DISCUSS ballot.
Other thanks to Eliot Lear, the IoT directorate reviewer (at my request),
please consider this int-dir review:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/review-ietf-ace-wg-coap-eap-11-iotdir-telechat-lear-2024-10-19/__;!!D9dNQwwGXtA!TZVBHRgLFp62FB9L066Rg1uOAr0aHmrHHnhTt83Cnn0wPOjyV-cPEqyRb-Ke5YxTja0P9YnVbTG2s6sd$
and a previous early review
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/review-ietf-ace-wg-coap-eap-08-iotdir-early-lear-2023-07-05/__;!!D9dNQwwGXtA!TZVBHRgLFp62FB9L066Rg1uOAr0aHmrHHnhTt83Cnn0wPOjyV-cPEqyRb-Ke5YxTja0P9YnVbaGk9Uad$
Glad to read the follow-up email discussions with Eliot and the authors.
I hope that this review helps to improve the document,
Regards,
-éric
# DISCUSS (blocking)
As noted
inhttps://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!D9dNQwwGXtA!TZVBHRgLFp62FB9L066Rg1uOAr0aHmrHHnhTt83Cnn0wPOjyV-cPEqyRb-Ke5YxTja0P9YnVbUxILwpg$
, a
DISCUSS ballot is just a request to have a discussion on the following topics:
## Shepherd write-up
There are too many "XXX: check with co-authors' included critical questions
about IPR disclosure and willingness to be cited as authors. I.e., I do no
think that it is up to the IESG to check these points on their own.
I also find that answers to question 1 and 2 as contradicting each others...
Authors > We contacted Loganaden regarding these points.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
# COMMENTS (non-blocking)
## Section 3.1
Where is `Step 0` defined ? I.e., refer to section 3.2.
Authors > Thank you, we added the reference.
The text is too assertive about the use of mDNS & DHCPv6 as these protocols
cannot currently be used for the discovery (i.e., no option is defined for
DHCPv6).
Authors > Thank you for this observation. We change the text to avoid
this, and as previously stated this is said to be out of scope.
“There are different methods to discover the IPv6 address of the EAP
authenticator or intermediary entity.”
## Section 3.2
Who is `we` ? The authors ? The WG ? The IETF ? Suggest using the passive voice.
Authors > We have rewritten the text using passive voice to avoid this.
## Section 7.1
Is CoAP always over IPv6, i.e., does it always run over 6LO, RFC 7252 seems to
allow CoAP over IPv4 ? Else `CoAP goes on top of UDP/TCP, which provides a
checksum mechanism over its payload` is not correct as UDP over IPv4 can have
no check-sum.
Authors > Thank you for the comments.
It is worth noting that the PANA protocol [RFC 5191] and PCP [RFC7652]
transport EAP on top of UDP and there was no issue in this area, and
they do not add any checksum in the protocol. We would relay on lower
layers checksums.
In any case, if we use CoAP-EAP, in case of using UDP and IPv4,we would
rely on the link-layer checksums. If not available, we would use
CoAP-EAP over a reliable transport such as TCP or Websockets.
The new text will be as follows:
“Lower layer error detection. EAP relies on lower layer error detection
(e.g., CRC, checksum, MIC, etc.). For simplicity, CoAP-EAP delegates
error detection to the lower layers, such as the link layer or transport
layer (e.g., UDP over IPv6 or TCP).”
# NITS (non-blocking / cosmetic)
## Use of SVG graphics
Please consider using the aasvg tool to have nice graphics ;-)
Authors > Sure, the next version we will add SVG. Thank you for the
suggestion.
--
Dan García Carrillo
---------------------
Departamento de Informática, Área de Telemática, Universidad de Oviedo
2.7.8 - Escuela Politécnica de Ingeniería, 33204, Campus de Viesques, Gijón
Tel.: +34 985182654 (Ext. 2654) | email:garcia...@uniovi.es
_______________________________________________
Ace mailing list -- ace@ietf.org
To unsubscribe send an email to ace-le...@ietf.org
