Subject: [Int-area] registering tunnel types

From: tom petch <[email-masked]>
Date: Fri, 26 Oct 2018 12:05:14 +0000

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 26 Oct 2018 07:40:06 -0700

Tom,

Tunnels seem to be ubiquitous in the IETF, as in the Internet.

IMO:
	A over B, which is typically more like A over X over B (requiring a shim), belongs where A belongs.

The point is that this tunnel is trying to create a new version of service A that needs to behave exactly like A. It typically isn’t changing B.

That said, if there are extensions to B required, then they need ALSO be reviewed where B belongs, but IMO only in concert with A being where A belongs.

I.e., that’s why the IP over * tunnels draft (draft-ietf-intarea-tunnels) is in intarea.

Joe

> On Oct 26, 2018, at 5:05 AM, tom petch <[email-masked]> wrote:
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: <[email-masked]>
Date: Mon, 29 Oct 2018 10:42:28 +0000

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-numbers-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. 

Cheers,
Med

> -----Message d'origine-----
> De : Int-area [mailto:[email-masked]] De la part de tom petch
> Envoyé : vendredi 26 octobre 2018 14:05
> À : [email-masked]
> Objet : [Int-area] registering tunnel types
>

---

From: <[email-masked]>
Date: Mon, 29 Oct 2018 12:25:11 +0000

Hi Joe, all,

The various techniques discussed in draft-ietf-softwire-yang were specified in the softwire WG. This is why we are defining in softwire WG, not in another WG, a YANG module for these techniques. 

Cheers,
Med

> De : Int-area [mailto:[email-masked]] De la part de Joe Touch
> Envoyé : vendredi 26 octobre 2018 16:40
> À : tom petch
> Cc : [email-masked]
> Objet : Re: [Int-area] registering tunnel types
> 
> Tom,
> 
> The point is that this tunnel is trying to create a new version of service A
> that needs to behave exactly like A. It typically isn’t changing B.
> 
> That said, if there are extensions to B required, then they need ALSO be
> reviewed where B belongs, but IMO only in concert with A being where A
> belongs.
>

---

From: tom petch <[email-masked]>
Date: Tue, 30 Oct 2018 12:07:00 +0000

----- Original Message -----
From: <[email-masked]>
To: "tom petch" <[email-masked]>; <[email-masked]>
Sent: Monday, October 29, 2018 10:42 AM

Hi Tom, all,

* 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

---

From: <[email-masked]>
Date: Tue, 30 Oct 2018 13:15:35 +0000

Hi Tom, 

Please see inline.

Cheers,
Med

> De : tom petch [mailto:[email-masked]]
> Envoyé : mardi 30 octobre 2018 13:07
> À : BOUCADAIR Mohamed TGI/OLN; [email-masked]
> 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
> 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
> seem to neglect the need to update, the impact on, the tunnel MIB

[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."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^  

> 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?

> NETMOD WG have a view on this?

[Med] The yang doctor is happy with the design in the softwire I-D.  

> 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

[Med] RFC4087 is the current authoritative reference we have as per the IANA-maintained registry.