Re: [Idr] Roman Danyliw's No Objection on draft-ietf-idr-tunnel-encaps-20: (with COMMENT)
Roman Danyliw <rdd@cert.org> Thu, 03 December 2020 03:55 UTC
Return-Path: <rdd@cert.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D8F3A09E9; Wed, 2 Dec 2020 19:55:41 -0800 (PST)
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 sjTnfNy2SuJ2; Wed, 2 Dec 2020 19:55:39 -0800 (PST)
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 BD7423A09E5; Wed, 2 Dec 2020 19:55:38 -0800 (PST)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0B33taft027111; Wed, 2 Dec 2020 22:55:36 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 0B33taft027111
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1606967736; bh=BK9iVBzbPPyR+wbomeet2CKWL52Fqqeq3zleBS4T3hU=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=pGH2eA4FdOy2RsUDzs6RTb4LNC8T2ZSjMXQ/zl3NYRL/h3JoBn5Ne/eUk+5D4HXle KxsJD+PG3Rhhs7rFN36THlS1aWUIt1lhkYvyzD5IyefT7AbRJDASxnHmGvycF6mk5s gY40NFev8/nk6lO2yWOR4v8LxBPf6pe1waLc/JuM=
Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0B33tVec041591; Wed, 2 Dec 2020 22:55:31 -0500
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.2106.2; Wed, 2 Dec 2020 22:55:31 -0500
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.2106.002; Wed, 2 Dec 2020 22:55:31 -0500
From: Roman Danyliw <rdd@cert.org>
To: John Scudder <jgs@juniper.net>
CC: The IESG <iesg@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf. org" <idr@ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>, Hares Susan <shares@ndzh.com>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-idr-tunnel-encaps-20: (with COMMENT)
Thread-Index: AQHWx1s3YBEyWsTPbECNny8tkbXRWKnkl1uAgAAoq3A=
Date: Thu, 03 Dec 2020 03:55:30 +0000
Message-ID: <8b27a469b9f745ada895c498380159f6@cert.org>
References: <160676974641.7444.11457973014978444006@ietfa.amsl.com> <847123B1-67D3-41FF-A156-A6A25F66186B@juniper.net>
In-Reply-To: <847123B1-67D3-41FF-A156-A6A25F66186B@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.202.131]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/hV2t6-8mq2dOvmXO-PvLuiON5o4>
Subject: Re: [Idr] Roman Danyliw's No Objection on draft-ietf-idr-tunnel-encaps-20: (with COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2020 03:55:41 -0000
Hi John! > -----Original Message----- > From: John Scudder <jgs@juniper.net> > Sent: Wednesday, December 2, 2020 3:24 PM > To: Roman Danyliw <rdd@cert.org> > Cc: The IESG <iesg@ietf.org>; draft-ietf-idr-tunnel-encaps@ietf.org; idr- > chairs@ietf.org; idr@ietf. org <idr@ietf.org>; Alvaro Retana > <aretana.ietf@gmail.com>; Hares Susan <shares@ndzh.com> > Subject: Re: Roman Danyliw's No Objection on draft-ietf-idr-tunnel-encaps-20: > (with COMMENT) > > Hi Roman, > > Thanks to you and Scott for the review. My comments in line below. > > > On Nov 30, 2020, at 3:55 PM, Roman Danyliw via Datatracker > <noreply@ietf.org> wrote: > > > > [External Email. Be cautious of content] > > > > > > Roman Danyliw has entered the following ballot position for > > draft-ietf-idr-tunnel-encaps-20: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > > this introductory paragraph, however.) > > > > > > Please refer to > > https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discus > > s-criteria.html__;!!NEt6yMaO-gk!SDO6amF- > 195w2tACTwBncPxZpEwE3lYKshrE25 > > ln2IlWuMo7eyz3ZCHi-_XmfQ$ for more information about IESG DISCUSS and > > COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet > > f-idr-tunnel-encaps/__;!!NEt6yMaO-gk!SDO6amF- > 195w2tACTwBncPxZpEwE3lYKs > > hrE25ln2IlWuMo7eyz3ZCGbyG-DkQ$ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank you to Scott Kelly for performing the SECDIR review. > > > > ** Section 1.5. Per “Because RFC 8365 depends on RFC 5640, it is > > similarly obsoleted.”, this seems inconsistent with the meta-data > > header in the document (as RFC8365 isn’t obsoleted). > > Right, see my reply to Martin — this was an error, fixed in the forthcoming > version 21. Thanks. > > ** Section 11. Please use normative language on the applicability > > text restricting use to a single administrative domain. > > > > OLD > > However, it is intended that the Tunnel Encapsulation > > attribute be used only within a well-defined scope, e.g., within a > > set of Autonomous Systems that belong to a single administrative > > entity. > > > > NEW (or something like this) > > > > However, the Tunnel Encapsulation attribute MUST only be used within a > > well-defined scope such as a set of Autonomous Systems that belong to > > a single administrative entity. > > Adopted, but as a SHOULD instead of a MUST — I don’t think we want to > absolutely preclude people experimenting with promiscuous Internet-wide > tunneling if they really want to. This gives me a bit of pause. I read the current text of "well-defined scope" as equivalent to a MUST which is why I noted this as a simple COMMENT. I shouldn't have assumed. If the intent is a SHOULD, then providing that clarity with normative language continues to be helpful. However, as a SHOULD, the current security considerations need to be bolstered to cover the cases where Internet wide tunneling is happening (i.e., outside of the well scoped domain). > > ** Section 12. Typo. s/tunnelling/tunneling/ > > British vs. American spellings, my nemesis. Fixed. Ooops. I was faithfully reporting what my US-English configured reader flagged without giving further consideration. My mistake. > > ** Section 14.2. Per “Specifically, the following code points should > > be marked as deprecated”, how does one mark code points as deprecated > > in the “BGP Tunnel Encapsulation Attribute Tunnel Types” registry > > (https://urldefense.com/v3/__https://www.iana.org/assignments/bgp- > parameters/bgp-parameters.xhtml*tunnel-types__;Iw!!NEt6yMaO- > gk!SDO6amF- > 195w2tACTwBncPxZpEwE3lYKshrE25ln2IlWuMo7eyz3ZCGd89XW4g$ ). > > I don’t see such a column, or is the intend simply to update the > > Reference column to this document? > > (Already addressed.) > > > ** Section 15. Clarifying text > > OLD > > "hijacking" of traffic (insertion of > > an undesired node in the path) > > > > NEW > > "hijacking" of traffic (insertion of an undesired node in the path > > allowing for inspection or modification of traffic, or avoidance of > > security controls) Thanks. Roman > Thanks, done. > > —John
- [Idr] Roman Danyliw's No Objection on draft-ietf-… Roman Danyliw via Datatracker
- Re: [Idr] Roman Danyliw's No Objection on draft-i… John Scudder
- Re: [Idr] Roman Danyliw's No Objection on draft-i… Roman Danyliw
- Re: [Idr] Roman Danyliw's No Objection on draft-i… John Scudder
- Re: [Idr] Roman Danyliw's No Objection on draft-i… Roman Danyliw
- Re: [Idr] Roman Danyliw's No Objection on draft-i… John Scudder