Hi, Based on Tom's comment about the issues or discrepancies in purpose, I would like to request that the purpose of the iftunnel document is made clear at least in a email response. As not being active and being thrown under the bus of having to do an IESG review of this document it would be really good if you could provide some summary of the context and the need for this particular document. Especially in light of how it uses the IANA registry. Thanks Magnus Westerlund On 2019-05-10 08:20, mohamed.boucadair@xxxxxxxxxx wrote: > Hi Tom, > > Thanks for sharing your thoughts. > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : tom petch [mailto:daedulus@xxxxxxxxxxxxx] >> Envoyé : jeudi 9 mai 2019 18:13 >> À : Black, David; BOUCADAIR Mohamed TGI/OLN; tsv-art@xxxxxxxx >> Cc : softwires@xxxxxxxx; Black, David; ietf@xxxxxxxx; draft-ietf-softwire- >> iftunnel.all@xxxxxxxx >> Objet : Re: Tsvart last call review of draft-ietf-softwire-iftunnel-04 >> >> ----- Original Message ----- >> From: "Black, David" <David.Black@xxxxxxxx> >> Sent: Thursday, May 09, 2019 2:45 PM >> >>>> [Med] The intent of the draft is to reflect the current registered >> tunnels types. >>> ... >>>> [Med] Registering new tunnel types is not in the scope set for this >> draft. >>> I understand that, but as stated in the review, I don't think that >> it's the best course of action. The email below appears to reject all >> of the IETF Last Call comments in the review and in particular presents >> the scope of the draft as fixed and unchangeable; that's unfortunate. >> On that basis, I will agree to disagree and leave these IETF Last Call >> concerns to the ADs to sort out. >> David >> >> I think that the concerns that you raise need addressing. > [Med] It is an easy fix to update the draft with a table asking codes for the following example list: > > o CAPWAP [RFC5415] > o AMT [RFC7450] > o TCP Encapsulation of IKE and IPsec Packets [RFC8229] > o NSH [RFC8300] > o VXLAN [RFC7348] > o LISP [RFC6830bis] > o VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] > o Geneve [I-D.ietf-nvo3-geneve] > o GUE [I-D.ietf-intarea-gue] > > but I'm struggling with the rationale for doing this in draft-ietf-softwire-iftunnel. > > Can you please help me understand the following: > > * Why such request wasn't made earlier for the following? > > o CAPWAP [RFC5415] > o AMT [RFC7450] > o TCP Encapsulation of IKE and IPsec Packets [RFC8229] > o NSH [RFC8300] > o VXLAN [RFC7348] > > * Why working in progress specifications can't make this request directly to IANA if such code is needed? > > o LISP [RFC6830bis] > o VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] > o Geneve [I-D.ietf-nvo3-geneve] > o GUE [I-D.ietf-intarea-gue] > > * What is the point in having a codepoint but no actual usage is defined for it? > > > I also think >> that there is another consideration that might be of greater impact. >> >> The definition of interface types has long been an IANA registry which >> has been incorporated into MIB modules and, latterly, YANG modules. >> Recently, there has been an I-D >> Guidelines and Registration Procedures for Interface Types >> with Authors : David Thaler Dan Romascanu >> which, if I read it aright, is saying that the process has gone off the >> rails and that the IANA registry should be of Interface Types and >> nothing to do with MIB modules or YANG modules, although the YANG and >> MIB modules will most likely be derived from it. I see it as a question >> of who owns the registry, and that it should be those concerned with >> interfaces and their specification and that those concerned with OAM >> should take second place to that. >> >> If that logic is correct, then I would apply it to tunnels, that the >> registration of tunnels belongs to those concerned with tunnels, >> int-area perhaps, where I see drafts on tunnels being discussed, with >> those concerned with OAM building on that work but not being the >> drivers, controllers, thereof. >> >> Tom Petch >> >>> Thanks, --David >>> >>>> -----Original Message----- >>>> From: mohamed.boucadair@xxxxxxxxxx >>>> <mohamed.boucadair@xxxxxxxxxx> >>>> Sent: Thursday, May 9, 2019 3:50 AM >>>> To: Black, David; tsv-art@xxxxxxxx >>>> Cc: softwires@xxxxxxxx; ietf@xxxxxxxx; >> draft-ietf-softwire-iftunnel.all@xxxxxxxx >>>> Subject: RE: Tsvart last call review of >> draft-ietf-softwire-iftunnel-04 >>>> >>>> [EXTERNAL EMAIL] >>>> >>>> Hi David, >>>> >>>> Thank you for the review. >>>> >>>> Please see inline. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : David Black via Datatracker [mailto:noreply@xxxxxxxx] >>>>> Envoyé : mercredi 8 mai 2019 00:46 >>>>> À : tsv-art@xxxxxxxx >>>>> Cc : softwires@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-softwire- >>>>> iftunnel.all@xxxxxxxx >>>>> Objet : Tsvart last call review of draft-ietf-softwire-iftunnel-04 >>>>> >>>>> 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@xxxxxxxx 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, >>>> [Med] The intent of the draft is to reflect the current registered >> tunnels >>>> types. This is mentioned in the introduction: >>>> >>>> This document specifies the initial version of the >> iana-tunnel-type >>>> ^^^^^^^^^^^^^^ >>>> YANG module identifying tunnel interface types. The module >> reflects >> ^^^^^^^^ >>>> IANA's registry maintained at [TUNNELTYPE-IANA-REGISTRY]. The >> latest >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> revision of this module can be obtained from the IANA web site. >>>> >>>> and the >>>>> discussion of extension of this YANG module would need to be >> aligned >>>> with >>>>> that limited applicability. >>>> [Med] This is an IANA-maintained module. That is, when a new tunnel >> type is >>>> registered, the module will be automatically updated to include that >> new >>>> type identity: >>>> >>>> When this registry is modified, the YANG module >> iana-tunnel-type >>>> must be updated as defined in RFCXXXX. >>>> >>>>> 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. >>>> [Med] Registering new tunnel types is not in the scope set for this >> draft. It is >>>> up to the documents defining these tunnel types or making use of >> them to >>>> make a request to IANA. For example, this is the approach followed >> in >>>> softwire wg for at least three tunnel types (16, 17, 18). >>>> >>>>> 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. >>>>> >>>> [Med] Wouldn't that recommendation be better added to documents such >>>> as: https://tools.ietf.org/html/draft-thaler-iftype-reg-02? > _______________________________________________ > Tsv-art mailing list > Tsv-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/tsv-art > -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx ----------------------------------------------------------------------
