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

<mohamed.boucadair@orange.com> Mon, 20 May 2019 07:39 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 02BEE12013D; Mon, 20 May 2019 00:39:24 -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 pVxiG6GB4q7u; Mon, 20 May 2019 00:39:22 -0700 (PDT)
Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA76120049; Mon, 20 May 2019 00:39:21 -0700 (PDT)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 456rPh3mq3z5xcq; Mon, 20 May 2019 09:39:20 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 456rPh2z9pzDq7d; Mon, 20 May 2019 09:39:20 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM24.corporate.adroot.infra.ftgroup ([fe80::b43f:9973:861e:42af%21]) with mapi id 14.03.0439.000; Mon, 20 May 2019 09:39:20 +0200
From: mohamed.boucadair@orange.com
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, "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>, "draft-thaler-iftype-reg.authors@ietf.org" <draft-thaler-iftype-reg.authors@ietf.org>
Thread-Topic: Tsvart last call review of draft-ietf-softwire-iftunnel-04
Thread-Index: AQHVBSapff5w91BJLEieNwQUv+aBKaZibUIAgABjeoCADNEFAIAEDiwg
Date: Mon, 20 May 2019 07:39:19 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA8B9BD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <155726915148.24435.7582686501694078061@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA7A76F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CE03DB3D7B45C245BCA0D243277949363055C97D@MX307CL04.corp.emc.com> <1A44EACD-5C2E-4E26-B514-42C3CE6A1801@cisco.com>
In-Reply-To: <1A44EACD-5C2E-4E26-B514-42C3CE6A1801@cisco.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/B-92iDoEWrdPDgHMrGeMRrpGr1g>
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: Mon, 20 May 2019 07:39:24 -0000

Hi Eric, all,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Eric Vyncke (evyncke) [mailto:evyncke@cisco.com]
> Envoyé : vendredi 17 mai 2019 17:29
> À : Black, David; BOUCADAIR Mohamed TGI/OLN; tsv-art@ietf.org
> Cc : softwires@ietf.org; ietf@ietf.org; draft-ietf-softwire-
> iftunnel.all@ietf.org; draft-thaler-iftype-reg.authors@ietf.org
> Objet : Re: Tsvart last call review of draft-ietf-softwire-iftunnel-04
> 
> Dan and David, I took the liberty to add you to the discussion as draft-
> thaler-iftype-reg could be a way forward.
> 
> David, thank you for your review and the raised point.
> 
> Tom, and Magnus, thank you as well for being part of the discussion.
> 
> David, I see your point about referring to an 'outdated hence invalid'
> reference. I think we all agree that we need to have a IANA registry of
> ifTypes per draft-thaler-iftype-reg.
> 
> Nevertheless, I do not want to delay this document until that registry is
> created by the IANA as at least one other document depends on this one.

[Med] draft-thaler-iftype-reg does not create any new registry.

> Furthermore, I am unsure about the will of Dave & Dan to push forward
> their I-D.
> 
> Med, can you have a -06 revision with:
> - clearer abstract (basically  copy & paste of the 1st paragraph of the
> introduction) with the specific limitations / restrictions pointed by the
> reviews (for example "... containing the limited and incomplete collection
> of IANA...")

[Med] I can update the abstract as follows: 

OLD: 
   This document specifies a YANG module containing a collection of IANA
   maintained YANG identities, used as interface types for tunnel
   interfaces.

NEW:
   This document specifies the initial version of a YANG module
   containing a collection of IANA maintained YANG identities, used as
   interface types for tunnel interfaces.  The module reflects the
   "ifType definitions: tunnelType" registry maintained by IANA.  The
   latest revision of this module can be obtained from the IANA web
   site.

> - what about adding some text about "Upon the create of a IANA registry of
> ifType, then an update of this document will be required". Unsure whether
> it has ever been used in a RFC though.

[Med] I'm not sure about this one. As mentioned above, there is no current plan to create another yet iftype registry.

If the point is how the module will be updated if new entries are registered? Then, this is not a concern because the module is maintained by IANA; that is, any change to the register will be systematically reflected by IANA in the IANA module.

For example, registration requests for new tunnel types can made following the rules in draft-thaler-iftype-reg. Once granted, the iftunnel module be updated by IANA following the rules defined in draft-ietf-softwire-iftunnel. No RFC update is required. 

> 
> But, at least fix the abstract and be more restrictive on the 'value' of
> the current ifType MIB
> 
> Hope this will allow the document to progress
> 
> -éric
> 
> On 09/05/2019, 15:46, "Black, David" <David.Black@dell.com> wrote:
> 
>     > [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?
>