Re: [Softwires] Tsvart last call review of draft-ietf-softwire-iftunnel-04

tom petch <daedulus@btconnect.com> Tue, 04 June 2019 16:40 UTC

Return-Path: <daedulus@btconnect.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4024A1200C7; Tue, 4 Jun 2019 09:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.247
X-Spam-Level:
X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
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 tI3Mom-C_Al0; Tue, 4 Jun 2019 09:40:37 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00102.outbound.protection.outlook.com [40.107.0.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C734D120077; Tue, 4 Jun 2019 09:40:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q1u0XbKrDMv0ksTbYgv3UjOz7Oj1n6+WX+0+9yrJTkU=; b=FV1gTUQPk8a6p51ofZHlstQ9gKwN8iqlpnmlC2ixtp5+qd+b4BzlCWZNKFdI85qU88hUmPvKZEQeRh4A0Kn1UvlKfRXZvgsk6ruhTVHcstCtwqGZ0WD1ZSOLsTXav1rigZNl5NloDxD6/ingLXxK/bK5XbBw+UQEqQUvm2H/1UA=
Received: from AM6PR07MB5335.eurprd07.prod.outlook.com (20.177.198.213) by AM6PR07MB5815.eurprd07.prod.outlook.com (20.178.93.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.6; Tue, 4 Jun 2019 16:40:34 +0000
Received: from AM6PR07MB5335.eurprd07.prod.outlook.com ([fe80::551b:17a3:2ca8:f52c]) by AM6PR07MB5335.eurprd07.prod.outlook.com ([fe80::551b:17a3:2ca8:f52c%5]) with mapi id 15.20.1965.011; Tue, 4 Jun 2019 16:40:34 +0000
From: tom petch <daedulus@btconnect.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, David Black <david.black@dell.com>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "softwires@ietf.org" <softwires@ietf.org>, ietf <ietf@ietf.org>, "draft-ietf-softwire-iftunnel.all@ietf.org" <draft-ietf-softwire-iftunnel.all@ietf.org>
Thread-Topic: Tsvart last call review of draft-ietf-softwire-iftunnel-04
Thread-Index: AQHVGvOe5w7bRHq+T0OwD0wXdDr3Yw==
Date: Tue, 4 Jun 2019 16:40:34 +0000
Message-ID: <00ec01d51af3$a516af00$4001a8c0@gateway.2wire.net>
References: <155726915148.24435.7582686501694078061@ietfa.amsl.com> <B4EB793C-CC54-462B-BD35-891BD0150635@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0187.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a::31) To AM6PR07MB5335.eurprd07.prod.outlook.com (2603:10a6:20b:6c::21)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 326b1697-a76b-4a89-c304-08d6e90b5d47
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:AM6PR07MB5815;
x-ms-traffictypediagnostic: AM6PR07MB5815:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <AM6PR07MB5815CCEA0292E864BFD5204AC6150@AM6PR07MB5815.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0058ABBBC7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(346002)(396003)(39860400002)(366004)(13464003)(51444003)(189003)(199004)(61296003)(4326008)(81166006)(99286004)(229853002)(8936002)(25786009)(76176011)(81816011)(81686011)(386003)(6436002)(62236002)(81156014)(305945005)(102836004)(6512007)(9686003)(52116002)(1556002)(476003)(186003)(50226002)(7736002)(6306002)(44716002)(73956011)(110136005)(6506007)(66476007)(66556008)(64756008)(66446008)(4720700003)(66946007)(54906003)(6486002)(68736007)(44736005)(8676002)(446003)(66066001)(19627235002)(14444005)(6246003)(26005)(316002)(486006)(2906002)(84392002)(3846002)(6116002)(478600001)(14496001)(14454004)(2501003)(53936002)(86362001)(71190400001)(256004)(71200400001)(66574012)(5660300002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB5815; H:AM6PR07MB5335.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: CAPsn+8l1cqeu9b7M9SGZ0FiN1pjqJn0GKZc152ym+9TNo8MC2dSKkHcTnUoAaf8ry25FnZeL+lIH0Qi7sltatUc77k+FJMjaxL1g6vzbBAWZrlUSlYmWJwMDEQi1HXVEBZuXi5Vhcfr0N25rc1nI/8+f3yZWflyWWp1L6n2GvXkPDyTt5t+aYY+1SzudutPYj/KDoL4y1MTDniBBATEZNUjlMxS5OqZ0diI70Hd1miShkplIXTR0fdNsjqG4qPNVJC4t0Ct0CQe2IXBft96Jg8ocWNFKhFegDFPRcIKi7oHdVNwJN0i37lquaXg+YMlfgDNJPt8/9OfFE83wh0KshpiN0NI/kFlI+2u9357x2ul+4Tt5vHx6Tpk6eqIMz/7UusjgV0rBKnMVPijbdbHiIbZX9w4Yr9T/36hgLqyraE=
Content-Type: text/plain; charset="utf-8"
Content-ID: <6FF4E1402412E844B0FC90B9FDE774C3@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 326b1697-a76b-4a89-c304-08d6e90b5d47
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2019 16:40:34.1208 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: daedulus@btconnect.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5815
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/XoMwzaa73NZgAnLH_zlI3hd2A4E>
Subject: Re: [Softwires] Tsvart last call review of draft-ietf-softwire-iftunnel-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jun 2019 16:40:39 -0000

----- Original Message -----
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>;
Sent: Tuesday, May 28, 2019 8:07 AM

> Dear all,
>
> Thank you again for the review.
>
> After discussion with Dave Thaler (who maintains the tunnel type IANA
registry), it appears that the draft can go forward without waiting for
a complete IANA registry for tunnel types.

Eric

Accepting that not all tunnel types will be in the IANA YANG module, I
think that there is another unresolved issue that I see as problematic.

The I-D talks of the IANA tunnelType Table, as in s.4.2, but I see no
such thing on the IANA website. There is a MIB module but that is not a
registry.  The referenced URL is
Internet-standard MIB -
mib-2.interface.ifTable.ifEntry.ifType.tunnelType
a MIB module, not a registry.

The treatment of interfaces and tunnels by IANA are different.
Interfaces have a registry and when that is updated, that drives updates
to a YANG module and a MIB module

Tunnels do not have a registry, just a MIB module.  Probably this I-D
should create a registry of tunnels so that MIB and YANG tunnel modules
can be updated in the same way as Interface ones are.  As it is, I see
nowhere for the new text relating to a YANG module to go in the existing
IANA pages.

I realise that the Expert Reviewer thinks he can manage but I want the
IANA pages to make sense more widely than that.

Tom Petch

>
> Best regards
>
> -éric
>
> On 08/05/2019, 00:45, "David Black via Datatracker"
<noreply@ietf.org>; wrote:
>
>     Reviewer: David Black
>     Review result: Not Ready
>
>     This document has been reviewed as part of the transport area
review team's
>     ongoing effort to review key IETF documents. These comments were
written
>     primarily for the transport area directors, but are copied to the
document's
>     authors and WG to allow them to address any issues raised and also
to the
>     IETF discussion list for information.
>
>     When done at the time of IETF Last Call, the authors should
consider this
>     review as part of the last-call comments they receive. Please
always CC
>     tsv-art@ietf.org if you reply to or forward this review.
>
>     This draft defines a YANG module for tunnel types based on the
MIB-2
>     tunnel type registry maintained by IANA.
>
>     My fundamental concern with this draft is that the MIB-2 tunnel
type
>     registry is seriously incomplete and out of date, as there are a
large
>     number of tunnel types that aren't included in that registry,
e.g., IPsec
>     tunnel-mode AMT tunneling.  In its current form, that registry
does not
>     appear to be a good starting point for specifying YANG management
of
>     tunnels.
>
>     A limited justification that I could envision for defining this
YANG module
>     would be to use it for mechanical translations to YANG of existing
MIBs
>     that use MIB-2 tunnel types - if that's the justification, then it
would need
>     to be clearly stated in an applicability statement within this
draft, and the
>     discussion of extension of this YANG module would need to be
aligned with
>     that limited applicability.
>
>     The proverbial "right thing to do" would be to update both the
MIB-2 tunnel
>     type registry and this draft with all of the currently known
tunnel types.
>     The references section of draft-ietf-tsvwg-rfc6040update-shim
>
(https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/)
>     may help in identifying tunnel protocols that should be included.
>
>     A minor concern involves the use of RFC 8085 as the reference for
UDP
>     tunnels; while that's certainly better than the existing use of
RFC 4087, due
>     to the extensive design guidance in RFC 8085, designers of
UDP-encapsulated
>     tunnel protocols ought to be encouraged to register their
protocols as separate
>     tunnel types (e.g., so the network operator has some idea of what
the UDP
>     tunnel is actually being used for).  This draft ought to encourage
tunnel
>     protocol designers to register their own tunnel types in
preference to reuse
>     of the UDP tunnel type, including placing text in the IANA tunnel
type
>     registry and this YANG module to encourage that course of action.
>
>
>
>
>