IETF Logo Mail Archive

Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT)

Roman Danyliw <rdd@cert.org> Wed, 21 October 2020 02:10 UTC

Return-Path: <rdd@cert.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6193A09F8; Tue, 20 Oct 2020 19:10:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUeTjVFabZEf; Tue, 20 Oct 2020 19:10:51 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9983A09F6; Tue, 20 Oct 2020 19:10:51 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 09L2AkCx004779; Tue, 20 Oct 2020 22:10:46 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 09L2AkCx004779
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1603246246; bh=OxmJRH6pSDQuhKkLqTCcvaU2y/W22P7l0VLSwlmuIss=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=P+Ss/X2YbYU39BrjDeRKkIVNHiQjde15UtIMiu9mRSUTcY5Kgs9A7nksrSLgvQ6uE +jvbbSx6RPoQvVd1EbZacN6BznUcf1vyxEX0W8jOFkOUkaOBMTrwdPmygOcak0b0nN /O2LOfe54VHOnSl6SCkYDy7SvLahpfiAafYW0Mg4=
Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 09L2AfD5027905; Tue, 20 Oct 2020 22:10:41 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 20 Oct 2020 22:10:41 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Tue, 20 Oct 2020 22:10:41 -0400
From: Roman Danyliw <rdd@cert.org>
To: Fernando Gont <fgont@si6networks.com>, The IESG <iesg@ietf.org>
CC: Owen DeLong <owen@delong.com>, "v6ops@ietf.org" <v6ops@ietf.org>, "v6ops-chairs@ietf.org" <v6ops-chairs@ietf.org>, "draft-ietf-v6ops-slaac-renum@ietf.org" <draft-ietf-v6ops-slaac-renum@ietf.org>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT)
Thread-Index: AQHWpyiIQLBsyj8O3kCPbnX4mKk3aamhTMQA//++8cCAAFP0gP//8Hdw
Date: Wed, 21 Oct 2020 02:10:40 +0000
Message-ID: <c883ecee51be42268e57797f37ccd4b8@cert.org>
References: <160322952602.3916.9135001094597388319@ietfa.amsl.com> <f6bbf5e9-ce2c-fd1f-5c3e-bd4ca6f33adc@si6networks.com> <2b620a6c7c4f4d24b0c26f915263052a@cert.org> <d2d4898d-7c55-0222-5237-71b3ec9282ff@si6networks.com>
In-Reply-To: <d2d4898d-7c55-0222-5237-71b3ec9282ff@si6networks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.203.69]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/bewBwv-3AKtwHrVmtiB-iRokmXk>
Subject: Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2020 02:10:54 -0000

Hi Fernando!

> -----Original Message-----
> From: Fernando Gont <fgont@si6networks.com>
> Sent: Tuesday, October 20, 2020 7:05 PM
> To: Roman Danyliw <rdd@cert.org>; The IESG <iesg@ietf.org>
> Cc: Owen DeLong <owen@delong.com>; v6ops@ietf.org; v6ops-
> chairs@ietf.org; draft-ietf-v6ops-slaac-renum@ietf.org
> Subject: Re: Roman Danyliw's No Objection on draft-ietf-v6ops-slaac-renum-04:
> (with COMMENT)
> 
> Hello, Roman,
> 
> On 20/10/20 19:07, Roman Danyliw wrote:
> > Hi Fernando!
> >
> >> -----Original Message-----
> >> From: iesg <iesg-bounces@ietf.org> On Behalf Of Fernando Gont
> >> Sent: Tuesday, October 20, 2020 5:58 PM
> >> To: Roman Danyliw <rdd@cert.org>; The IESG <iesg@ietf.org>
> >> Cc: Owen DeLong <owen@delong.com>; v6ops@ietf.org; v6ops-
> >> chairs@ietf.org; draft-ietf-v6ops-slaac-renum@ietf.org
> >> Subject: Re: Roman Danyliw's No Objection on draft-ietf-v6ops-slaac-renum-
> 04:
> >> (with COMMENT)
> >>
> >> Hello, Roman,
> >>
> >> Thanks so much for your comments! In-line...
> >>
> >> On 20/10/20 18:32, Roman Danyliw via Datatracker wrote:
> >>> --------------------------------------------------------------------
> >>> --
> >>> COMMENT:
> >>> --------------------------------------------------------------------
> >>> --
> >>>
> >>> Thanks to Klaas Wiereng for the SECDIR review.
> >>>
> >>> ** Section 6.  As Section 3.2 is proposing tuning the parameters in
> >>> RFC4861, it is likely worth reiterating that these security
> >>> considerations still apply
> >>
> >> Not sure what you mean. The security considerations in RFC4861, or
> >> something else?
> >
> > Yes, and this is minor, I meant to restate the obvious that RFC4861 applies
> (instead of a bare statement that no new security).
> 
> Would you consider your comment addresses if we tweak the Security
> Considerations text as:
> 
>     This document discusses a problem that may arise in scenarios where
>     flash-renumbering events occur, and proposes workarounds to mitigate
>     the aforementioned problems.  This document does not introduce any
>     new security issues, and thus the same security considerations as
>     for [RFC4861] apply

That text looks good and would address my feedback.  Thank you!

Regards,
Roman

v2.23.0 | Report a Bug | By Email