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

tom petch <> Tue, 04 June 2019 16:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4024A1200C7; Tue, 4 Jun 2019 09:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.247
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tI3Mom-C_Al0; Tue, 4 Jun 2019 09:40:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C734D120077; Tue, 4 Jun 2019 09:40:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 ( by ( 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 ([fe80::551b:17a3:2ca8:f52c]) by ([fe80::551b:17a3:2ca8:f52c%5]) with mapi id 15.20.1965.011; Tue, 4 Jun 2019 16:40:34 +0000
From: tom petch <>
To: "Eric Vyncke (evyncke)" <>, David Black <>, "" <>
CC: "" <>, ietf <>, "" <>
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$>
References: <> <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-clientproxiedby: LO2P265CA0187.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a::31) To (2603:10a6:20b:6c::21)
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: []
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: <>
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;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None ( 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: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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-Transport-CrossTenantHeadersStamped: AM6PR07MB5815
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-softwire-iftunnel-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Jun 2019 16:40:39 -0000

----- Original Message -----
From: "Eric Vyncke (evyncke)" <>
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.


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 -
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"
<> 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
>     primarily for the transport area directors, but are copied to the
>     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
> if you reply to or forward this review.
>     This draft defines a YANG module for tunnel types based on the
>     tunnel type registry maintained by IANA.
>     My fundamental concern with this draft is that the MIB-2 tunnel
>     registry is seriously incomplete and out of date, as there are a
>     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
>     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
>     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
>     may help in identifying tunnel protocols that should be included.
>     A minor concern involves the use of RFC 8085 as the reference for
>     tunnels; while that's certainly better than the existing use of
RFC 4087, due
>     to the extensive design guidance in RFC 8085, designers of
>     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
>     protocol designers to register their own tunnel types in
preference to reuse
>     of the UDP tunnel type, including placing text in the IANA tunnel
>     registry and this YANG module to encourage that course of action.