On 7/11/22 8:16 PM, Yong-Geun Hong wrote:
Dear Robert Sparks.
First, thanks for your valuable review and comments of the 6lo use
cases draft.
Second, sorry for the late reply. I have acknowledged your email but
due to other business, I lost the chance to reply immediately.
During the update of this draft, I tried to resolve your comments in
the revision.
The following are my responses for your comments.
1. Update the section of Security Considerations
As you mentioned, it seems that the use cases draft does not have
close relation with security issues but it has several parts which are
related to security issues in the main body.
As you recommend, I added the summary texts in the section of
Security Considerations.
I don't think the addition is sufficient. As written it's almost
cryptic. This section should say _why_ L2 security is required, and what
the threats are if it is not provided.
2. Handling of Appendix A
In old versions of this draft, the content in Appendix A is located
in the main body. During progressing this draft and resolving the
comments, it was moved to Appendix A.
At the IETF 114, I would ask for directions and decide how to proceed.
3. Misuse of technology description and marketing words
As you pointed, the draft has some parts which are recognized as
marketing words. Because we invited some experts who are involved in
the specific area, some marketing words could be included.
I tried to change the marketing words to technology words in the
revision.
You could find the revised version of this draft in here :
https://datatracker.ietf.org/doc/draft-ietf-6lo-use-cases
Once again, thanks for your review and comments
Best regards.
Yong-Geun.
2022년 4월 6일 (수) 오전 6:09, Robert Sparks <[email protected]>님이
작성:
Apologies, there's an edit-buffer glitch below, corrected in what's
uploaded at
https://datatracker.ietf.org/doc/review-ietf-6lo-use-cases-12-secdir-lc-sparks-2022-04-05/.
On 4/5/22 4:04 PM, Robert Sparks via Datatracker wrote:
> Reviewer: Robert Sparks
> Review result: Has Issues
>
> 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 last call
> comments.
>
> This document has issues to address before publication as an
Informational RFC
>
> Issues:
>
> >From the abstract: "The document targets an audience who would
like to
> understand and evaluate running end-to-end IPv6 over the
constrained node
> networks for local or Internet connectivity."
>
> Its security considerations section claims "Security
considerations are not
> directly applicable to this document". Yet the text of the draft
has several
> places that rightly call out thing like "there exist
implications for privacy",
> "privacy also becomes a serious issue", and "the assumption is
that L2 security
> must be present." A summary of these things in the security
considerations
> section seems prudent. At _least_ call out again the assumption
about L2
> security.
>
> The "Security Requirement"A summary of these things in the security
> considerations section seems prudent. At _least_ call out again
the assumption
> about L2 security.
>
> The "Security Requirement" row in Table 2 is not well explained.
The values in
> that row are explained at all. (For instance, the word
"Partially" appears
> exactly once in the document - it is unclear what it means).
>
> Nits/Comments:
>
> Appendix A is neither introduced nor referenced from the body of
the document.
> Why is it here?
>
> I'm a little concerned about some of the technology descriptions
possibly
> moving beyond simple facts into interpretation or even
marketing. The last
> paragraph of section 2.5 is a particularly strong example. Look
for phrases
> section 4 that include "targets" or "targeted by" and make sure
that's what the
> organizations ins that define those technologies say (consider
references).
>
> At 'superior "range"', why is range in quotes? Think about
restructuring the
> sentences that use 'superior' to avoid the connotation of
"better than". All
> this document really needs to acknowledge is "goes further".
>
>
>
> _______________________________________________
> secdir mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
