Hi Tom, Please see inline.
Cheers, Med > -----Message d'origine----- > De : tom petch [mailto:[email protected]] > Envoyé : mardi 30 octobre 2018 13:07 > À : BOUCADAIR Mohamed TGI/OLN; [email protected] > Objet : Re: [Int-area] registering tunnel types > > ----- 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. [Med] Yes, the I-D requests assigning a code from that 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 [Med] Values can be assigned without requiring a MIB or even an RFC. Please check the list at https://www.iana.org/assignments/smi-numbers/smi-numbers..xhtml#smi-numbers-5 Also, note that RFC2863 states the following: === 3.1.10. Addition of New ifType values Over time, there is the need to add new ifType enumerated values for new interface types. If the syntax of ifType were defined in the MIB in section 6, then a new version of this MIB would have to be re- issued in order to define new values. In the past, re-issuing of a MIB has occurred only after several years. Therefore, the syntax of ifType is changed to be a textual convention, such that the enumerated integer values are now defined in the textual convention, IANAifType, defined in a different document. This allows additional values to be documented without having to re-issue a new version of this document. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new ifType values. === And RFC4087: The assignment policy for IANAtunnelType values is identical to the policy for assigning IANAifType values. So, it is completely fine to register a new IANAtunnelType without having a MIB module. (adding a new numeric value which YANG does not have - I > assume that the designated expert will assign a value). [Med] Yes, assigning a new code is subject to the expert review....as usual.. 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 [Med] This is the normal process. https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-5 says the following: "For every ifType registration, the corresponding transmission number value should be registered or marked "Reserved." In addition, the [IANAifType-MIB] and [iana-if-type YANG] modules should be updated in accordance with [RFC2863] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ and [RFC7224], respectively." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > '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. [Med] The corresponding enumeration in the in the IANAifType-MIB (https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib) is IANAtunnelType. What is wrong with that, Tom? > > 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? [Med] The yang doctor is happy with the design in the softwire I-D. > > Is the Designated Expert for the MIB module ok to take over the > responsibility for making additions to a YANG Module? [Med] This is not a valid question. We don't ask the Designated Expert to make addition to a YANG module, but to an existing registry following existing procedures. > > And I think that the current reference to RFC4087 for tunnelType in IANA > needs updating. > [Med] RFC4087 is the current authoritative reference we have as per the IANA-maintained registry. > 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
