Eric To be more concrete about the changes I propose to this I-D, after some off-list discussion. This I-D should ask IANA to insert the name tunnelType Definitions at the URL https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbe rs-6: to make it clear that this is the registry for tunnels not just a MIB module or an appendage to the interface registry [this also brings the IANA pages more in line with the instructions to IANA in this I-D] The Note proposed in this I-D should be expanded to say something along the lines of "Updates to this registry will propagate updates to both the IANA maintained ianaiftype-mib MIB module, as defined in RFC4087, and to the tunnelType YANG module, as defined in RFCXXXX" [the current proposed Note makes no mention of updating the MIB module, rather it takes it for granted that it will happen which the current IANA pages do not spell out] Alongside 'For a functional mib language definition ...' IANA should be asked to add a reference 'For a functional YANG language definition ...' This I-D makes no mention of the need for an integer associated with a new tunnel type which the YANG does not require but which the SMI does. I would prefer that this be mentioned in this I-D for completeness. Some or all of which I see as an update to RFC4087 Tom Petch ----- Original Message ----- From: "tom p." <daedulus@xxxxxxxxxxxxx> To: "Eric Vyncke (evyncke)" <evyncke@xxxxxxxxx>; "David Black" <david.black@xxxxxxxx>; <tsv-art@xxxxxxxx> Cc: <softwires@xxxxxxxx>; "ietf" <ietf@xxxxxxxx>; <draft-ietf-softwire-iftunnel.all@xxxxxxxx> Sent: Tuesday, June 04, 2019 5:36 PM > ----- 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. > > > > > > > > > > >
