Re: [Softwires] Martin Vigoureux's No Objection on draft-ietf-softwire-iftunnel-06: (with COMMENT)

"Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <> Thu, 13 June 2019 07:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 417D31200F5; Thu, 13 Jun 2019 00:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E1CbkewzCEiS; Thu, 13 Jun 2019 00:44:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A7CF91200CE; Thu, 13 Jun 2019 00:44:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uHOCvrwaUyH5/HTZNckwvHa7R58Hxh9S4A3SHadOQWk=; b=lVDPm9F+dXruqcLIfkGs7xZk+HSRE/6h6dQVhOeA37T+QsZTgjUq3nQrIM8xv0wELe5MHDlrwP2pv9kacUwRD60Snea3+bRuHKdAnFTen8hvl/jgXd6gts1Uy7FbzqgKUFZJ3i5ubPTES4bm6Yv1tD4ZVMDIm8SJhF6an/6GHL0=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.8; Thu, 13 Jun 2019 07:43:59 +0000
Received: from ([fe80::24d2:40d2:ef60:7a05]) by ([fe80::24d2:40d2:ef60:7a05%7]) with mapi id 15.20.1987.010; Thu, 13 Jun 2019 07:43:59 +0000
From: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <>
To: "" <>, The IESG <>
CC: "" <>, Yong Cui <>, "" <>, "" <>
Thread-Topic: Martin Vigoureux's No Objection on draft-ietf-softwire-iftunnel-06: (with COMMENT)
Thread-Index: AQHVIbvDyJ3cjs5bNUuk13850UgmJQ==
Date: Thu, 13 Jun 2019 07:43:59 +0000
Message-ID: <>
References: <> <787AE7BB302AE849A7480A190F8B93302EAA54A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAA54A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
x-clientproxiedby: PR0P264CA0056.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1d::20) To (2603:10a6:5:7::32)
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 55d3e556-8220-461c-8d2e-08d6efd2e52c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DB7PR07MB5772;
x-ms-traffictypediagnostic: DB7PR07MB5772:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0067A8BA2A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(396003)(366004)(136003)(346002)(51234002)(189003)(199004)(6306002)(14454004)(68736007)(53936002)(966005)(65826007)(102836004)(478600001)(65806001)(65956001)(66066001)(8676002)(31686004)(66574012)(7736002)(305945005)(6512007)(26005)(81166006)(81156014)(8936002)(5660300002)(11346002)(4326008)(31696002)(2501003)(73956011)(66556008)(229853002)(64126003)(446003)(36756003)(6486002)(6436002)(76176011)(2906002)(25786009)(52116002)(86362001)(99286004)(476003)(186003)(64756008)(3846002)(6246003)(66476007)(6506007)(386003)(6116002)(71200400001)(66946007)(66446008)(58126008)(14444005)(110136005)(256004)(316002)(71190400001)(54906003)(2616005)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB5772;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: F03+uX7kZzxYGNKUNGN1Z/+YXVs4Kzx2MQq6LwpuUJAk6pKEITAmko9jsUenfrCCx0rql/2n8Ry4e+iemjgDUcJYjfkXHSS/sdd9inUGRpsqaHx8uNuVG/xbKUCS0shLRc0cauVfJNKHi1pXFExFikzogt+6zB5jNVQFWyo43oXreSQRh1zTKuEkx6J9S5pmKfdZhxV2Hte7UqoacO74UTqlKvakPZjGCO+Npykc83xqvuoTRhTGJwiA/xbiDw+exNAxaaSHRh10GyCrNk1G4qgkpe2PWs0AG2EhtNVBBlx3yqhCWEDHqo2D1gS/5awrZ1I+AGTz7Q3rtKVwyVdRdIqG2I+eo+E2cU48mKVJaxnljFXrymAKWGz/Sjp6JoYPgSBAN0aFqzeA5jRhJLXY5gwl+7m9xTsFoI9HXWoCJXs=
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 55d3e556-8220-461c-8d2e-08d6efd2e52c
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2019 07:43:59.5621 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5772
Archived-At: <>
Subject: Re: [Softwires] Martin Vigoureux's No Objection on draft-ietf-softwire-iftunnel-06: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: softwires wg discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Jun 2019 07:44:07 -0000

Hi Med,

please see inline


Le 2019-06-12 à 7:31, a écrit :
> Hi Martin,
> Thank you for the comment.
> Please see inline.
> Cheers,
> Med
>> -----Message d'origine-----
>> De : Martin Vigoureux via Datatracker []
>> Envoyé : mardi 11 juin 2019 18:58
>> À : The IESG
>> Cc :; Yong Cui; softwire-
>> Objet : Martin Vigoureux's No Objection on draft-ietf-softwire-iftunnel-
>> 06: (with COMMENT)
>> Martin Vigoureux has entered the following ballot position for
>> draft-ietf-softwire-iftunnel-06: No Objection
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> Please refer to
>> for more information about IESG DISCUSS and COMMENT positions.
>> The document, along with other ballot positions, can be found here:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> Hello,
>> I am a bit puzzled because the Abstract recognizes that the document is
>> built
>> onto an incomplete data-set and that makes me wonder whether the model
>> will be
>> usable until the data-set is completed.
> [Med] The registry does not need to be comprehensive to be useful/usable. For example, this module is already used by a document which is in the RFC Editor queue: draft-ietf-softwire-yang.
>> Also, I really do not understand the update you propose to the registry.
>> It
>> seems that you point to the technology spec rather than to the original
>> mib
>> module definition, but I quickly looked and none of the specs I parsed
>> define
>> the mib entry/value
> [Med] This update was requested by the Designated Experts. They want the technology spec to be cited, not the RFC defining the MIB or YANG. Please note that registering a code does not require a MIB or a YANG.
That is exactly my point. 
is the MIB module registration so it should reference the RFCs which 
created the module and asked for the registration of the codes. As an 
illustrative example, 7856 is the RFC which asked for the registration 
of softwireMesh(16). I couldn't find any such request in 5565. So I 
really don't think you should remove 7856 from the references, but it is 
definitly good to add 5565.
After a quick glance, this seems to be the case for all changes you are 

> , so getting rid of the existing reference appears to
>> me as
>> a clear loss of information. I think you should keep the original
>> reference and
>> add a new one if needed, but not simply replace.
>> And if you have undertaken this effort of tidying the registry, why not
>> complete it with the missing values?
> [Med] We used to have this discussion as part of the tsv directorate review. We don't think it is the job of this document to register new tunnel techniques to an existing registry. Nevertheless, we tried to get in touch with the authors of draft-ietf-lisp-rfc6830bis, draft-ietf-nvo3-vxlan-gpe, draft-ietf-nvo3-geneve, and draft-ietf-intarea-gue to invite them to register their tunnel technology.
> The I-D is mirroring the content of an * existing * registry. The corresponding YANG module will be updated by IANA upon assignment of a new code.