Re: [Tsv-art] Tsvart last call review of draft-ietf-softwire-iftunnel-04
<mohamed.boucadair@orange.com> Thu, 09 May 2019 14:43 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F3912011B; Thu, 9 May 2019 07:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aP-C5FBmJsWV; Thu, 9 May 2019 07:43:21 -0700 (PDT)
Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FCE6120120; Thu, 9 May 2019 07:43:14 -0700 (PDT)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 450GKr1vGqz10tN; Thu, 9 May 2019 16:43:12 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.51]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 450GKq6WnnzDq82; Thu, 9 May 2019 16:43:11 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM22.corporate.adroot.infra.ftgroup ([fe80::954c:232a:f07d:25af%21]) with mapi id 14.03.0439.000; Thu, 9 May 2019 16:43:11 +0200
From: mohamed.boucadair@orange.com
To: "Black, David" <David.Black@dell.com>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "softwires@ietf.org" <softwires@ietf.org>, "ietf@ietf.org" <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: AQHVBjvLoGotpmycT0al8kNJQOcXkqZiy2vAgAAIe7A=
Date: Thu, 09 May 2019 14:43:11 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA7ACE5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <155726915148.24435.7582686501694078061@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA7A76F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CE03DB3D7B45C245BCA0D243277949363055C97D@MX307CL04.corp.emc.com>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949363055C97D@MX307CL04.corp.emc.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/Q-zyghi1Essk9gp_eIju4zZV50s>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-softwire-iftunnel-04
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 May 2019 14:43:24 -0000
Re-, I agree with you that many tunneling schemes are not present in the IANA registry but is that a problem? I don't think so because registrations are for a reason. The natural way from where I sit is that any specification that, for example, defines a specific YANG module for a tunneling scheme not currently in the IANA registry, and needs a specific interface type, will make a request for a code assignment. FWIW, we are making this work because we had a concrete case (draft-ietf-softwire-yang) which needs to augment the YANG interface module for a specific tunnel scheme. To that aim, we requested IANA to assign a new type and designed this module to access to tunnel types maintained by IANA. When a new registration is made, the module defined in draft-ietf-softwire-iftunnel will be updated automatically by IANA. I fail to see why the "best course of action" for this document is to register new types without defining the usage. Cheers, Med > -----Message d'origine----- > De : Black, David [mailto:David.Black@dell.com] > Envoyé : jeudi 9 mai 2019 15:46 > À : BOUCADAIR Mohamed TGI/OLN; tsv-art@ietf.org > Cc : softwires@ietf.org; ietf@ietf.org; draft-ietf-softwire- > iftunnel.all@ietf.org; Black, David > Objet : RE: Tsvart last call review of draft-ietf-softwire-iftunnel-04 > > > [Med] The intent of the draft is to reflect the current registered > tunnels types. > ... > > [Med] Registering new tunnel types is not in the scope set for this > draft. > > I understand that, but as stated in the review, I don't think that it's > the best course of action. The email below appears to reject all of the > IETF Last Call comments in the review and in particular presents the scope > of the draft as fixed and unchangeable; that's unfortunate. On that > basis, I will agree to disagree and leave these IETF Last Call concerns to > the ADs to sort out. > > Thanks, --David > > > -----Original Message----- > > From: mohamed.boucadair@orange.com > > <mohamed.boucadair@orange.com> > > Sent: Thursday, May 9, 2019 3:50 AM > > To: Black, David; tsv-art@ietf.org > > Cc: softwires@ietf.org; ietf@ietf.org; draft-ietf-softwire- > iftunnel.all@ietf.org > > Subject: RE: Tsvart last call review of draft-ietf-softwire-iftunnel-04 > > > > > > [EXTERNAL EMAIL] > > > > Hi David, > > > > Thank you for the review. > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : David Black via Datatracker [mailto:noreply@ietf.org] > > > Envoyé : mercredi 8 mai 2019 00:46 > > > À : tsv-art@ietf.org > > > Cc : softwires@ietf.org; ietf@ietf.org; draft-ietf-softwire- > > > iftunnel.all@ietf.org > > > 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 > > > 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, > > > > [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 > > > (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. > > > > > > > [Med] Wouldn't that recommendation be better added to documents such > > as: https://tools.ietf.org/html/draft-thaler-iftype-reg-02?
- [Tsv-art] Tsvart last call review of draft-ietf-s… David Black via Datatracker
- Re: [Tsv-art] Tsvart last call review of draft-ie… Rajiv Asati (rajiva)
- Re: [Tsv-art] Tsvart last call review of draft-ie… Black, David
- Re: [Tsv-art] Tsvart last call review of draft-ie… mohamed.boucadair
- Re: [Tsv-art] Tsvart last call review of draft-ie… Black, David
- Re: [Tsv-art] Tsvart last call review of draft-ie… mohamed.boucadair
- Re: [Tsv-art] Tsvart last call review of draft-ie… tom petch
- Re: [Tsv-art] Tsvart last call review of draft-ie… mohamed.boucadair
- Re: [Tsv-art] Tsvart last call review of draft-ie… Magnus Westerlund
- Re: [Tsv-art] Tsvart last call review of draft-ie… mohamed.boucadair
- Re: [Tsv-art] Tsvart last call review of draft-ie… Eric Vyncke (evyncke)
- Re: [Tsv-art] Tsvart last call review of draft-ie… Suresh Krishnan
- Re: [Tsv-art] Tsvart last call review of draft-ie… Eric Vyncke (evyncke)
- Re: [Tsv-art] Tsvart last call review of draft-ie… mohamed.boucadair
- Re: [Tsv-art] Tsvart last call review of draft-ie… Eric Vyncke (evyncke)
- Re: [Tsv-art] Tsvart last call review of draft-ie… Mirja Kuehlewind
- Re: [Tsv-art] Tsvart last call review of draft-ie… Rajiv Asati (rajiva)
- Re: [Tsv-art] Tsvart last call review of draft-ie… tom petch
- Re: [Tsv-art] Tsvart last call review of draft-ie… tom petch
- Re: [Tsv-art] Tsvart last call review of draft-ie… mohamed.boucadair