Hi Martin, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Vigoureux, Martin (Nokia - FR/Paris-Saclay) > [mailto:martin.vigour...@nokia.com] > Envoyé : jeudi 13 juin 2019 09:44 > À : BOUCADAIR Mohamed TGI/OLN; The IESG > Cc : draft-ietf-softwire-iftun...@ietf.org; Yong Cui; softwire- > cha...@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.boucad...@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:nore...@ietf.org] > >> Envoyé : mardi 11 juin 2019 18:58 > >> À : The IESG > >> Cc : draft-ietf-softwire-iftun...@ietf.org; Yong Cui; softwire- > >> cha...@ietf.org; cuiy...@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. > > _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
