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

"Black, David" <David.Black@dell.com> Thu, 09 May 2019 13:46 UTC

Return-Path: <David.Black@dell.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 A7B621200C1; Thu, 9 May 2019 06:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=HHR4LUom; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=QMy09YH2
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 vSnXGyfgVS5z; Thu, 9 May 2019 06:46:19 -0700 (PDT)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7765F1200DB; Thu, 9 May 2019 06:46:19 -0700 (PDT)
Received: from pps.filterd (m0170397.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x49DjALg020278; Thu, 9 May 2019 09:46:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=/kcGwcuxl9K2vr0dQv12NcPbZMnN9T2DILe4LTMrenM=; b=HHR4LUomsxLdzzqyNWXJAAMBeI69RNeQ6wZQSPefX0hlcqC3cMhKjd+nAxnd376Kr/6r L5Fe3eL2ek4Urr8xd3x7RmGM3OD2jy67ukQYVSfo4F3XZpLCnJ9xCocVD/Fz9Uf3dF8+ /6ADR115lDhQNAPy10kaACQauj4+I7CcoCYo/+TwwBgVKkLA2sJi7qeSwQ9rNO3IUVi+ wrMpemYKU/wnJdisjdXohZp7W1EHE2NECKcg5TrMEdI6WYc0ypMc5qIMrKrVOaJEe/T5 3CS6EQXpvj5kW6tz+FL/xW/uMFbWwDfmZ/N1m1jf4+nlG0vYO+7y7ZL5L7Zwt9AqEI/X Fg==
Received: from mx0a-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2sc9gva8u6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 May 2019 09:46:17 -0400
Received: from pps.filterd (m0089484.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x49Dhfnf038877; Thu, 9 May 2019 09:46:17 -0400
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by mx0b-00154901.pphosted.com with ESMTP id 2sch90c10k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 09 May 2019 09:46:16 -0400
Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x49DkEbo001241 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 May 2019 09:46:15 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x49DkEbo001241
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1557409576; bh=920loiombZtWVzeK520G6aX9by0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=QMy09YH2Xw7qnvX+WpYoGVLM2ddyFVSBSTFhT4uowfprbfHtN8m0T4k1AaapjTdKv AO0GGGoY0hSwrpVmlSG6mJ8UQSHML+DAJ/WmUgfdYKJN7sj5KOFV6rwZzZa82MNS0H YaaXFhMqK95dMtl607HvYchH8kw6xOPw53rwMwbU=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x49DkEbo001241
Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd02.lss.emc.com (RSA Interceptor); Thu, 9 May 2019 09:45:39 -0400
Received: from MXHUB304.corp.emc.com (MXHUB304.corp.emc.com [10.146.3.30]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x49Djseh027924 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Thu, 9 May 2019 09:45:54 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB304.corp.emc.com ([10.146.3.30]) with mapi id 14.03.0439.000; Thu, 9 May 2019 09:45:53 -0400
From: "Black, David" <David.Black@dell.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.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>, "Black, David" <David.Black@dell.com>
Thread-Topic: Tsvart last call review of draft-ietf-softwire-iftunnel-04
Thread-Index: AQHVBjvLoGotpmycT0al8kNJQOcXkqZiy2vA
Date: Thu, 09 May 2019 13:45:53 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949363055C97D@MX307CL04.corp.emc.com>
References: <155726915148.24435.7582686501694078061@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA7A76F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA7A76F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.21.130]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-09_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905090083
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905090083
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/YirfmFSKGYI11yksf1z5z2eo5Kc>
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: Thu, 09 May 2019 13:46:23 -0000

> [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?