----- Original Message ----- From: <[email protected]> To: "tom petch" <[email protected]>; <[email protected]> Sent: Monday, October 29, 2018 10:42 AM
Hi Tom, all, In order to provide a full context, below some precisions: * draft-ietf-softwire-yang DOES NOT create a new registry for maintaining tunnel types nor changes the procedure to assign new code points. Such register does already exist: https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbe rs-6. * draft-ietf-softwire-yang creates a YANG module which **maintained by IANA**; that is, upon assignment of a new code by IANA, the module is updated automatically by IANA. * draft-ietf-softwire-yang augments the interface YANG module with aplusp specific nodes. To do so, it requires the tunnel type to be set to aplusp. <tp> Med I think that there is a little more to it than that. There is indeed an existing tunnel type registry in the SMI Group for use by MIB modules. The I-D requests an addition to the tunnel type registry. I think that all previous such requests in an RFC have come along with a MIB and then a subset of the MIB information has been added to the related YANG module. Here the process is reversed and so we are implicitly updating the MIB module (adding a new numeric value which YANG does not have - I assume that the designated expert will assign a value). It should work but is a new and different process. The IANA Considerations in this I-D seem to neglect the need to update, the impact on, the tunnel MIB module. The I-D does say 'The name of the "identity" is the same as the corresponding enumeration in the IANAifType-MIB. ' which is wrong - we are dealing with tunnelType not ifType here. More widely, should we cater for a definition which is YANG only, or is it still right to keep the MIB and YANG modules in line? Does the NETMOD WG have a view on this? Is the Designated Expert for the MIB module ok to take over the responsibility for making additions to a YANG Module? And I think that the current reference to RFC4087 for tunnelType in IANA needs updating. To me, there are a number of ramifications spreading out across the IETF and I doubt if I can see them all. Tom Petch Cheers, Med > -----Message d'origine----- > De : Int-area [mailto:[email protected]] De la part de tom petch > Envoyé : vendredi 26 octobre 2018 14:05 > À : [email protected] > Objet : [Int-area] registering tunnel types > > I am not sure where tunnels have a home in the IETF but for anyone with > an interest in them, draft-ietf-softwire-yang, having completed IETF > Last Call two weeks ago, has since acquired a YANG module for tunnel > types, based on the Tunnel MIB, RFC4087, which seems not to have been > turned into a YANG module before. > > I am unsure where the place to discuss such a topic is; softwires, which > owns the I-D containing the module, would be the place for aplusp but > perhaps not for the others. I have forwarded this to 6man thinking that > they would have an interest. > > The I-D has been revised five times since Last Call completed and I have > suggested that it needs to go back to softwires for them to agree this > is really what they want before the I-D goes any further. > > Tom Petch > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
