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.
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 <rjsparks@xxxxxxxxxxx>님이 작성:
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
> secdir@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
