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? > >
