Dear Robert Sparks.
Thanks for your valuable comments and sorry for the late response.
To resolve your comments, I updated the related paragraph as follows.
- Security and Encryption: Though 6LoWPAN basic specifications do not address security at the network layer, the assumption is that L2 security must be present. Nevertheless, care must be taken since specific L2 technologies may exhibit security gaps. Typically, 6lo L2 technologies (see Section 2) offer security properties such as confidentiality and/or message authentication. In addition, end-to-end security is highly desirable. Protocols such as DTLS/TLS, as well as object security are being used in the constrained-node network domain [I-D.ietf-lwig-security-protocol-comparison]. The relevant IETF working groups should be consulted for application and transport level security. The IETF has worked on address authentication [RFC8928] and secure bootstrapping is also being discussed in the IETF. However, there may be other security mechanisms available in a deployment through other standards such as hardware-level security or certificates for the initial booting process. In order to use security mechanisms, the implementation needs to afford it in terms of processing capabilities and energy consumption.
And, I submitted the revision draft based on your comments.
It is appreciated to check again and let me know any missing points.
Best regards.
Yong-Geun.
2022년 11월 18일 (금) 오전 1:36, Robert Sparks via Datatracker <noreply@xxxxxxxx>님이 작성:
Reviewer: Robert Sparks
Review result: Ready
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other review
comments.
This document is ready for publication as an Informational RFC
Thanks for addressing my Last Call comments. The new Security Considerations
text is helpful (though I would have preferred even more).
I'll point to one last potential problem spot (as a nit) that you may wish to
reconsider. See Section 3 at:
"Encryption is important if the implementation can afford it."
>From the rest of the document, it's clear that Encryption is important even if
the implementation _can't_ afford it (and what does "afford it" even mean in
this context)?
Please try to find more specific text to convey what you are trying to say.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
