----- Original Message ----- From: "Eric Vyncke (evyncke)" <evyncke@xxxxxxxxx> Sent: Tuesday, May 28, 2019 8:07 AM > Dear all, > > Thank you again for the review. > > After discussion with Dave Thaler (who maintains the tunnel type IANA registry), it appears that the draft can go forward without waiting for a complete IANA registry for tunnel types. Eric Accepting that not all tunnel types will be in the IANA YANG module, I think that there is another unresolved issue that I see as problematic. The I-D talks of the IANA tunnelType Table, as in s.4.2, but I see no such thing on the IANA website. There is a MIB module but that is not a registry. The referenced URL is Internet-standard MIB - mib-2.interface.ifTable.ifEntry.ifType.tunnelType a MIB module, not a registry. The treatment of interfaces and tunnels by IANA are different. Interfaces have a registry and when that is updated, that drives updates to a YANG module and a MIB module Tunnels do not have a registry, just a MIB module. Probably this I-D should create a registry of tunnels so that MIB and YANG tunnel modules can be updated in the same way as Interface ones are. As it is, I see nowhere for the new text relating to a YANG module to go in the existing IANA pages. I realise that the Expert Reviewer thinks he can manage but I want the IANA pages to make sense more widely than that. Tom Petch > > Best regards > > -éric > > On 08/05/2019, 00:45, "David Black via Datatracker" <noreply@xxxxxxxx> wrote: > > 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, and the > discussion of extension of this YANG module would need to be aligned with > that limited applicability. > > 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. > 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. > > > > >
