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?
