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

tom petch <daedulus@btconnect.com> Fri, 07 June 2019 11:40 UTC

Return-Path: <daedulus@btconnect.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 AEEEA1200E5; Fri, 7 Jun 2019 04:40:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.734
X-Spam-Level: *
X-Spam-Status: No, score=1.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FAKE_REPLY_C=1.486, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
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 R_MyCtMQZNiX; Fri, 7 Jun 2019 04:39:58 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40136.outbound.protection.outlook.com [40.107.4.136]) (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 BC408120130; Fri, 7 Jun 2019 04:39:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gHYDe+Ax2LGWCJLY4rq09MeiiJ4Tazp4SC4XFRG1ZlM=; b=rio4o6NSs/By5lWULoWaHkzaXy0KrDmFMDzlrD5UcYxQSOJgkt5I5YGGbFYzo2gnsQ/ONlsXiafEtMq3wQ4qBTDXBLCQE6HVNCiX8vhXNlFARfk9AjwJL0ZmW9Lu7nc6XU6TCx+YwsJPb6NtaNQaCfGQ2YwmVmxwv9Ns6QNRMVE=
Received: from AM6PR07MB5335.eurprd07.prod.outlook.com (20.177.198.213) by AM6PR07MB4502.eurprd07.prod.outlook.com (20.176.242.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.5; Fri, 7 Jun 2019 11:39:55 +0000
Received: from AM6PR07MB5335.eurprd07.prod.outlook.com ([fe80::551b:17a3:2ca8:f52c]) by AM6PR07MB5335.eurprd07.prod.outlook.com ([fe80::551b:17a3:2ca8:f52c%5]) with mapi id 15.20.1987.004; Fri, 7 Jun 2019 11:39:55 +0000
From: tom petch <daedulus@btconnect.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, David Black <david.black@dell.com>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "softwires@ietf.org" <softwires@ietf.org>, ietf <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: AQHVHSW6yBTo/YP1LUKSgwLuZh+4RQ==
Date: Fri, 7 Jun 2019 11:39:55 +0000
Message-ID: <01f601d51d25$22138e00$4001a8c0@gateway.2wire.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0007.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::19) To AM6PR07MB5335.eurprd07.prod.outlook.com (2603:10a6:20b:6c::21)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5852bcda-89e3-43e2-5922-08d6eb3cdc90
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:AM6PR07MB4502;
x-ms-traffictypediagnostic: AM6PR07MB4502:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <AM6PR07MB45020A7BBCF09FCF59A0A7EAC6100@AM6PR07MB4502.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0061C35778
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(136003)(346002)(396003)(39860400002)(13464003)(189003)(199004)(26005)(3846002)(14496001)(6116002)(81166006)(81156014)(966005)(102836004)(8676002)(5660300002)(66066001)(110136005)(54906003)(66446008)(99286004)(1556002)(4326008)(62236002)(229853002)(186003)(6486002)(8936002)(44716002)(81816011)(66574012)(81686011)(2501003)(52116002)(86362001)(486006)(71200400001)(71190400001)(6506007)(53936002)(256004)(25786009)(386003)(14454004)(478600001)(2906002)(44736005)(6246003)(73956011)(66946007)(64756008)(19627235002)(66476007)(9686003)(6512007)(14444005)(66556008)(6306002)(61296003)(50226002)(316002)(68736007)(476003)(4720700003)(305945005)(7736002)(6436002)(84392002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB4502; H:AM6PR07MB5335.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: KHxU/FOon1Xw1Wf2k8iD+C8BpjP3KMA23TS5tgHprmOhekPfkJ182ZsIgy4Gdj3ZKIeUohy/JQH00vdqGkWad3TVxKyAVE2UNUNh1/YQ4KLtx1M2ZRaVdO1hnOF6OxZRPriLJhzKiGmSOT+oKfjg9vVsJ38moWRsC0RA+R8U4pypa9dhKBiI6HR/LVAtogDfLOgIQOd0Z/qEjxU3qeNtpPZsIkXEoFtWIb9sr72u1UG6YfAZBFZjRMs+gKUkAvL96E2+GszGwQQLUDtO55In4PTPNHtAZ1e0i+3ZM9wRHM9ydizrXZ4UkX4M6/oVPwSUUOBhPmrfQIBG0P74LDrMI+rtUodPGwzcNAMI19pXCdL3zJIk49rXOcwLAMPFgSO+euJf5/EyPxvi16FN7Pt6wSiYQ6fnpypJfVeHSMXo6dw=
Content-Type: text/plain; charset="utf-8"
Content-ID: <C6934C0DAA55224A9B7AD013316BCBCA@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5852bcda-89e3-43e2-5922-08d6eb3cdc90
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2019 11:39:55.6053 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: daedulus@btconnect.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4502
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/7rEwFTe_n893bZoInZeA0sTZdMw>
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, 07 Jun 2019 11:40:01 -0000

Eric

To be more concrete about the changes I propose to this I-D, after some
off-list discussion.

This I-D should ask IANA to insert the name
tunnelType Definitions
at the URL
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbe
rs-6:
to make it clear that this is the registry for tunnels not just a MIB
module or an appendage to the interface registry
[this also brings the IANA pages more in line with the instructions to
IANA in
this I-D]

The Note proposed in this I-D should be expanded to say something along
the lines of

"Updates to this registry will propagate updates to both the IANA
maintained ianaiftype-mib MIB module, as defined in RFC4087, and to the
tunnelType YANG module, as defined in RFCXXXX"

[the current proposed Note makes no mention of updating the MIB module,
rather it takes it for granted that it will happen which the current
IANA pages do not spell out]

Alongside
'For a functional mib language definition ...'
IANA should be asked to add a reference
'For a functional YANG language definition ...'

This I-D makes no mention of the need for an integer associated with a
new tunnel type which the YANG does not require but which the SMI does.
I would prefer that this be mentioned in this I-D for completeness.

Some or all of which I see as an update to RFC4087

Tom Petch

----- Original Message -----
From: "tom p." <daedulus@btconnect.com>;
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>;; "David Black"
<david.black@dell.com>;; <tsv-art@ietf.org>;
Cc: <softwires@ietf.org>;; "ietf" <ietf@ietf.org>;;
<draft-ietf-softwire-iftunnel.all@ietf.org>;
Sent: Tuesday, June 04, 2019 5:36 PM

> ----- Original Message -----
> From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>;
> Sent: Tuesday, May 28, 2019 8:07 AM
>
> > Dear all,
> >
> > Thank you again for the review.
> >
> > After discussion with Dave Thaler (who maintains the tunnel type
IANA
> registry), it appears that the draft can go forward without waiting
for
> a complete IANA registry for tunnel types.
>
> Eric
>
> Accepting that not all tunnel types will be in the IANA YANG module, I
> think that there is another unresolved issue that I see as
problematic.
>
> The I-D talks of the IANA tunnelType Table, as in s.4.2, but I see no
> such thing on the IANA website. There is a MIB module but that is not
a
> registry.  The referenced URL is
> Internet-standard MIB -
> mib-2.interface.ifTable.ifEntry.ifType.tunnelType
> a MIB module, not a registry.
>
> The treatment of interfaces and tunnels by IANA are different.
> Interfaces have a registry and when that is updated, that drives
updates
> to a YANG module and a MIB module
>
> Tunnels do not have a registry, just a MIB module.  Probably this I-D
> should create a registry of tunnels so that MIB and YANG tunnel
modules
> can be updated in the same way as Interface ones are.  As it is, I see
> nowhere for the new text relating to a YANG module to go in the
existing
> IANA pages.
>
> I realise that the Expert Reviewer thinks he can manage but I want the
> IANA pages to make sense more widely than that.
>
> Tom Petch
>
> >
> > Best regards
> >
> > -éric
> >
> > On 08/05/2019, 00:45, "David Black via Datatracker"
> <noreply@ietf.org>; wrote:
> >
> >     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, and the
> >     discussion of extension of this YANG module would need to be
> aligned with
> >     that limited applicability.
> >
> >     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.
> >     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.
> >
> >
> >
> >
> >
>