Re: [Softwires] Tsvart last call review of draft-ietf-softwire-iftunnel-04
<mohamed.boucadair@orange.com> Fri, 10 May 2019 06:20 UTC
Return-Path: <mohamed.boucadair@orange.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 4407712017F; Thu, 9 May 2019 23:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 ZrTU1aDaOQ9i; Thu, 9 May 2019 23:20:15 -0700 (PDT)
Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C8E120169; Thu, 9 May 2019 23:20:15 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 450g711YNNzBsFJ; Fri, 10 May 2019 08:20:13 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 450g7101Zhz1xpY; Fri, 10 May 2019 08:20:13 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7F.corporate.adroot.infra.ftgroup ([fe80::d9:d3cd:85bd:d331%21]) with mapi id 14.03.0439.000; Fri, 10 May 2019 08:20:12 +0200
From: mohamed.boucadair@orange.com
To: tom petch <daedulus@btconnect.com>, "Black, David" <David.Black@dell.com>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "softwires@ietf.org" <softwires@ietf.org>, "Black, David" <David.Black@dell.com>, "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: AQHVBoIIoGotpmycT0al8kNJQOcXkqZj3ojg
Date: Fri, 10 May 2019 06:20:12 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA7B682@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <155726915148.24435.7582686501694078061@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA7A76F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CE03DB3D7B45C245BCA0D243277949363055C97D@MX307CL04.corp.emc.com> <01be01d50681$86da50e0$4001a8c0@gateway.2wire.net>
In-Reply-To: <01be01d50681$86da50e0$4001a8c0@gateway.2wire.net>
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/softwires/rnogmp_QAeuk2o3p0oCjgnZkhC8>
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: Fri, 10 May 2019 06:20:18 -0000
Hi Tom, Thanks for sharing your thoughts. Please see inline. Cheers, Med > -----Message d'origine----- > De : tom petch [mailto:daedulus@btconnect.com] > Envoyé : jeudi 9 mai 2019 18:13 > À : Black, David; BOUCADAIR Mohamed TGI/OLN; tsv-art@ietf.org > Cc : softwires@ietf.org; Black, David; ietf@ietf.org; draft-ietf-softwire- > iftunnel.all@ietf.org > Objet : Re: Tsvart last call review of draft-ietf-softwire-iftunnel-04 > > ----- Original Message ----- > From: "Black, David" <David.Black@dell.com> > Sent: Thursday, May 09, 2019 2:45 PM > > > > [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. > > > > David > > I think that the concerns that you raise need addressing. [Med] It is an easy fix to update the draft with a table asking codes for the following example list: o CAPWAP [RFC5415] o AMT [RFC7450] o TCP Encapsulation of IKE and IPsec Packets [RFC8229] o NSH [RFC8300] o VXLAN [RFC7348] o LISP [RFC6830bis] o VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] o Geneve [I-D.ietf-nvo3-geneve] o GUE [I-D.ietf-intarea-gue] but I'm struggling with the rationale for doing this in draft-ietf-softwire-iftunnel. Can you please help me understand the following: * Why such request wasn't made earlier for the following? o CAPWAP [RFC5415] o AMT [RFC7450] o TCP Encapsulation of IKE and IPsec Packets [RFC8229] o NSH [RFC8300] o VXLAN [RFC7348] * Why working in progress specifications can't make this request directly to IANA if such code is needed? o LISP [RFC6830bis] o VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] o Geneve [I-D.ietf-nvo3-geneve] o GUE [I-D.ietf-intarea-gue] * What is the point in having a codepoint but no actual usage is defined for it? I also think > that there is another consideration that might be of greater impact. > > The definition of interface types has long been an IANA registry which > has been incorporated into MIB modules and, latterly, YANG modules. > Recently, there has been an I-D > Guidelines and Registration Procedures for Interface Types > with Authors : David Thaler Dan Romascanu > which, if I read it aright, is saying that the process has gone off the > rails and that the IANA registry should be of Interface Types and > nothing to do with MIB modules or YANG modules, although the YANG and > MIB modules will most likely be derived from it. I see it as a question > of who owns the registry, and that it should be those concerned with > interfaces and their specification and that those concerned with OAM > should take second place to that. > > If that logic is correct, then I would apply it to tunnels, that the > registration of tunnels belongs to those concerned with tunnels, > int-area perhaps, where I see drafts on tunnels being discussed, with > those concerned with OAM building on that work but not being the > drivers, controllers, thereof. > > Tom Petch > > > 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? > >
- [Softwires] Tsvart last call review of draft-ietf… David Black via Datatracker
- Re: [Softwires] Tsvart last call review of draft-… Rajiv Asati (rajiva)
- Re: [Softwires] Tsvart last call review of draft-… Black, David
- Re: [Softwires] Tsvart last call review of draft-… mohamed.boucadair
- Re: [Softwires] Tsvart last call review of draft-… Black, David
- Re: [Softwires] Tsvart last call review of draft-… mohamed.boucadair
- Re: [Softwires] Tsvart last call review of draft-… tom petch
- Re: [Softwires] Tsvart last call review of draft-… mohamed.boucadair
- Re: [Softwires] [Tsv-art] Tsvart last call review… Magnus Westerlund
- Re: [Softwires] [Tsv-art] Tsvart last call review… mohamed.boucadair
- Re: [Softwires] Tsvart last call review of draft-… Eric Vyncke (evyncke)
- Re: [Softwires] Tsvart last call review of draft-… Suresh Krishnan
- Re: [Softwires] Tsvart last call review of draft-… Eric Vyncke (evyncke)
- Re: [Softwires] Tsvart last call review of draft-… mohamed.boucadair
- Re: [Softwires] Tsvart last call review of draft-… Eric Vyncke (evyncke)
- Re: [Softwires] [Tsv-art] Tsvart last call review… Mirja Kuehlewind
- Re: [Softwires] Tsvart last call review of draft-… Rajiv Asati (rajiva)
- Re: [Softwires] Tsvart last call review of draft-… tom petch
- Re: [Softwires] Tsvart last call review of draft-… tom petch
- Re: [Softwires] Tsvart last call review of draft-… mohamed.boucadair