Re: [secdir] Secdir last call review of draft-ietf-6lo-use-cases-12
Robert Sparks <rjsparks@nostrum.com> Tue, 12 July 2022 15:01 UTC
Return-Path: <rjsparks@nostrum.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AA8C14F74F; Tue, 12 Jul 2022 08:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.287
X-Spam-Level:
X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPLw3GepcmNr; Tue, 12 Jul 2022 08:01:15 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947F1C14F74C; Tue, 12 Jul 2022 08:01:15 -0700 (PDT)
Received: from [192.168.1.114] ([47.186.48.51]) (authenticated bits=0) by nostrum.com (8.17.1/8.17.1) with ESMTPSA id 26CF1Dga095017 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 12 Jul 2022 10:01:13 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1657638074; bh=dGDCDsuRMX2Eo7e0zcuyiI6oEhKfoSat1OYRfWZruY8=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=m5i1Y70XxXWOXRShGTqadVKhCVR33z5IaBfKy32euxbIEZsffL3km9ObbSRsk6tgN FsdzepI5LP9OpPFEpbJ+NFwCc4j2btZxL2ax0ENVmpF5LqfJLKJLhYZExfgCjOne/E bjkjhjg/ob26FhDwoB7a+3Sw9xH28gsKIn1MXLr4=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.48.51] claimed to be [192.168.1.114]
Content-Type: multipart/alternative; boundary="------------3nwLE5uDAWindMpUEEu3STDN"
Message-ID: <4516cbea-66a1-b298-842e-f4a8085c7ef3@nostrum.com>
Date: Tue, 12 Jul 2022 10:01:08 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
To: Yong-Geun Hong <yonggeun.hong@gmail.com>
Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-6lo-use-cases.all@ietf.org, lo <6lo@ietf.org>
References: <164919269800.5647.13515861264060312018@ietfa.amsl.com> <f79d9aba-618c-5d08-8a4e-744616097e6c@nostrum.com> <CACt2foGiTNma93=_uxwPfBHJOjJ4P9RcYTThZBbX=NCkOAfHXQ@mail.gmail.com>
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <CACt2foGiTNma93=_uxwPfBHJOjJ4P9RcYTThZBbX=NCkOAfHXQ@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/N2HIBAxTbODP0mucO5RUR7UYT2s>
Subject: Re: [secdir] Secdir last call review of draft-ietf-6lo-use-cases-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jul 2022 15:01:19 -0000
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 <rjsparks@nostrum.com>님이 > 작성: > > 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@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview >
- [secdir] Secdir last call review of draft-ietf-6l… Robert Sparks via Datatracker
- Re: [secdir] Secdir last call review of draft-iet… Robert Sparks
- Re: [secdir] Secdir last call review of draft-iet… Yong-Geun Hong
- Re: [secdir] Secdir last call review of draft-iet… Robert Sparks
- Re: [secdir] Secdir last call review of draft-iet… Yong-Geun Hong