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

[<[e-mail]>]

Hi Martin,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Vigoureux, Martin (Nokia - FR/Paris-Saclay)
> [mailto:[e-mail]]
> Envoyé : jeudi 13 juin 2019 09:44
> À : BOUCADAIR Mohamed TGI/OLN; The IESG
> Cc : [e-mail]; Yong Cui; softwire-
> [e-mail]; [e-mail]
> 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, [e-mail] a écrit :
> > Hi Martin,
> >
> > Thank you for the comment.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Martin Vigoureux via Datatracker [mailto:[e-mail]]
> >> Envoyé : mardi 11 juin 2019 18:58
> >> À : The IESG
> >> Cc : [e-mail]; Yong Cui; softwire-
> >> [e-mail]; [e-mail]; [e-mail]
> >> 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.
> >