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

<> Thu, 09 May 2019 07:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB33212008C; Thu, 9 May 2019 00:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JxgRgoj6v1eF; Thu, 9 May 2019 00:49:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6BF2E120006; Thu, 9 May 2019 00:49:54 -0700 (PDT)
Received: from (unknown [xx.xx.xx.68]) by (ESMTP service) with ESMTP id 45058w2W0WzCr20; Thu, 9 May 2019 09:49:52 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) by (ESMTP service) with ESMTP id 45058v68h1z1xpY; Thu, 9 May 2019 09:49:51 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7D.corporate.adroot.infra.ftgroup ([fe80::bcfe:4850:e646:f223%21]) with mapi id 14.03.0439.000; Thu, 9 May 2019 09:49:51 +0200
From: <>
To: David Black <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Tsvart last call review of draft-ietf-softwire-iftunnel-04
Thread-Index: AQHVBSahckFrxdrf30G+bBb9YX7WPKZiXS9g
Date: Thu, 9 May 2019 07:49:50 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA7A76F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Softwires] Tsvart last call review of draft-ietf-softwire-iftunnel-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: softwires wg discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 May 2019 07:49:57 -0000

Hi David, 

Thank you for the review. 

Please see inline.


> -----Message d'origine-----
> De : David Black via Datatracker []
> Envoyé : mercredi 8 mai 2019 00:46
> À :
> Cc :;; draft-ietf-softwire-
> Objet : Tsvart last call review of draft-ietf-softwire-iftunnel-04
> 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
> 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,

[Med] The intent of the draft is to reflect the current registered tunnels types. This is mentioned in the introduction:

   This document specifies the initial version of the iana-tunnel-type
   YANG module identifying tunnel interface types.  The module reflects
   IANA's registry maintained at [TUNNELTYPE-IANA-REGISTRY].  The latest
   revision of this module can be obtained from the IANA web site.

 and the
> discussion of extension of this YANG module would need to be aligned with
> that limited applicability.

[Med] This is an IANA-maintained module. That is, when a new tunnel type is registered, the module will be automatically updated to include that new type identity: 

      When this registry is modified, the YANG module iana-tunnel-type
      must be updated as defined in RFCXXXX.

> 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.

[Med] Registering new tunnel types is not in the scope set for this draft. It is up to the documents defining these tunnel types or making use of them to make a request to IANA. For example, this is the approach followed in softwire wg for at least three tunnel types (16, 17, 18).  

> 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 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.

[Med] Wouldn't that recommendation be better added to documents such as: