Re: [Softwires] Tsvart last call review of draft-ietf-softwire-iftunnel-04

[tom petch <[e-mail]>]

----- Original Message -----
From: "Eric Vyncke (evyncke)" <[e-mail]>
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"
<[e-mail]> 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
>     [e-mail] 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.
>
>
>
>
>