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

<mohamed.boucadair@orange.com> Thu, 13 June 2019 09:23 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 87FDD120291; Thu, 13 Jun 2019 02:23:09 -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 bqN84jOl0EKW; Thu, 13 Jun 2019 02:23:07 -0700 (PDT)
Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7501200D8; Thu, 13 Jun 2019 02:23:06 -0700 (PDT)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 45PdZK1b4zz21KD; Thu, 13 Jun 2019 11:23:05 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 45PdZK0vpbzyPk; Thu, 13 Jun 2019 11:23:05 +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; Thu, 13 Jun 2019 11:23:04 +0200
From: <mohamed.boucadair@orange.com>
To: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <martin.vigoureux@nokia.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-softwire-iftunnel@ietf.org" <draft-ietf-softwire-iftunnel@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>, "softwire-chairs@ietf.org" <softwire-chairs@ietf.org>, "softwires@ietf.org" <softwires@ietf.org>
Thread-Topic: Martin Vigoureux's No Objection on draft-ietf-softwire-iftunnel-06: (with COMMENT)
Thread-Index: AQHVIbvDyJ3cjs5bNUuk13850UgmJaaZTV7A
Date: Thu, 13 Jun 2019 09:23:04 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EAA60F8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <156027229257.30949.8281092047545393602.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EAA54A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <12df9203-f831-c56f-599f-9140750c04f4@nokia.com>
In-Reply-To: <12df9203-f831-c56f-599f-9140750c04f4@nokia.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/softwires/DcGBNZ6OU3ad3rRSt6qQ7aXwnoQ>
Subject: Re: [Softwires] Martin Vigoureux's No Objection on draft-ietf-softwire-iftunnel-06: (with COMMENT)
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, 13 Jun 2019 09:23:09 -0000

Hi Martin,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Vigoureux, Martin (Nokia - FR/Paris-Saclay)
> [mailto:martin.vigoureux@nokia.com]
> Envoyé : jeudi 13 juin 2019 09:44
> À : BOUCADAIR Mohamed TGI/OLN; The IESG
> Cc : draft-ietf-softwire-iftunnel@ietf.org; Yong Cui; softwire-
> chairs@ietf.org; softwires@ietf.org
> Objet : Re: Martin Vigoureux's No Objection on draft-ietf-softwire-
> iftunnel-06: (with COMMENT)
> 
> Hi Med,
> 
> please see inline
> 
> -m
> 
> Le 2019-06-12 à 7:31, mohamed.boucadair@orange.com a écrit :
> > Hi Martin,
> >
> > Thank you for the comment.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Martin Vigoureux via Datatracker [mailto:noreply@ietf.org]
> >> Envoyé : mardi 11 juin 2019 18:58
> >> À : The IESG
> >> Cc : draft-ietf-softwire-iftunnel@ietf.org; Yong Cui; softwire-
> >> chairs@ietf.org; cuiyong@tsinghua.edu.cn; softwires@ietf.org
> >> 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 https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> >> for more information about IESG DISCUSS and COMMENT positions.
> >>
> >>
> >> The document, along with other ballot positions, can be found here:
> >> https://datatracker.ietf.org/doc/draft-ietf-softwire-iftunnel/
> >>
> >>
> >>
> >> ----------------------------------------------------------------------
> >> COMMENT:
> >> ----------------------------------------------------------------------
> >>
> >> 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.
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-
> numbers-6
> is the MIB module registration so it should reference the RFCs which
> created the module and asked for the registration of the codes.

[Med] This is the kind of clarification in draft-thaler. The registry should not be understood as tied to MIBs. It isn't. 

 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
> proposing.

[Med] That is on purpose. The agreement we had with the Designed expert is: reference the documents that define the actual encapsulation, not the MIB module RFCs.

> 
> >
> > , 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.
> >