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

[tom petch <[e-mail]>]

----- Original Message -----
From: "Black, David" <[e-mail]>
Sent: Thursday, May 09, 2019 2:45 PM

> > [Med] The intent of the draft is to reflect the current registered
tunnels types.
> ...
> > [Med] Registering new tunnel types is not in the scope set for this
draft.
>
> I understand that, but as stated in the review, I don't think that
it's the best course of action.  The email below appears to reject all
of the IETF Last Call comments in the review and in particular presents
the scope of the draft as fixed and unchangeable; that's unfortunate.
On that basis, I will agree to disagree and leave these IETF Last Call
concerns to the ADs to sort out.
>

David

I think that the concerns that you raise need addressing.  I also think
that there is another consideration that might be of greater impact.

The definition of interface types has long been an IANA registry which
has been incorporated into MIB modules and, latterly, YANG modules.
Recently, there has been an I-D
Guidelines and Registration Procedures for Interface Types
with Authors : David Thaler   Dan Romascanu
which, if I read it aright, is saying that the process has gone off the
rails and that the IANA registry should be of Interface Types and
nothing to do with MIB modules or YANG modules, although the YANG and
MIB modules will most likely be derived from it.  I see it as a question
of who owns the registry, and that it should be those concerned with
interfaces and their specification and that those concerned with OAM
should take second place to that.

If that logic is correct, then I would apply it to tunnels, that the
registration of tunnels belongs to those concerned with tunnels,
int-area perhaps, where I see drafts on tunnels being discussed, with
those concerned with OAM building on that work but not being the
drivers, controllers, thereof.

Tom Petch

> Thanks, --David
>
> > -----Original Message-----
> > From: [e-mail]
> > <[e-mail]>
> > Sent: Thursday, May 9, 2019 3:50 AM
> > To: Black, David; [e-mail]
> > Cc: [e-mail]; [e-mail];
[e-mail]
> > Subject: RE: Tsvart last call review of
draft-ietf-softwire-iftunnel-04
> >
> >
> > [EXTERNAL EMAIL]
> >
> > Hi David,
> >
> > Thank you for the review.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : David Black via Datatracker [mailto:[e-mail]]
> > > Envoyé : mercredi 8 mai 2019 00:46
> > > À : [e-mail]
> > > Cc : [e-mail]; [e-mail]; draft-ietf-softwire-
> > > [e-mail]
> > > Objet : Tsvart last call review of draft-ietf-softwire-iftunnel-04
> > >
> > > 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,
> >
> > [Med] The intent of the draft is to reflect the current registered
tunnels
> > types. This is mentioned in the introduction:
> >
> >    This document specifies the initial version of the
iana-tunnel-type
> >                                ^^^^^^^^^^^^^^
> >    YANG module identifying tunnel interface types.  The module
reflects
> >
^^^^^^^^
> >    IANA's registry maintained at [TUNNELTYPE-IANA-REGISTRY].  The
latest
> >    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >    revision of this module can be obtained from the IANA web site.
> >
> >  and the
> > > discussion of extension of this YANG module would need to be
aligned
> > with
> > > that limited applicability.
> >
> > [Med] This is an IANA-maintained module. That is, when a new tunnel
type is
> > registered, the module will be automatically updated to include that
new
> > type identity:
> >
> >       When this registry is modified, the YANG module
iana-tunnel-type
> >       must be updated as defined in RFCXXXX.
> >
> > >
> > > 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.
> >
> > [Med] Registering new tunnel types is not in the scope set for this
draft. It is
> > up to the documents defining these tunnel types or making use of
them to
> > make a request to IANA. For example, this is the approach followed
in
> > softwire wg for at least three tunnel types (16, 17, 18).
> >
> > > 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.
> > >
> >
> > [Med] Wouldn't that recommendation be better added to documents such
> > as: https://tools.ietf.org/html/draft-thaler-iftype-reg-02?
>